As a Lean proponent I talk a lot about speed. Lean says to focus on time not resource utilization. That is, we want to shorten the cycle time of our value streams (that is, the time from when we start to when we deliver value). It also suggests that most problems are systemic – so when they occur we must fix the problem – view it as an ongoing impediment - and not merely work around it.

I wanted to announce Scrum# our approach to Scrum. As many of you know, we have been long-time proponents of extending Scrum with Lean and technical best practices (Design Patterns, Test-Driven Development, aka Emergent Design). We've decided to formalize the naming of our approach so we could better define it.

In my earlier blog I commented about the role and value of context. I recently came back from a trip where I was conducting an assessment of a 50-75 person development organization. They were doing Scrum reasonably well and had based their sprints on building epics, having read Mike Cohn's books. This made sense since epics typically defined releasable value.

I have just come back from SQE's Better Software Development Conference after having finished my sixth team-oriented Scrum training in the six weeks. It has been an amazing time with these teams and it has reinforced my belief that learning Scrum needs to be a team-activity because Scrum is a team process. To create a highly functioning team, everyone on the team needs to understand the basics of Scrum. The team's coaches - the Scrum Masteffr and the Product Champion - need some additional training for their specialized roles.  read more »

 Test-Driven Development and Design Patterns

Last month, in my conversation with Scott Bain on Impediments to TDD, I wanted to explore how he was incorporating TDD and Design Patterns, two areas of particular expertise for Scott. That is the topic of today's conversation.

If you haven't already read my "A Reflection on Just in Time (JIT)" I suggest you read that now, before proceeding.

I have been re-reading "The Machine That Changed the World: The Story of Lean Production." It got me thinking about how the paradigm shift from Mass Production to Lean Production is very similar to the shift from Waterfall to Agile. This is because the beliefs underlying Mass Production are fairly similar to those of Waterfall while the beliefs underlying Lean Production are fairly similar to Agile: 

Emergent Design (audio of the webinar)

What is design? An opportunity to mitigate risk. A way to look for eliminating waste. It is certainly not simply the "thinking" part of software development.

When are you doing design? Just up front?

Overcoming Impediments to Test-Driven Development

Recently, I had the chance to sit down with Scott Bain, author of Emergent Design and an expert in Test-Driven Development. He wanted to talk about what he has seen as impediments to implementing Test-Driven Development: impediments that arise before an organization decides to adopt TDD and impediments that arise after adopting TDD. He bases this on his conversations with clients who are in the midst of implementing TDD, on his coaching experience, and on own personal journey with TDD has he has incorporated the concepts into Net Objectives training in Design Patterns, TDD, and Analysis.

This is the first of several posts about how a team can be Agile while using Visual Studio Team System to manage their project and process.

You have probably heard the quip that the last simple project was done in 1960. The complexity and breadth of software projects today is truly astounding.  The size of teams working on a project seems to be getting larger. To deal with this complexity, teams must have higher bandwidth communication and various Agile methodologies like Scrum, XP, BDD, FDD, AUP, and Clear Case achieve this by emphasizing smaller local team sizes.  

However, if only one small Agile team were to take on something the size of a modern DBMS, accounting system, large scale e-commerce site, or a medical records management system, they would not be able to deliver product of sufficient value for years.  To achieve release goals, there have to be dozens or hundreds of small teams working on the project to deliver and maintain the product. And coordinating so many teams is, itself, a complex problem.

Does this sound like a Catch-22?

This blog is somewhat of a response to a comment on my JIT posting.

I really like The Goal and think the Theory of Constraints (TOC) is brilliant.   I believe it can be applied to software development in two ways.  One is very valuable and the other must be dealt with with great care.  First, the one to be careful.