agile programming

Overheard - Defining kanban for programmers

“We in the software community are new to kanban, and it is easy to get a bit too enthusiastic, and unintentionally change the meaning of kanban when we discuss it.” Henrik Mårtensson, Defining Kanba

Kanban is used by in both lean and agile software development methodologies. Henrik explains that the kanban boards filled with sticky notes used by software developers are work-in-progress (WIP) kanban cards.

Scott Miller says

Each sticker or card represents a task at a small level - design login screen, develop reservation stored procedure, test login (the smaller the task the better). The stickers/cards may also be agile user stories. In addition, there are usually columns for “To Do”, “Active”, “Failed Test”, and “Complete”. There may also be columns for the different teams that are touching the task.

The task is moved along from one column to the next and everyone on the team can see what the status is and what task is due next, without everyone needing a copy of Microsoft Project on their PC’s (not that there’s anything wrong with that…). This also empowers the development team to be a “pull” system. A developer can pull a card from the “To Do” column and work on it. The project manager can see what the status is at any moment.

Overheard: Kent Beck, extreme programming and the quest for quality

I think it’s a combination of technical and social factors that leads to all the defects in deployed software. Part of it is the attitude that software is just inherently unreliable, and customers are conditioned to accept that. Developers are conditioned to accept that. Testers are conditioned to accept that. We just decided it was like the weather and there’s nothing we could do about it, which isn’t a very responsible position because in fact, there’s a lot that software developers can do about it. Kent Beck, as quoted in Extreme Programming inventor talks about agile development

Kent Beck gave a great interview that’s posted on the IBM developerWorks site, where he talks about the payroll project at Chrysler.  It’s a great read.

Now, the payroll program would handle Chrysler’s entire payroll, representing 1/10 of 1 percent of the entire US gross national product — at that scale, with union rules and all the places they operate, it’s a complicated program. They had a crying business need; it had to work. At the same time, this wasn’t rocket science — we just had to execute.

So, after a couple of weeks I interviewed everyone one-on-one. I told the first guy that we’ll divide the project into three-week intervals called, say, iterations. In each iteration we’ll implement a few new features called stories. We’ll write down all the stories we need, slot them into the iterations, then do it.

I told the next guy [I interviewed] that we have these three-week iterations divided into stories. For each story we’ll write these, um, acceptance tests to demonstrate that the stories meet the customer’s expectations.

With each person I interviewed I added a little more. By the end of the day, I’d interviewed 20 people and had laid out Extreme Programming’s basics.

My favorite quote from the article? “Sucks less isn’t progress.”