Measuring velocity is not enough
Scrum as an agile approach is great, it allows teams to get up to speed quickly with agile and also enable the business to understand what being agile means. The problem is that people often just do Scrum. Doing Scrum is not enough, it is a great place to start and will help you with your projects but your team still need to get the engineering disciplines in place, they still need to work on doing the right thing the right way and with level of quality demanded by the business.
Jack Milunsky posted a nice article that talks about why Measuring Velocity is not enough.
Like burndown charts, velocity is just another metric which the team can use to reach what I believe is the ultimate goal – sustainable throughput. Velocity in my opinion, is not a metric for determining productivity.
What I really liked, and is something that I am going to be covering a lot more over the coming months is the conclusion
.in order to enhance productivity there are many things one can do:
* You have to get the requirements down pat. The best way to do this is to work with the customer to define the user stories and get their intent up-front.
* Ensure you are capturing the acceptance test criteria from the customer up-front. This helps solve the greatest risk of all – getting the wrong product.
* Define your definition of "done" up-front so that there’s no argument at the end.
* Ensure you build quality in right from the start.
The conclusion can be split into two areas
- Understanding the Requirements
- Getting your process right
Getting your process right is something the development teams control, and there is a lot of information out there today about techniques like Test Driven Development, Continuous Integration and the like that all focus on the development process and quality.
Understanding the the requirements on the other hand and getting the business to provide you with valid and testable user stories is an area of agile development that I feel has been neglected. There are great books that have been written on how to write user stories and how to ensure they are testable. There are other books aimed at the business analysts about how to gather requirements. However these have never come together, agile development teams don’t look much be the user stories.
This pushing back beyond the user stories and into the way requirements are gathered and the business is understood is something I have been working on for a while. And with this push back beyond the user story it is clear the way to get business and customer buy in to the agile development approach is to really change the way businesses approach the complex problems they are trying to solve.
I have some really exciting things to announce over the coming weeks that will really take this discussion forward, working with some of the most visionary guys in the field.
Rest assured there will be a very big SharePoint focus.
