Disassembling the Nokia Test
The Nokia Test is a quick assessment of practices to determine if your Scrum implementation is up to snuff, based on how it is implemented at Nokia. There is debate about whether it should be more or less rigorous or flexible. My thinking is that it’s great if you are doing exactly what Nokia does, which is true for very few of us. Let’s take it apart to see if there are any user serviceable parts inside.
First off, I think that if you are not Nokia and you have decided to use this test as your golden standard, you have already missed the point about agility. No single defined approach will ever be optimal for all your projects in your organization. Any organization should have a step zero where they look at the proposed project, look at the team and culture, look at the business objectives, and consciously decide the most reasonable approach for attacking the problem. While some elements of Scrum can be generalized, not all of it can be. Nokia’s spin on Scrum won’t work for everyone.
Into the test itself. The first few elements identify whether or not you are really iterative.
Iterations must be timeboxed to less than six weeks. I think iteration is imperative, but I have a problem with a magic number in the mix. Most of us as developers have learned that a hard-coded number is a sure-fire way of giving us problems at some point, and this is true here as well. Six weeks might be fine for Nokia, but that might be the entire project lifecycle in some shops. Too few iterations and you don’t have enough visibility into true progress, or natural points for allowing feedback to improve the existing product. Too many iterations, and you run the risk of excessive overhead. Lose the magic number, be iterative, but select an iteration cycle that works for you.
Software must be tested and working at the end of an iteration. I’ll buy that, pretty well as is. The point here is that we don’t want a gradually increasing bow-wave of loose ends that totally consumes the last iteration or two. When you have implemented a feature, it should work. If there are any loose ends, there should be an understanding of where they will be tied up in a later iteration.
Iteration must start before specification is complete. This one is interesting. Without insight into the thought processes going on, the intent appears to be avoidance of analysis paralysis, and that is a good thing. The idea of the specification ever being complete is a powder keg, though. The iteration needs to have clearly defined goals (that can be objectively assessed at the business value level), but the details can and must be discovered during the iteration. Ideally, the backlog of features (or whatever terminology you use) is defined to a level where the scope of the next iteration (or the next few iterations) is understood before the current iteration finishes.
As noted in some of the discussions around the Nokia Test, another key part of iteration that needs to be explicitly identified is that the team actually takes the time at the end of an iteration to consider the results, and feed the learning into future iterations. A retrospective that impacts future development is imperative. It wouldn’t hurt to explicitly identify that anytime someone sees behavior that is at odds with project and team success, they should step up and address the concern. Retrospectives aren’t the only point for this.
The next few elements identify whether or not you are really doing Nokia’s idea of Scrum. I’ll look at these and try to generalize to be more widely applicable, as Scrum is not part of the lexicon in every software shop (please don’t be shocked at this).
You know who the product owner is. Another straightforward element that is critical for any project. Someone has to have clear responsibility for ensuring that the product delivers the value to the end user, and to the business. Done correctly, the expectation of what that ROI should look like is defined in advance, as part of the overall vision for the product. That’s an element that many product owners conveniently neglect to do (giving them an easier task of artificially declaring victory), and is the accountability side of the issue.
There is a product backlog prioritized by business value. The product backlog has estimates created by the team. I put these together because I think there is value in looking at this element of Scrum from a different perspective. Business value and effort estimates are two valid viewpoints, and I think both should contribute to the overall prioritization. There may be features that involve little work but provide moderate business value, and could easily be implemented in an early iteration to beef-up the early feature set. There may be high value features that are difficult to implement: the job might be made easier by implementing other components first. I would suggest bringing both perspectives to the table, respecting them as reasonable (see the next point), and having the important discussions.
The team generates burndown charts and knows their velocity. Very Scrum-speak here, but can be generalized to suggest that estimates from the development need to be credible, and based on past experience with similar work. This is still one of the weakest areas for most teams, agile or otherwise, in the software industry. To be fair, the business owners should be striving to be quantifiably defendable from their perspective as well. In both cases, this is impossible if you do not track performance (time or value) against categories that can be mapped to future work products. Scrum does a nice job of providing a simplified model for doing so and gives teams an easier opportunity for getting started, but this remains a glaring hole in most shops.
There are no project managers (or anyone else) disrupting the work of the team. Wow. The way I read this, there are some serious dysfunctions to be addressed in how project management is perceived here. Sorry, but it is not a matter of telling everyone to get the hell out of the way, we have some code to sling: we are trying to develop commercial-grade products, not get our assignments to compile before the deadline. The business and the customer should always have a voice in what goes on, and this needs to be balanced. If project managers are seen as disruptive, that needs to be fixed. Call them Scrum masters if you need to, but in any shop, the project manager needs to be there to facilitate the team’s ability to get work done.
I expect that Nokia never intended the Nokia Test to be an industry-wide standard, and can’t fault them for what they have done (though I sure wonder about the history behind that last point). Indeed, their consideration of these issues and crafting of this Test is an indication that they are mature enough to identify a rigorousness that helps eliminate what many would call Cowboy Agile. Hopefully with this disassembly, you will be able to identify more relevant standards for the products you create. Whether or not you use a branded approach, you can define practices that allow you to be agile.