Month: September 2009

Many organisations strive for excellence, talking about and planning for becoming a Center of Excellence. However, many of those organisations seems to be stuck in a culture of Cost/Benefit analysis.

But noone has become an expert, a top level athlete or world artist by calculating the return on investment on reading a book on a subject, practicing six hours a day or painting picture after picture.

We do these things because, in our heart, we belive it is the right thing to do.

I believe it is the same with excellence, we can only become excellent if we truly believe in the actions we take. Just as a simple example, there probably would never be a framework for automated acceptance testing if you did a cost/benefit analysis before implementing it. It is just to hard to calculate the benefit, the return on that investment. And particularly so if you only consider the current project…

Excellence comes from a burning conviction to become better!

In this blog entry Mike Griffiths summarises some discussions he had with Tony Parrottino, who is a Behavioural Scientist. It is an interesting blog post and Tony’s answers to some of the questions are important clues on how to progress the agile thinking and ways of working.

I have often said that I think “the three questions” (what did I do, what am I going to do, is anything blocking me) are not the best ones. In my view the focus on the daily meeting should be continuous, visible progress, so maybe the most important question is the one about blockage. If we focus on that we can grow a helping culture which is one important component in a fully self-organising, top-notch, team.

I get some support from Tony Parrottino, since he says the three questions are “sub-optimal”. I think Tony is answering the wrong question, though. Because the questions are not put to the team by a manager that wants them to perform. Instead they are the things other team members need to hear to be able to help out.

Tony is much focused on that the one thing we need to manage is behaviour to increase performance of individuals and teams. One of his comments was

trying to remove what you don’t want will not ensure you will get what you do want

But that is in the context of team behaviour, not in terms of obstacles or difficulties. He goes on to talk about “pinpointing” which seems to be a term used to be precise in expressing what you expect your collegues to do and how to behave. To this I can only agree. Focus is one of the most important factors in performance, and you can only focus if you know exactly what is expected.

In larger organistations it seems more difficult to get acceptance for the agile estimation and planning. By agile estimation and planning I mean measuring velocity of a team and using burndowns or other methods to forecast finished stories or functions at the time of the deadline. There are many good places, blogs and books to read about this.

This reluctance is probably related to the larger number of people focused on the number crunching of traditional resource allocation and planning, but also because the size of features are bigger.

Traditionally we have always hoped there was a way to find the “true” and absolute cost of some development early. Usually the thinking goes along the lines of thinking and planning really long and hard. That will never happen… and we know that more thinking will not help. Those that get their initial estimates fairly right is using statistics to adjust them over time to match historical observable data. Some companies actually collect data about the relation between some initial estimate and the “real” number of worked hours. Let’s call this the estimation factor.

This factor is based on statistical, empirical evidence, and includes any and all effects that influence the “real” outcome: de-scoping, requirements creep, features not realized up-front, difference in skills etc. All which are normal effects in any development and should be expected. In any particular case the factor may be off by a mile, but overall it will even itself out. That’s what statistics is about.

However, statistics only work if you measure the same way every time. If you re-estimate in the middle of development, you can’t reliably use the same estimation factor, because you are not in the same position as when you first estimated. You have more knowledge about the actual required functionality, its complexity and some of the work has already been done, possibly with de-scoping and just realized required additions thrown in.

So if you mix and match these numbers and throw in some “converted agile estimate” too, you will get a number which will tell you nothing.

Actually, the estimation factor, if used correctly, is exactly what the team velocity is: a factor between some guestimated effort (points) and some empirical data (points per iteration) that can, if used correctly, help you to forecast future outcome. The estimation factor is on large objects like features and whole departments, the team velocity is on stories and a single team.

I am not a beliver in converting team velocity to hours, and I am sure that planning and follow-up could be extremly simplified (and de-mystified 😉 if some agile techniques where applied. Agile is about making things simpler, not more complicated.

Repeatedly I get the question “What books should I read about Agile?”. Here is a list I have compiled. There are probably more good books, and if you find one, don’t hesitate to recommend it to me.

Agile

• Lean Software Development: An Agile Toolkit, by Tom & Mary Poppendieck.
• Agile Software Development, by Alistair Cockburn.
• Agile Software Development Ecosystems, by Jim Highsmith.
• Scrum and XP from the Trenches, by Henrik Kniberg.

Scrum

• Agile Software Development with Scrum, by Ken Schwaber & Mike Beedle.

XP

• Extreme Programming Explained: Embrace Change, by Kent Beck.
  The first edition is more practical, the second is re-written extensively to show how values fit together with the techniques and practices.
• Planning Extreme Programming, by Kent Beck & Martin Fowler.

Management & Leadership

• Agile and Iterative Development—A Manager’s Guide, by Craig Larman.
• Collaboration Explained : Facilitation Skills for Software Project Leaders, by Jean Tabaka.
• Managing The Design Factory, by Donald Reinertsen.
• Agile Retrospectives: Making Good Teams Great, by Esther Derby & Diana Larsen.
• Peopleware: Productive Projects and Teams , by Tom DeMarco & Tim Lister.

Requirement Management & Modelling

• User Stories Applied: For Agile Software Development, by Mike Cohn.
• Agile modeling: Effective Practices for Extreme Programming and the Unified Process, by Scott Ambler.

Planning

• Agile Estimating and Planning, by Mike Cohn.

TDD/Test/QA

• Agile Testing: A Practical Guide for Testers and Agile Teams, by Lisa Crispin.
• Test Driven: TDD and Acceptance TDD for Java Developers, by Lasse Koskela.
• Test-Driven Development By Example, by Kent Beck.

Programming & Refactoring

• The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt & David Thomas.
• Working Effectively with Legacy Code, by Michael Feathers.
• Refactoring: Improving the Design of Existing Code, by Martin Fowler.
• Refactoring to Patterns, by Joshua Kerievsky.

Lean

• Implementing Lean Software Development: From Concept to Cash, by Mary & Tom Poppendieck.