In this post, I would like to share my recent experience in a project that failed miserably, mainly due to negligence of the “Individuals and their Interactions” principle.
The first principle of the agile manifesto stresses focus on “Individuals and their Interactions” but unfortunately there is this misconception that this simply means more irrelevant meetings and hollow speeches. I am a big believer that a good agile team must be built on respect, trust and transparency and that communication problems will considerably slow the project and could potentially lead to outright projects’ failure if not tackled swiftly.
Studies of “communication saturation” during one project showed that, when no communication problems exist, teams can perform 50 times better than the industry average. Jeff Sutherland
In my humble opinion, “Individuals and their Interactions” means:
- everyone’s opinion counts regardless of titles and experience
- honesty when communicating with all members of the team all the time - not just a select few
- transparency in all decisions and actions
- all members share a goal and work towards that goal
- team fosters contructive criticism and positive conflict
- all members are expected to defend and help the team
Our team lacked in several of these points, which had a detrimental effect on the project and the team. In the rest of this post I will examine the aforementioned points and describe how not sticking to them affected the project.
Opinions Count
Management interfered with the team and tried to force their ideas. Any team member that expressed an opinion that did not agree with theirs was labelled disruptive and negative. This meant that team members were afraid to voice their concerns and, therefore, the team missed opportunities to improve, individuals were frustrated but suffering in silence, morale dropped and productivity suffered as a consequence.
Honesty
The team was shielded from the business, which is sensible as you do not want your development team to be constantly interrupted and mess with their flow. However, the development team should not be kept in a silo, completely cut-off from the outside world. The team still needs to know the decisions that are being made and the deliverables being promised as there input is invaluable when determining feasibility. Furthermore, this helps in maintaining the focus of the team. In this particular project, we later discovered that the product team, lets just say, were economical with the truth about the state of the project, the commitments and deliverables. That, understandably, had a negative effect on the team as it dealt a great blow to the trust the team had for the product owners. This started a downward spiral that lead to a complete breakdown in communication between the team and product owners.
A Shared Goal
This project had at least three different product owners. One operated behind the scenes while the other two were on completely different pages. The team was getting mixed expectations and ever changing goals. This was so bad that it got to a stage where both were not sure what they want from the team and both pushing the team into completely opposite directions. Time was wasted navigating blind alleys and chasing dead-ends. This was especially evident when the senior product owner went on holiday and gave the reigns to the BA-cum-PO who was involved with the project from the start but was not properly briefed on the direction and priorities. The team ended up spending a whole sprint spiking and implementing a solution for a feature that was never going to be part of the product.
Transparency
The product owner was not part of the team, which I think is crucial in maintaining an open communication channel and ensuring availability and involvement. The product owners were disconnected and distant while the team felt they lacked urgency and were indifferent to the success of the project. They were not there to answer questions about the product nor share its direction with the rest of the team. User stories were not readied for planning and poorly written.
Futhermore, these particular product owners failed to recognize what role they play in an agile project. They took the ‘Owner’ in product owners quite literally. They stopped discussing the direction of the product with the development team and started making decision and coming up with solutions within themselves. The relationship became akin to a military regiment with orders coming from the product owners that no one must dare to question. Naturally, this lead to, among other things, another colossal time waste as they came up with technically unfeasible solutions that the development team, to put it mildly, picked enormous holes in. Ron Jeffries in his excellent book ‘The Nature of Software Development’ posits, and I’m paraphrasing here, that “product owners” should be called “product champions” as the whole agile team should “own” the product.
Positive Conflicts and Comoraderie
Successful teams foster positive conflicts as they are crucial in continuous improvement. They promote healthy debate and push teams to strive to find ways to do things better. This goes hand in hand with constructive criticism. Team members must attempt to keep their egos in check and look at the bigger picture, which is working together as a team to deliver working software that provides value to customers. This was another thing that was not properly managed as every conflict was portrayed as harmful and team members did not accept or handle criticism well. This created a somewhat toxic environment where people started taking it personally and instead of addressing it within the team, they started airing out their dirty laundry to the rest of the business. This had an adverse effect on how the team was viewed and the trust the business had in it.
Conclusion
Instil the right values in a team, set their directions and define their goals but let them work out how to get there. Do not try to micro-manage and treat team members as foot soldiers by enforcing unrealistic boundaries and chains of commands. Engage the team and give them ownership, be transparent and empower them this can do wonders for their motivation and productivity. A motivated and happy team is a productive team. Allow the team to experiment and discover ways to improve and learn.