A not-so-infamous compromise

Agile is a jour­ney, not a des­ti­na­tion. You prob­a­bly already heard this quote, and hope­ful­ly you spent some moments to reflect on its truth. When start­ing from scratch — as it hap­pens in agile trans­for­ma­tion projects — the first steps of this jour­ney might not be per­fect­ly fit­ted to all agile good prac­tices. But, hey! even a splen­did but­ter­fly is an ugly larve in its first days of life.

So, imag­ine that a soft­ware com­pa­ny has decid­ed to migrate from a clas­si­cal project man­age­ment mod­el to Agile soft­ware devel­op­ment. And, to be more specif­i­cal­ly, they choose Scrum. Among many things that are chang­ing, some of the roles with­in the project teams are dis­ap­pear­ing. But what do I say?! ALL roles are dis­ap­pear­ing and some new ones are cre­at­ed from scratch. Peo­ple need to move from the old role to the new one and this is def­i­nite­ly not a walk in the park.

Think about the Project Man­agers. In the old orga­ni­za­tion they were the mighty emper­ors of each project, decid­ing who does what and by when. They were enti­tled – per­fect­ly legit­i­mate – to allo­cate tasks and almost exclu­sive­ly com­mu­ni­cate with all stake­hold­ers, while the team was just a hand­ful of resources, doing their job to accom­plish the project objec­tives. In the new orga­ni­za­tion what role could a for­mer Project Man­ag­er play?

Some may say that (s)he could become a Scrum Mas­ter. I would­n’t strong­ly dis­agree, but I would advise care­ful­ness. Yes, it is pos­si­ble, but usu­al­ly such a tran­si­tion is not that easy. And if you take a look on the job descrip­tions of a clas­si­cal Project Man­ag­er and of a Scrum Mas­ter, you can eas­i­ly under­stand why. It takes time to switch your mind­set from com­mand and con­trol to empow­er and facil­i­tate. And – in my expe­ri­ence – some peo­ple nev­er suc­ceed this per­son­al trans­for­ma­tion. Sad, but true.

The tran­si­tion from Project Man­ag­er to Prod­uct Own­er seems to be more con­ve­nient and nat­ur­al. You still have a lever­age on the product/project objec­tives and on its back­log, you decide on pri­or­i­ties and you accept or reject the incre­ments pro­duced by the team. Much more famil­iar job for a Project Man­ag­er, isn’t it? Appar­ent­ly this is the per­fect move that a Project Man­ag­er can make in such a sit­u­a­tion. But the dev­il hides in the details.

The well-trained reflex­es of a Project Man­ag­er – espe­cial­ly of a good one! — are not yet dead. They reap­pear every now and then. In sprint reviews, when (s)he might be tempt­ed to change the accep­tance cri­te­ria of a fin­ished user sto­ry, just to add new con­di­tions, because in the past (s)he was allowed to do so. Or dur­ing the sprint, when slip­ping some new “urgent” tasks in the sprint back­log would appear per­fect­ly nor­mal – is for the sake of the project suc­cess, isn’t it? Or in sprint plan­ning when (s)he might feel the temp­ta­tion to sug­gest the esti­ma­tion in sto­ry points of an user sto­ry or the name of the per­sons that should be assigned to work on it. And the bad news is that the team – which used to inter­act with this per­son as a Project Man­ag­er not so long ago – might not even notice the vio­la­tion of agile prin­ci­ples. It seems so nat­ur­al, so con­sis­tent with the past!

So, how do you help the new Prod­uct Own­er and the team to avoid this trap? Well, unfor­tu­nate­ly there is no Swiss-army knife solu­tion that will solve any prob­lem of this type. But I can sug­gest here a pos­si­ble approach to make sure that the team is han­dling the assign­ment of sto­ries and tasks by them­selves. Short notice: I am refer­ring here to teams that – for any valid rea­son – are doing this assign­ment of sto­ries and tasks in the sec­ond part of the sprint plan­ning, after esti­mat­ing the size of each sprint back­log item¹. So, here it is:

