Going Back to the Beginning

I had a very interesting conversation on the scrumdevelopment yahoo group this week that really got me thinking about a few things.  The argument was about the value of estimating stories in scrum.  I will definitely talk about that in another post, as Ron Jeffries has once again opened my eyes to a new way of looking at things.  What I really got out of this was a reminder that we need to sometimes go back to the beginning and cut out some of the cruft that has been growing in our understanding.

What was it that we liked about Agile when it hit the scene?  The emphasis was on working software, not documentation and reports.  The focus was to make something of value, release it often, and build the value incrementally.

What am I talking about?  I’m talking about going back to the beginning of the Agile movement, even slightly before there was an Agile movement, and remembering why we are doing this in the first place.

I still recall how I got started “doing Agile”.  I had just finished spending $30,000 getting my team trained in a semi-iterative, semi-waterfall process that was all the rage at the time, and still has quite a few adherents.  I came away from this week feeling rather deflated and very disappointed.  After spending all of that money, and having my team sit through a week of being lectured at, I started to despair that there just isn’t a good way to overcome the inherent problems with software development.  As a side note, there was also an extremely heavy push by the teacher that there really is no way to use this process successfully without spending a ton of money on his tool.  I remind myself of that whenever I go to coach a client.

So what happened next you are wondering…maybe.   Well I’ll tell you.  I went to visit another software shop, with an eye to maybe working there.  What I saw was an incredibly happy work environment.  People were working together, and they seemed to enjoy themselves.  When I commented on this, they said that a large part of this was because they were doing Extreme Programming.  The code was extremely high quality, they had predictable delivery, and even more interestingly, there was a high level of energy that suffused everything they did.  This caused me to take a close look at what XP was all about.  I was then able to try it in my shop, with a team that was curious but a little suspicious.  I asked them to try it, and the results were fantastic.  We had the fastest turnaround and the lowest defect rate of any similar group within our corporation.  And most importantly, the team was having fun.  One experienced programmer came to me one day and said “Steve, I just wanted to thank you for making programming fun again.”  After ten years, I still consider this my highest achievement.

So lets go back to the beginning.  Lets remember why we want to “Do Agile”.  We want to create great software, and we want to enjoy ourselves while we do it.  Take a look at your current process, and ask yourself, “how many of these activities are we doing because they enable great software, and how many of these activities are really there because we read somewhere that they are required?”  I for one am going to focus on Doing the Simplest Thing That Could Possibly Work, with a side helping of You Aren’t Going to Need It.

Posted in Uncategorized | Tagged , , , , | Leave a comment

Self Organization is an Emergent Behavior

Ever since I got involved in the agile development community, I’ve struggled with the concept of self organizing teams. We all know that the most highly performing teams are self organizing. The question remains, “How do I, as the duly appointed leader of this team, enable self organization?”

This seems like a false proposition, even from the outset. We started with a team that has been formed by some act of management. Then management assigns someone the job of leading the team. The paradox is obvious. “Go organize a self organizing team”. I confess that I have really had a hard time with this concept for years. Finally, in the course of a weekend, I have stumbled on what I believe is the answer to this paradox. Just as good software design is emergent, so is a self organizing, self directed agile team.

One of the earliest and most valuable lessons I learned in the world of extreme programming is that good software design comes not from up front planning, but from constant, purposeful craftsmanship and refactoring. When we are working on the software, as we find areas that can use improvement, we refactor to a new, slightly better design, paying close attention to not changing the behavior of the software. Each of these changes is small, and may have only a little bit of impact, but over time we will find that a new software design has emerged, and that it is superior to where we started. I believe that this is exactly how a self directed team will emerge as well.

How does an agile development team become self directing? One step at a time. Most organizations are going to form a team around some sort of project or task, and then assign someone as the manager or lead. One of the most important jobs for this manager is to enable an environment where the team can become a high performing team. This means providing the right tools and a safe environment in which to take risks. As the team starts to gel, certain behaviors that lead to self organization will emerge. Perhaps a programmer will start implementing unit tests and continuous integration, just because she finds it interesting. Or maybe the team will collectively start to make decisions, and inform you of them as they are starting to be implemented. Each step of the way, be ready to identify and encourage these emergent behaviors. Over time, you will be able to step further and further away from the “command and control” and the team will be able to emerge as a true self directed unit. At this time, you can comfortably move on, or take a long vacation: you will have earned it.

Posted in Uncategorized | Tagged , , , , | Leave a comment