By: Chris Sims
One component of the Toyota Production System is the concept of standard (or standardized) work. A recent post on the Kanban Development list asked if this concept carries over when TPS and lean are applied to software projects.
Recently, I’ve been hearing this a lot: “I’m between jobs. I’ve got the time to work on my professional development, but now I don’t have the money.” Talk about frustrating! Hillary and I had a long talk about what we could do to help; here is what we came up with.
In my most recent InfoQ article, I write about someone’s approach to making a kanban flow look less like a waterfall process. The result is a workflow with new names for the steps. That’s fine, but it misses the point that even if the steps are the same, an agile kanban system is far from, and far better than, a traditional waterfall process.
In My Framework is More Productive than Your Framework, Ken DeLong examines approaches to making software projects more productive. He finds that despite the hype about frameworks, languages, and project management tools, these tend not to be the bottlenecks. Ken believes that the largest productivity gains are likely to come from improved communication, code readability and debugability.
Read the whole story I wrote about it on InfoQ.
Cheers,
I worked for a company that deployed their server software every day, sometimes more often than that. Over time, the system got more complicated and more prone to break when changed. The decision was made to only deploy twice a week. The reasoning was that this would give us more time to test the new build. Now we had a new problem: when we found bugs during testing it could be difficult to track down which of the many changes in the new build caused the problem. Worse yet, even when we could quickly find and fix the trouble, we had to do a whole new build and start the testing process over again.
The only game that we played at both of the agile learning games sessions was ‘Arranging the Deck Chairs.’ It’s a very simple, if physical, game. There are only 3 rules that the players must abide by:
I’m enjoying Agile Open Northwest. I hosted a session on agile learning games, in which we played three games:
A member of a new agile team asked the Scrum Development list how to keep track of the actual time engineers spend on tasks, and how this relates to the agile concept of velocity. Velocity is the agile metric for tracking how fast the team is completing features, and thus how long it will take to complete a project. The group’s opinion was that tracking time spent isn’t necessary or useful.
Pair programming and code review are each practices that improve the quality of software, as well as promote knowledge sharing. When the Agile vs. Lean, XP vs. Scrum, and vi vs. Emacs debates get slow, developers have been known to debate the merits of pair programming vs. code review.
I have worked with teams that used each of these practices to great advantage, as well as teams that used the both. Not surprisingly, the teams that used both practices had the cleanest code and the fewest problems with customer-reported bugs.
Theodore Nguyen-Cao described code reviewers as chickens, and paired programmers as pigs. I found the analogy interesting, and so I wrote
this article for
InfoQ.
Cheers,
If you haven’t heard of
Jonathan Coulton yet, now you have. He’s clever, geeky, and his music lends itself to great videos. This one is ‘Code Monkey’.
As a special bonus, here is ‘Mandelbrot Set’.