The fabric of the Agile brain

Is there a way of build­ing the com­mon brain of an Agile team? To under­stand it bet­ter I went through an imag­i­nary trip around all Scrum cer­e­monies, from the begin­ning of a new prod­uct to its. Let’s walk it together.

So there’s the start of the project. Here are the Prod­uct Own­er, the Scrum Mas­ter and the Devel­op­ment Team. An Archi­tect has joined the team to help them in this new begin­ning. And there’s the prod­uct back­log, not so clear for the moment, with a lot of epics that need to be fur­ther detailed and split in stories.

The Prod­uct Own­er comes in front of the team and shows them the exist­ing sto­ries and epics: guys, we want to build a taxi order­ing appli­ca­tion. I already pre­pared the sto­ries about the cus­tomer account in our appli­ca­tion, and the taxi dri­ver account also – they will need them to authen­ti­cate and start using it. Also you can see these sto­ries about how a cus­tomer places an order and the taxi dri­ver is accept­ing it and thus a sort of a con­tract is con­clud­ed between the two of them. We’re going to see what else we will devel­op, but for the time being let me just say that I am think­ing about these epics: online pay­ment of the taxi, chat with taxi dri­ver while wait­ing, fol­low­ing the taxi on a traf­fic map, cus­tomer feed­back for the qual­i­ty, maybe some inte­gra­tion with Waze.

The Devel­op­ment Team asks some more ques­tions about some addi­tion­al details, like: can the cus­tomer or the taxi dri­ver can­cel the order after accept­ing it? Online pay­ment will be done how? Then the Archi­tect explains that the tech­ni­cal solu­tion will have a back-end writ­ten in Java and run­ning under Tom­cat, using a Post­greSQL data­base, while the 2 front-ends, one for the cus­tomer and the oth­er for the taxi dri­ver, will be devel­oped in Python. He lets the team know that he’s in favor of using web ser­vices. And that he’s still con­sid­er­ing what is the best option for bal­anc­ing, but for the time being those details are enough to start.

And the team asks also some ques­tions: will it run on Android and iPhone? How about Microsoft phones, will they be sup­port­ed? How many con­cur­rent users do we expect? Which map­ping ser­vice are we using, google or open­lay­ers? Should we use mate­r­i­al design UI? And then there is this rough esti­ma­tion round and the Scrum Mas­ter makes some cal­cu­la­tions and finds out that in two months the first ver­sion could be released, although is not yet a min­i­mum viable prod­uct. But he’s hap­py and con­grat­u­late every­body: great project start!

I’ve seen so many times this sce­nario. Every­one has seen the back­log, every­one has seen the draft tech­ni­cal con­cept. So there ready to start work­ing. But do they share the same understanding?

Do they all have the same under­stand­ing about the prod­uct? Do they all have the same under­stand­ing about cus­tomer expec­ta­tions? Who is the cus­tomer? Why are they build­ing an Yet Anoth­er Taxi Order­ing appli­ca­tion? Aren’t there enough on the mar­ket already? What will dif­fer­en­ti­ate theirs from the oth­er? What kind of need will they ful­fill that was not ful­filled so far? What’s in the mind of the PO that needs to be also in the mind of each Devel­op­ment Team mem­ber? Have they made the same assump­tions when esti­mat­ing and think­ing about how this appli­ca­tion will be devel­oped? What’s in the mind of each devel­op­ment team mem­ber that needs to be shared with the oth­ers and – espe­cial­ly – with the PO?

While talk­ing about the back­log and mak­ing the first esti­ma­tions, were they wor­ried about the same risks? Which of them needs to be tak­en into seri­ous con­sid­er­a­tion? Maybe the data­base is too slow for this kind of appli­ca­tion? Maybe Python is not the most pro­duc­tive way to devel­op the fron­tend? Maybe they don’t have enough exper­tise with map­ping ser­vices? Which one is valid? What’s in the mind of each devel­op­ment team mem­ber and needs to be shared with others?

And there’s the plan­ning ses­sion. Sto­ries are tak­en by pri­or­i­ty, dis­cussed, esti­mat­ed and put in the sprint back­log. This sprint they com­mit to burn a num­ber of sto­ry points. And the plan­ning goes to the next phase, where they should split sto­ries in tasks, but team is eager to go back to cod­ing. There is no need to dis­cuss so many details, says the team. We all know which sto­ries we should take the respon­si­bil­i­ty: him the on refer­ring to the web ser­vices, her the ones that deal with the fron­tend and him the data­base part. So why los­ing pre­cious time and not just start­ing to work? And the Scrum Mas­ter is hap­py to see such a deter­mi­na­tion to deliv­er: great hard-work­ing team!

But when plan­ning means esti­ma­tions and esti­ma­tions are based on knowl­edge. If such a spe­cial­iza­tion exists inside the team, how are they able to assess cor­rect­ly the effort and com­plex­i­ty of a sto­ry? Or is it just one of them that knows and the oth­ers are just fol­low­ing him? Then how about that bal­ance that occurs when sev­er­al informed opin­ions are con­fronting? Why are they even esti­mat­ing col­lec­tive­ly? How can they have the same under­stand­ing about the solu­tion they build if there are areas com­plete­ly unknown? What hap­pens if one of them is unavail­able, who can replace that team member?

