Is there a way of building the common brain of an Agile team? To understand it better I went through an imaginary trip around all Scrum ceremonies, from the beginning of a new product to its. Let’s walk it together.
So there’s the start of the project. Here are the Product Owner, the Scrum Master and the Development Team. An Architect has joined the team to help them in this new beginning. And there’s the product backlog, not so clear for the moment, with a lot of epics that need to be further detailed and split in stories.
The Product Owner comes in front of the team and shows them the existing stories and epics: guys, we want to build a taxi ordering application. I already prepared the stories about the customer account in our application, and the taxi driver account also – they will need them to authenticate and start using it. Also you can see these stories about how a customer places an order and the taxi driver is accepting it and thus a sort of a contract is concluded between the two of them. We’re going to see what else we will develop, but for the time being let me just say that I am thinking about these epics: online payment of the taxi, chat with taxi driver while waiting, following the taxi on a traffic map, customer feedback for the quality, maybe some integration with Waze.
The Development Team asks some more questions about some additional details, like: can the customer or the taxi driver cancel the order after accepting it? Online payment will be done how? Then the Architect explains that the technical solution will have a back-end written in Java and running under Tomcat, using a PostgreSQL database, while the 2 front-ends, one for the customer and the other for the taxi driver, will be developed in Python. He lets the team know that he’s in favor of using web services. And that he’s still considering what is the best option for balancing, but for the time being those details are enough to start.
And the team asks also some questions: will it run on Android and iPhone? How about Microsoft phones, will they be supported? How many concurrent users do we expect? Which mapping service are we using, google or openlayers? Should we use material design UI? And then there is this rough estimation round and the Scrum Master makes some calculations and finds out that in two months the first version could be released, although is not yet a minimum viable product. But he’s happy and congratulate everybody: great project start!
I’ve seen so many times this scenario. Everyone has seen the backlog, everyone has seen the draft technical concept. So there ready to start working. But do they share the same understanding?
Do they all have the same understanding about the product? Do they all have the same understanding about customer expectations? Who is the customer? Why are they building an Yet Another Taxi Ordering application? Aren’t there enough on the market already? What will differentiate theirs from the other? What kind of need will they fulfill that was not fulfilled so far? What’s in the mind of the PO that needs to be also in the mind of each Development Team member? Have they made the same assumptions when estimating and thinking about how this application will be developed? What’s in the mind of each development team member that needs to be shared with the others and – especially – with the PO?
While talking about the backlog and making the first estimations, were they worried about the same risks? Which of them needs to be taken into serious consideration? Maybe the database is too slow for this kind of application? Maybe Python is not the most productive way to develop the frontend? Maybe they don’t have enough expertise with mapping services? Which one is valid? What’s in the mind of each development team member and needs to be shared with others?
And there’s the planning session. Stories are taken by priority, discussed, estimated and put in the sprint backlog. This sprint they commit to burn a number of story points. And the planning goes to the next phase, where they should split stories in tasks, but team is eager to go back to coding. There is no need to discuss so many details, says the team. We all know which stories we should take the responsibility: him the on referring to the web services, her the ones that deal with the frontend and him the database part. So why losing precious time and not just starting to work? And the Scrum Master is happy to see such a determination to deliver: great hard-working team!
But when planning means estimations and estimations are based on knowledge. If such a specialization exists inside the team, how are they able to assess correctly the effort and complexity of a story? Or is it just one of them that knows and the others are just following him? Then how about that balance that occurs when several informed opinions are confronting? Why are they even estimating collectively? How can they have the same understanding about the solution they build if there are areas completely unknown? What happens if one of them is unavailable, who can replace that team member?
What is the meaning of commitment for the team? Can anyone consciously commit to something that he/she does not understand? Or is it that each member commits for his own part, but not for the entire sprint backlog? How about their common way of thinking?
Here is the daily scrum and its famous three questions: what have you accomplished since last daily, what are going to accomplish until the next daily and what are the impediments that stand in your way. Since there are no subtasks, but stories on the board, each of the development team member says something like: I worked on story X but not finished ‘cause it takes longer than one day and I will continue to work to story X. And there are no impediments so far. Super, says the Scrum Master, lets move on with our work.
But that was one of those moments when the team is supposed to become – at least for some moments – as one. Do they share the same understanding about the progress? Definitely no. How could they understand if they’ll burn everything if several days the status of each story is “in progress”? How much in progress? 20%, 80%, 5%? Compared to the time elapsed, is it developing faster or slower than estimated? Where is the collective reasoning of the team, the common brain that they should use in these moments?
And, since there is no understanding 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 hiding under the carpet some issues that he’s having because he’s ashame to admit not knowing 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 weaknesses and be helped by someone with less seniority…
But where is the common understanding that the team needs to share? Where is their common set of norms and values?
At the end of each sprint there is the retrospective. The team gathers and thinks about what needs to be improved. They’re committing every sprint and burning all the stories. They keep the dailies. Planning has sometime flaws, but hey! thats what estimation is. Is not pharmacy. Every now and then the velocity drops because QA cannot finish testing – maybe we can get some more QA guys. No we can’t, there aren’t any available, says the SM. Ok, then that’s it. There is nothing that we can improve. Maybe we change a bit the structure of our SVN – I read an article about this and seems there are some improvements that we can make. Great, says the SM, that is the retrospective about: improving the process.
Not a word about the excessive specialization of roles within the development. Not a thing about the fact that everyone works 7 or 8 days to finish own stories and in the last 2 days they just drop everything into the lap of the QA saying: please test this! Changing this means to change the personal way of doing things, sharing the stories with colleagues, being transparent with your progress and issues. What are the values of the team? Do they include an open mind for change, collaboration and transparency?
Does the team have a written policy? Are there any decisions taken into the retrospective that go into that policy? In other words, does anybody really care about the norms and values that the team is sharing and upon which they have a common understanding?
Everything that I imagined during this voyage through the ceremonies of a team is not unusual. Is more or less common problems that most of the Agile team have. And quite frequently the effect of these problems are quoted in books and articles that explain why Agile has failed. It has not. Before saying this we need to make sure that we properly practice it, and there is still a lot to do about this.
In the end we all want to develop great software. The success of our products and the speed of their delivery to the market is mainly ensured through inspection and adaptation. This is how we make sure that we follow the customer’s needs, this is how we avoid loosing time and resources in developing useless features.
But the key for sustainable success is still the team. A great team is not the result of a great product, is the other way around. So creating a real Scrum team puts the premises of future success. How do we do that?
Transparency. Not only by making things visible. But by helping the team to develop its own common brain, its own common way of thinking. By encouraging them to share their individual thoughts in order to build the team consciousness, its norms and values. By helping them to prove themselves that a collective mind is wiser that the sum of their individual wisdom.
Inspection and adaptation are the key elements for a successful software product. But transparency is the key element for the team. Transparency is the fabric of the Agile brain great teams and keeps them in top shape. Isn’t this what we should try to achieve every day?