Agile is a journey, not a destination. You probably already heard this quote, and hopefully you spent some moments to reflect on its truth. When starting from scratch — as it happens in agile transformation projects — the first steps of this journey might not be perfectly fitted to all agile good practices. But, hey! even a splendid butterfly is an ugly larve in its first days of life.
So, imagine that a software company has decided to migrate from a classical project management model to Agile software development. And, to be more specifically, they choose Scrum. Among many things that are changing, some of the roles within the project teams are disappearing. But what do I say?! ALL roles are disappearing and some new ones are created from scratch. People need to move from the old role to the new one and this is definitely not a walk in the park.
Think about the Project Managers. In the old organization they were the mighty emperors of each project, deciding who does what and by when. They were entitled – perfectly legitimate – to allocate tasks and almost exclusively communicate with all stakeholders, while the team was just a handful of resources, doing their job to accomplish the project objectives. In the new organization what role could a former Project Manager play?
Some may say that (s)he could become a Scrum Master. I wouldn’t strongly disagree, but I would advise carefulness. Yes, it is possible, but usually such a transition is not that easy. And if you take a look on the job descriptions of a classical Project Manager and of a Scrum Master, you can easily understand why. It takes time to switch your mindset from command and control to empower and facilitate. And – in my experience – some people never succeed this personal transformation. Sad, but true.
The transition from Project Manager to Product Owner seems to be more convenient and natural. You still have a leverage on the product/project objectives and on its backlog, you decide on priorities and you accept or reject the increments produced by the team. Much more familiar job for a Project Manager, isn’t it? Apparently this is the perfect move that a Project Manager can make in such a situation. But the devil hides in the details.
The well-trained reflexes of a Project Manager – especially of a good one! — are not yet dead. They reappear every now and then. In sprint reviews, when (s)he might be tempted to change the acceptance criteria of a finished user story, just to add new conditions, because in the past (s)he was allowed to do so. Or during the sprint, when slipping some new “urgent” tasks in the sprint backlog would appear perfectly normal – is for the sake of the project success, isn’t it? Or in sprint planning when (s)he might feel the temptation to suggest the estimation in story points of an user story or the name of the persons that should be assigned to work on it. And the bad news is that the team – which used to interact with this person as a Project Manager not so long ago – might not even notice the violation of agile principles. It seems so natural, so consistent with the past!
So, how do you help the new Product Owner and the team to avoid this trap? Well, unfortunately there is no Swiss-army knife solution that will solve any problem of this type. But I can suggest here a possible approach to make sure that the team is handling the assignment of stories and tasks by themselves. Short notice: I am referring here to teams that – for any valid reason – are doing this assignment of stories and tasks in the second part of the sprint planning, after estimating the size of each sprint backlog item1. So, here it is:
During the second part of the planning, after finishing the estimation of user stories, the team needs to decide what is the commitment for the next sprint. Of course, the velocity of previous sprints is a good guidance, but there are also other things to consider. When a team is new to agile (as I stated in the beginning of this post), team members might feel a bit insecure to quickly decide how many stories they should commit to. Also, when competencies are not evenly spread in the team and team members are more specialized in some technical areas, this is a not-so-bad practice to make sure that everyone’s work capacity is fully covered.
As a Scrum Master or Agile Coach, grab several flipchart paper sheets and, using a marker, divide each of them vertically by the number of weeks of your sprint. Also divide them horizontally in 2 or 3 columns. Each team member will get one column, so make sure that you have enough flipchart sheets with columns for everyone. Stick the flipchart sheets on a wall, to create a big “calendar”.
Ask the team members to write their names on top of a column. If there are some stable sub-teams that are usually working together, they might use adjacent columns. Then ask them to grab some post-its and to write the stories that they will take care of2, and stick the post-its on the flipchart, in their own column. First story they will handle should be on the top of the column, the next should be lower, on an imaginary row that corresponds to the day of the sprint when that story is supposed to be started. For a team of nine members and a three-week sprint it should something like this (imagine that the yellow post-its are user stories and/or technical tasks):
Some agile evangelists may say that this is not the spirit of Scrum. They would be right, academically speaking. Some may even call this an infamous planning tool, reminding about the waterfall approach. To a certain point, it’s true. But I don’t think that waterfall project management is evil. I think that all kinds of project management are sets of tools that you use for a purpose. And this particular one I consider to be a very practical tools that helps a team to move toward agile, because:
- it gives the team members a smooth transition from the former processes to agile process, through a temporary compromise;
- it helps the team members to learn what commitment really means;
- it helps the team members to learn how to assess their capacity as accurate as possible;
- it helps the team members to coördinate tandems activities so the team capacity is fully used;
- it shows to everyone what self-organization actually is;
- it promotes transparency and visibility;
- is provides a very good additional guidance for daily scrums, where everyone can position his current status against the initial estimation;
- it helps the PO (the former project manager) to resist the temptation of “innocent” interference within the assignment of tasks and stories;
- it reassures the PO (the former project manager) that the commitment is realistic, through a tool that (s)he easily understands;
- it builds trust between PO (the former project manager) and the development team.
Should the team stop at a certain point in time to practice that? Of course. Because is a temporary compromise. When? The sooner, the better. When most of these goals where reached. When the larve is ready to become a butterfly.
- One valid reason that I frequently encounter is the uneven distribution of knowledge and competence inside the team. Some tasks can be executed only by some team members. Until they learn from each other, eg. through pair programming, the only option to continue delivering is to assign the right tasks to the right persons. [↩]
- They should select them from the ones prioritized by the PO and estimated by the team. [↩]