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.

I have been involved in several threads on more than one user group in trying to differentiate between what I view as Agile practices without the benefit of understanding Lean and what we do at Net Objectives where Lean both creates the context for and provides guidance to our Scrum practices. For some reason, these “conversations” have typically stirred heated debate, sometimes even personal attacks and once culminated in my getting thrown off a popular discussion group.  I thought I’d try to discuss why I talk about what we do the way I do.

This blog entry describes how a solid understanding of Just-In-Time (JIT) can give great insights into the differences between Waterfall and Agile methods.  I want to acknowledge the Poppendieck’s work for giving me the insights I am sharing today. Any failings, are mine, however. I highly recommend their latest Implementing Lean Software Development: From Concept to Cash.  It incorporates not only their earlier Lean Software Development Principles, but also the thoughts of Taichi Ohno and Womack and Jones – two consistent, but different ways of looking at what Lean is.