Tuesday, January 12, 2010

What’s the value of Agile out of the box?


I often meet peers who ask what Agile practices Pathfinder utilizes. From the outside we pretty much use all of XP’s practices. However, if you take a deeper look we do some things a little differently (especially how to use and calculate velocity). For Agile purists, one might question if we are really doing Agile. They would claim changing practices is slippery slope. For example, a team will start altering Agile practices to create a “home grown” version only to find they are using only some practices and not seeing the benefits they hoped for. I feel questioning if we are really doing Agile based on exactly what practices one uses shows how familiar and mature one is with Agile principals. A better question would be to ask why we changed them. Agile is not meant to be a methodology, but a set of principals. In my opinion, using things like Velocity to estimate whether a team will finish a project within a certain time frame is a hack at best. This always was hard to explain to customers. While I was reading Leading Lean Software Development I discovered something that helps. The Poppendieck’s point out that the engineering practices of Agile (TDD, collective code ownership, etc…) are solid and not likely to change. But, the project management practices implement a system on top of another system - a hack.

Once you have sufficient experience managing projects with Agile practices you should feel comfortable adapting those practices to your own teams and projects. As long as you are still following Agile principals this is okay. In general, this is what’s going on in smaller companies. Having coached a number of large organizations transitioning to Agile I can say this isn’t how they look at things. The problems start when you adapt the practices, but try to deliver all projects in an identical manner. This makes sense for waterfall-like delivery methods. But, when an organization comes up with its own version of “Agile” it can only work for the subset of projects it is tested on. Rolling this out to the entire organization as “the way” to deliver projects from them on is a failure pattern. The principals are lost and so is the adaptability of the organization. The time spent to move over to agile is immediately wasted.

Photo Credit:
kevindooley
under a Creative Commons Attribution License

Sunday, January 10, 2010

Review: Leading Lean Software Development


In Leading Lean Software Development, Mary and Tom Poppendieck present a handbook for how to run a software development group, top to bottom. I intended for this to be a simple review of concepts known to me for years, but the book offered much more. The book’s jacket describes it better than I can: They “show software leaders and team members exactly how to drive high-value change throughout a software organization—and make it stick.” If you are completely new to agile and lean you the book might move a little fast for you. If this is the case, I suggest you spend some quick time getting agile and lean 101 elsewhere first.

If you walk away with one concept after reading this book it should be to believe that success comes from people. The best companies focus on developing problem solving skills and local decision making. These companies favor adaptability over efficiency. These companies make money to survive rather than simply surviving to make money.

The book starts out by defining the concept of frames, “the unspoken mental constructs that shape our perspectives and control our behavior in ways we rarely notice.” A useful way to look at software development. I was happy to see their description of Agile as evolutionary rather than revolutionary. This is why when you explain the set of Agile practices to those with extensive experience they usually nod their heads and say they are already doing them. I have been telling people that Agile is a collection of best practices that good software shops have been using for years. Now I have a reference to support this.

Software craftsmen should read chapter 2 about technical excellence. The chapter goes through each engineering practices, explains it such that a non-practitioner can understand and gives examples. After they are done they should make their manager’s read it, then their managers.

Conclusion

I wish this book had been written 5 years ago. It would have saved me considerable effort and time trying to define what a well run software organization looks like. Your mileage my vary, but I will say that I intend to keep this on my bookshelf right next to Managing The Professional Service Firm.

:: Originally Posted on Pathfinder Development's Blog ::