Like many other Agile practitioners, I have seen too many cases where an organization wants to adopt Agile, but believes that all they need is a little training. Of course, the most extreme would be when a group believes they can send one person off to become a Certified ScrumMaster and then they can simply train everyone else. While this intuitively sounds foolish, and many people could begin to articulate the shortcomings of this mental model, I’ve struggled to present a clear and succinct view of what exactly why this model doesn’t work. Although I recently came across a very good model that captures what I tacitly knew already. I hope this is valuable to the rest of you out there trying to make the case for coaching. more »

Thanks to everyone from the Mass Bay PMI Chapter for coming to see me speak about Agile in the Enterprise. It was a great discussion and I thoroughly enjoyed it. I have made my slides available from tonight’s presentation, they can be downloaded here.

Also, several people expressed some interest in local Agile groups so that they could learn more. I would point out three specific ones that have monthly meetings and support vibrant communities of both learners and practitioners:

• Agile Bazaar
• Agile Boston
• Nashua Scrum Club

Yesterday I had the opportunity to attend the “Agile Comes to You” event in Waltham. It was great to see so many people interested in learning more about Agile and I had some great conversations. Here is a copy of the slides I used

Discipline in Agile Teams

The other day I had an interesting thought. I’ m not sure what precipitated it exactly, but there were several things that led me to this idea I’ve been mulling in my head. Perhaps it was Alistair Coburn’s keynote at Agile 2009 where he said that Agile as a distinct entity was gone; if it was once an iceberg, it has since melted and is now just part of the ocean. It could have been Jeff Sutherland’s presentation where he points out that 84% of IT organizations are self-reporting to use Scrum. Or perhaps it was simply working with a current client when they were asking for my help to come up with very clear guidelines about the number of acceptance criteria that should be allowed for a single story. Anyway, it struck me: as Scrum grows in popularity, are we institutionalizing it? more »

In 1996 a friend of mine asked me what my New Years Resolution was. I didn’t have one, so I thought one up on the spot, “My resolution is to quit making New Years Resolutions.” I have stuck with it for fourteen years now.

The idea behind New Years Resolutions is great. We should reflect on the year that has past, think about what we would like to do differently in the future, and resolve to make that change. That is a great thing to do. The problem is that when we only do it once a year we tend to fail. Then, we wait a whole year to reflect and do it again.

So, this year resolve to stop making New Years Resolutions. Instead, reflect on your behavior soon, and make changes right then. Change every month, every week, every hour. Soon you will get good at changing and those promises you make to yourself will come true more often than not.

That is the lesson of Agile: self-reflection is hard, and we kind of suck at it. Change is hard, and we kind of suck at it. If we do it more often then we will have to do less each time and it won’t be so hard. If we do it more often then we will get good at it and it won’t suck so much.

In November, I spoke at several Agile Journal events in the Northeast about the benefits of using Agile and how they transcend simply “going faster”. I have already posted the presentation, but like most power point slides, it does not stand that well on its own, so I wanted to write up a summary of my thoughts on this topic for the ages, as well as to develop my own thinking. I share these thoughts with you now. more »

In his 1986 paper, No Silver Bullet — Essence and Accidents of Software Engineering, Fred Brooks describes the difference between essential and accidental complexity in software systems. Software is complex because what the users need to do is complex. Such complexity cannot be eliminated, but it can be managed, and most of what we do in software development is about managing that complexity.

The goal of Agile Software Development is to deliver a continuous stream of valuable, working software to customers. The challenge in doing that is to find bugs as soon as we create them, fix them, and deliver software that is defect free. This is important, because defects found by customers create a backflow of information that disrupts our ability to deliver value. To some extent this backflow is essential, but by finding and eliminating defects at the source we can keep the signal-to-noise ratio high and get our customers to give us more information about what they need and less information about mistakes we made.

So how do we, simultaneously:

1. Embrace essential complexity that comes from the user domain?
2. Eliminate accidental complexity – in all of its forms – as waste?
3. Identify and eliminate defects at their source?

The Agile approach to managing essential complexity is very close to the approach that Fred Brooks advocated so long ago: Grow the system incrementally. Hide complexity in a modular system with various layers of abstraction – individual ideas are expressed where relevant and viewed as abstractions from the perspective of surrounding modules. All software paradigms, object-oriented, procedural, functional, aspect-oriented, etc. are methods of organizing code into such abstractions. The trick is that we can’t accurately predict where our system will become complex. So, we have to keep our solutions as simple as possible, and hide complexity only where we find it in the course of trying to describe some real world user need.

The implications of this cut across everything we do:

• Given a user story we should create the simplest solution that could possibly work. This is literally the same thing as saying, eschew accidental complexity.
• We refactor to simplify the design of existing code. This activity, which is an integral part of TDD, is specifically designed to remove accidental complexity as it occurs, particularly in the boundaries between stories and surrounding essential complexity as it is discovered.
• We move forward deliberately, in increments, with plenty of slack. We do this because complexity is hard. We need to take the time to look for it and deal with it.
• We test and refactor mercilessly. Complex things are hard to test. Just like insects are attracted to bright lights, software bugs are attracted to complexity (Essential or accidental.) Like a porch light on a Summer evening, if it’s complex and it isn’t tested I promise you it has bugs.

In Part Two I will address the issue of designing code and tests in a way that:  hides essential complexity, avoids accidental complexity, and exposes most defects at the source.