Toronto Project Manager – Paul Henman CSM

Last week was a tough one – my fellow scrum masters & I had to get seven scrum teams through their reviews, retrospectives and planning sessions. There’s a lot of debate over what can be done better next time, which is good – there’s lots of room for improvement and I think addressing just a few key things will make a big difference.

For those not familiar with these meetings, I should explain a little about each of the “sessions” I mentioned above:

• Review: at the end of an iteration (aka sprint), the team demonstrate their work to the customer. In our case we also walk through our Definition of Done (a checklist of things which have to be completed, e.g. unit test coverage, documentation) and end with the customer declaring whether our User Story* is done or not. (*Yes, I can see this list needs to grow!)
• Retrospective: the team looks at two questions: What went well? and What needs improvement? – the aim is to identify new things we’ve tried which worked and therefore we want to repeat, as well as identifying things which need to be addressed in order for the team (or project) to perform better. Some recent examples are pair programming (went well but we need to accomodate the additional time required when we’re planning) and quite a few environment issues (e.g. development tools, central build). The team prioritise the areas for improvement and then we discuss them, creating an action plan which may require me (as the scrum master) to escalate items.
• Planning: the team break down the tasks required to complete their goal(s) and estimate them; we use Ideal Hours, which is an uninterrupted hour and therefore may span a longer elapsed time. As a guide we compare the total estimate effort to the team’s capacity (how many hours can the team members commit to these tasks) and, if it looks reasonable, the team commit (to the customer) to deliver the User Story/Stories at the end of the iteration.

So what’s a User Story? Well, if a “traditional” project manager isn’t already freaked out by everything so far, this is sure to push them over the edge! Instead of detailed requirements documentation, the customer create a User Story which is really just a start point for a discussion with the scrum team. It can be something as vague as “As a user, I can log on to the system”. The aim is get the team and the customer talking and drawing – it’s only when this happens that both parties really start to understand each other. A customer won’t (normally) understand what’s possible, and so doesn’t know how much to ask for / expect from the team. Equally the team don’t (usually) have the business knowledge – techies tend to think about how something can be implemented, not why the customer / end user wants it or how they’ll use it.

I first encountered User Stories only a few months ago and I think it’s brilliant – the more we can get everyone to talk then the better we’ll understand each other. Writing reams of documentation doesn’t help anyone (unless you’re selling us the paper!) because it takes much longer to transfer the information between the parties, and frequently the assumption is that the documentation is complete – if it’s not written down then it’s not important (or is out of scope, etc.) and therefore we’ll do exactly what’s written down and no more.

So anyway, it was a long week and unfortunately some of those sessions spilled over in to this week, but the end is in sight … until we start this all over again in a couple of weeks!

It bugs me when people talk about “allocating resources” when they mean “assigning people” – it makes it sound like the professionals employed by (any) company are simply a commodity, a square peg than be placed into any square hole, or round hole given sufficient pressure. If your company looks on you and your co-workers as “resources” then I bet you feel truly valued and appreciated. Resources are things like money, equipment or the like – things which we need in order to do our job, things which won’t object to being called resources.

Did you know Project Agile was the name given by the US Department of Defence’s Advanced Research Project Agency to the pilot introduction of the M-16 rifle in Vietnam? Nor did I until my channel surfing landed me on a programme about infantry weapons.

Given that (I anticipate) a lot of my posts will relate to Agile and Scrum, I suppose I should start by explaining a little about them … or at least pointing you at some helpful resources, because there’s no point in me reinventing the wheel.

Agile is a family of (mostly iterative) development processes; a manifesto and some principles were documented by the founders of Agile in 2001. The term Agile came from Martin Fowler (of ThoughtWorks) but in total there were 17 people who created Agile; fortunately (for me, at least) some of these people frequent the online forums and discussion groups / mailing lists, imparting their views.

Scrum was one of the early agile methods along with Crystal Clear, Extreme Programming (XP), Adaptive Software Development, Feature Driven Development, and DSDM. It was first described by Takeuchi and Nonaka in “The New New Product Development Game” in which they noted that projects using small, cross-functional teams historically produce the best results, and likened these high-performing teams to the scrum formation in rugby.

For an overview of scrum, check out Mike Cohn’s description and frequently reproduced diagram … which I can’t help but reproduce just once more

Once you understand scrum/agile, there’s no going back to waterfall – at least that’s how my fellow scrum masters and I feel! It just makes so much sense – short iterations with close customer involvement, which reduces waste resulting from misunderstandings or changes in requirements.

Obviously this is a very quick overview but hopefully this blog, along with the many other resources out there, will help you (and me!) understand it and put it in to practice on a daily basis.