What is the mean­ing of com­mit­ment for the team? Can any­one con­scious­ly com­mit to some­thing that he/she does not under­stand? Or is it that each mem­ber com­mits for his own part, but not for the entire sprint back­log? How about their com­mon way of thinking?

Here is the dai­ly scrum and its famous three ques­tions: what have you accom­plished since last dai­ly, what are going to accom­plish until the next dai­ly and what are the imped­i­ments that stand in your way. Since there are no sub­tasks, but sto­ries on the board, each of the devel­op­ment team mem­ber says some­thing like: I worked on sto­ry X but not fin­ished ’cause it takes longer than one day and I will con­tin­ue to work to sto­ry X. And there are no imped­i­ments so far. Super, says the Scrum Mas­ter, lets move on with our work.

But that was one of those moments when the team is sup­posed to become – at least for some moments – as one. Do they share the same under­stand­ing about the progress? Def­i­nite­ly no. How could they under­stand if they’ll burn every­thing if sev­er­al days the sta­tus of each sto­ry is “in progress”? How much in progress? 20%, 80%, 5%? Com­pared to the time elapsed, is it devel­op­ing faster or slow­er than esti­mat­ed? Where is the col­lec­tive rea­son­ing of the team, the com­mon brain that they should use in these moments?

And, since there is no under­stand­ing of the progress, how do they know when one of them needs to be helped? How can they make sure that one of them is not hid­ing under the car­pet some issues that he’s hav­ing because he’s ashame to admit not know­ing how to solve them, although he’s a senior? Cause look, the bright junior has always some strange, wild ideas that seem to work almost every time – he can’t expose his weak­ness­es and be helped by some­one with less seniority…

But where is the com­mon under­stand­ing that the team needs to share? Where is their com­mon set of norms and values?

At the end of each sprint there is the ret­ro­spec­tive. The team gath­ers and thinks about what needs to be improved. They’re com­mit­ting every sprint and burn­ing all the sto­ries. They keep the dailies. Plan­ning has some­time flaws, but hey! thats what esti­ma­tion is. Is not phar­ma­cy. Every now and then the veloc­i­ty drops because QA can­not fin­ish test­ing – maybe we can get some more QA guys. No we can’t, there aren’t any avail­able, says the SM. Ok, then that’s it. There is noth­ing that we can improve. Maybe we change a bit the struc­ture of our SVN – I read an arti­cle about this and seems there are some improve­ments that we can make. Great, says the SM, that is the ret­ro­spec­tive about: improv­ing the process.

Not a word about the exces­sive spe­cial­iza­tion of roles with­in the devel­op­ment. Not a thing about the fact that every­one works 7 or 8 days to fin­ish own sto­ries and in the last 2 days they just drop every­thing into the lap of the QA say­ing: please test this! Chang­ing this means to change the per­son­al way of doing things, shar­ing the sto­ries with col­leagues, being trans­par­ent with your progress and issues. What are the val­ues of the team? Do they include an open mind for change, col­lab­o­ra­tion and transparency?

Does the team have a writ­ten pol­i­cy? Are there any deci­sions tak­en into the ret­ro­spec­tive that go into that pol­i­cy? In oth­er words, does any­body real­ly care about the norms and val­ues that the team is shar­ing and upon which they have a com­mon understanding?

Every­thing that I imag­ined dur­ing this voy­age through the cer­e­monies of a team is not unusu­al. Is more or less com­mon prob­lems that most of the Agile team have. And quite fre­quent­ly the effect of these prob­lems are quot­ed in books and arti­cles that explain why Agile has failed. It has not. Before say­ing this we need to make sure that we prop­er­ly prac­tice it, and there is still a lot to do about this.

In the end we all want to devel­op great soft­ware. The suc­cess of our prod­ucts and the speed of their deliv­ery to the mar­ket is main­ly ensured through inspec­tion and adap­ta­tion. This is how we make sure that we fol­low the cus­tomer’s needs, this is how we avoid loos­ing time and resources in devel­op­ing use­less features.

But the key for sus­tain­able suc­cess is still the team. A great team is not the result of a great prod­uct, is the oth­er way around. So cre­at­ing a real Scrum team puts the premis­es of future suc­cess. How do we do that?

Trans­paren­cy. Not only by mak­ing things vis­i­ble. But by help­ing the team to devel­op its own com­mon brain, its own com­mon way of think­ing. By encour­ag­ing them to share their indi­vid­ual thoughts in order to build the team con­scious­ness, its norms and val­ues. By help­ing them to prove them­selves that a col­lec­tive mind is wis­er that the sum of their indi­vid­ual wisdom.

Inspec­tion and adap­ta­tion are the key ele­ments for a suc­cess­ful soft­ware prod­uct. But trans­paren­cy is the key ele­ment for the team. Trans­paren­cy is the fab­ric of the Agile brain great teams and keeps them in top shape. Isn’t this what we should try to achieve every day?