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.

Working with the PMI Agile Virtual Community, I recently dabbled with publishing a presentation as a video with a voice over. This is a pecha kucha (20 slides advancing every 20 seconds) that I presented at the PMI Global Congress. I hope you enjoy.

more »

We already know that good unit tests are on FIRE. Here are some characteristics of good code:

Small – Classes contain only a few methods. Methods are no more than a few lines. Together they fit nicely on your screen without scrolling.

Intentional – Every bit of your code reveals precisely why it is there and what you intend for it to do.

Singular – Classes have one responsibility. Methods do one thing.

Tested – Every piece of interesting behavior in your code has a corresponding test (Likely it was written first.)

Encapsulated – Modules don’t know what information other modules contain. They tell instead of asking. They talk only to their closest collaborators.

Refactored – Eventually, code has to change. Good code stays good when it changes because it’s author loves it.

Agile teams have no leaders, because everyone on an Agile team is a leader. However, leadership is still important. So, how does leadership work if everyone is a leader? Here are my rules:

1) If something needs to be done, do it. Do it very, very well.

2) Never do anything by yourself. Always ask for help. Always give help.

3) Don’t delegate, cooperate. Never tell anyone to do anything that you can do for yourself.

So who is really in charge? The customer is. The customer knows what she wants and what she is willing to pay for. The team must deliver that.

The team gets to decide how to meet the customer’s needs. You won’t always agree. You have to work it out.

Remember that the right people showed up. You will solve the problem to the best of your ability and so will your teammates. Telling them how is counterproductive. If you know how then do it yourself, but involve them.

If you work this way everyone has an opportunity to succeed, to learn, and to grow.