Dur­ing the sec­ond part of the plan­ning, after fin­ish­ing the esti­ma­tion of user sto­ries, the team needs to decide what is the com­mit­ment for the next sprint. Of course, the veloc­i­ty of pre­vi­ous sprints is a good guid­ance, but there are also oth­er things to con­sid­er. When a team is new to agile (as I stat­ed in the begin­ning of this post), team mem­bers might feel a bit inse­cure to quick­ly decide how many sto­ries they should com­mit to. Also, when com­pe­ten­cies are not even­ly spread in the team and team mem­bers are more spe­cial­ized in some tech­ni­cal areas, this is a not-so-bad prac­tice to make sure that every­one’s work capac­i­ty is ful­ly covered.

As a Scrum Mas­ter or Agile Coach, grab sev­er­al flipchart paper sheets and, using a mark­er, divide each of them ver­ti­cal­ly by the num­ber of weeks of your sprint. Also divide them hor­i­zon­tal­ly in 2 or 3 columns. Each team mem­ber will get one col­umn, so make sure that you have enough flipchart sheets with columns for every­one. Stick the flipchart sheets on a wall, to cre­ate a big “cal­en­dar”.

Ask the team mem­bers to write their names on top of a col­umn. If there are some sta­ble sub-teams that are usu­al­ly work­ing togeth­er, they might use adja­cent columns. Then ask them to grab some post-its and to write the sto­ries that they will take care of², and stick the post-its on the flipchart, in their own col­umn. First sto­ry they will han­dle should be on the top of the col­umn, the next should be low­er, on an imag­i­nary row that cor­re­sponds to the day of the sprint when that sto­ry is sup­posed to be start­ed. For a team of nine mem­bers and a three-week sprint it should some­thing like this (imag­ine that the yel­low post-its are user sto­ries and/or tech­ni­cal tasks):

Some agile evan­ge­lists may say that this is not the spir­it of Scrum. They would be right, aca­d­e­m­i­cal­ly speak­ing. Some may even call this an infa­mous plan­ning tool, remind­ing about the water­fall approach. To a cer­tain point, it’s true. But I don’t think that water­fall project man­age­ment is evil. I think that all kinds of project man­age­ment are sets of tools that you use for a pur­pose. And this par­tic­u­lar one I con­sid­er to be a very prac­ti­cal tools that helps a team to move toward agile, because:

• it gives the team mem­bers a smooth tran­si­tion from the for­mer process­es to agile process, through a tem­po­rary compromise;
• it helps the team mem­bers to learn what com­mit­ment real­ly means;
• it helps the team mem­bers to learn how to assess their capac­i­ty as accu­rate as possible;
• it helps the team mem­bers to coör­di­nate tandems activ­i­ties so the team capac­i­ty is ful­ly used;
• it shows to every­one what self-orga­ni­za­tion actu­al­ly is;
• it pro­motes trans­paren­cy and visibility;
• is pro­vides a very good addi­tion­al guid­ance for dai­ly scrums, where every­one can posi­tion his cur­rent sta­tus against the ini­tial estimation;
• it helps the PO (the for­mer project man­ag­er) to resist the temp­ta­tion of “inno­cent” inter­fer­ence with­in the assign­ment of tasks and stories;
• it reas­sures the PO (the for­mer project man­ag­er) that the com­mit­ment is real­is­tic, through a tool that (s)he eas­i­ly understands;
• it builds trust between PO (the for­mer project man­ag­er) and the devel­op­ment team.

Should the team stop at a cer­tain point in time to prac­tice that? Of course. Because is a tem­po­rary com­pro­mise. When? The soon­er, the bet­ter. When most of these goals where reached. When the larve is ready to become a butterfly.

1. One valid rea­son that I fre­quent­ly encounter is the uneven dis­tri­b­u­tion of knowl­edge and com­pe­tence inside the team. Some tasks can be exe­cut­ed only by some team mem­bers. Until they learn from each oth­er, eg. through pair pro­gram­ming, the only option to con­tin­ue deliv­er­ing is to assign the right tasks to the right per­sons. [↩]
2. They should select them from the ones pri­or­i­tized by the PO and esti­mat­ed by the team. [↩]