During my 25 years as a project leader within software development, I’ve collected various memories concerning communication between individuals. Time after time I listen to discussions where the participants are talking past each other. According to my experience, issues in a project usually arise when interacting individuals believe they understand each other, when in reality they don’t. With these observations in mind, the following post will identify probable pitfalls during scaling of Agile development.
In the Manifesto for Agile Software Development, the top value is “Individuals and interactions over processes and tools”. It also says “That is, while there is value in the items on the right, we value the items on the left more”. From my point of view, it’s a balancing between these two, and it’s important not ending up in one way or the other.
Let’s begin with a few examples of situations I’ve witnessed over the years. The first one takes place about 15-20 years ago, where we had not yet introduced prioritized requirements. Actually, there was a list of priorities, however most requirements had the highest priority… A certain developer in the organization was instructed by various “demanders”, and eventually there was a tough dispute concerning wrong priorities. Consequently, the way tasks were communicated to the specific developer was assessed. Since this was the times before implementation of the backlog, instructions were continuously delivered by email, phone as well as in person visits. Had these instructions been congenial, no major issues would’ve arised, however in this case they were conflicting. The developer received no help with the priorities, so he performed the seemingly most important ones first, since it’s impossible to do everything at once. Quite messy, right? The communication assessment generated a list of about 8 different individuals commanding this certain developer, including the development manager, the architect, testers, other developers asking for support as well as other managers..
Another typical example is misunderstandings due to different terminology. The following situation took place only a few weeks ago, in a project where I’m the project manager. Of course, the discussions long, but in short, a senior manager casually asked a developer during lunchtime what he was currently working on, whereupon he responded that we were currently preparing a delivery. The answer confused the senior manager since he wasn’t expecting a delivery now, but rather when everything was finished, which according to the project plan would not occur until several months later. As a result, I received some, according to me, odd questions from the manager, wondering where all of this came from. Various discussions later, it became clear that the word “delivery” has several meanings. The developer meant delivery within the SCRUM terminology, where our goal is to deliver what’s been developed after every sprint. The senior manager, on the other hand, assumed it concerned a customer delivery.
Suspicion of co-workers not performing the right tasks or understanding what must be done is common in large organizations. To enable trust in everyone doing what they can to achieve the goals of the company, the backlog must be transparent. Its’ sole existence and visibility is not enough; everyone must also understand it. During discussions at Ericsson in 2005-2006 concerning the introduction of Agile methods, I witnessed a distrust of the developers from the program management. Not knowing who was doing what but only the responsible team/area was not appreciated. With a specific individual, it is possible to follow and discuss with him/her, whereas in an Agile organization the impression was that the developers could do whatever they liked. The true Agile evangelist would object, claiming that the program managers are always able to attend the Daily SCRUM meeting. However, with 100-150 teams, it’s hard to keep track on time and place. We did not succeed in finding a system for publicly available meeting times, connecting these to specific requirements etc. The connection between roadmap and the separate tasks of the developers could definitely have been better, however no existing tools supported these functions. The program managers were clearly comfortable in being able to micromanage the developers. When setting the developers free, you know what you have but not what you will receive. Personally, I prefer comparing with an either micromanaged or goal managed orienteer. Without any doubt, the potential is better utilized when more responsibility is delegated to the individual. More about this in a future post.
So, what happens when scaling an organization in combination with working Agile? In the first place, it’s important to consider what not being colocated, which is generally seen as preferable, involves. From my point of view, there are several possibilities the team might become distributed. Primarily, not physically being located at the same place. The first thought might be a co worker in one country/city, and another part of the team in another. In reality, I believe troubles already arise when employees are not located in the same room, or even worse in different corridors, never stumbling into each other. Already here, promoting individuals’ interaction is necessary.
Another way of becoming distributed, is from a time perspective. Instead of discussing F2F, documents and emails are exchanged. As a result, the team becomes distributed from a time point of view, suddenly not working towards the same goal. On the contrary, the team members work with different goals, not simultaneously reaching towards the universal goal.
The third way of becoming distributed, concerns team members from different cultures and/or with different mother tongues. This creates a distance between the individuals, worsening the interaction. In this case, the communication between team members decrease if you’re not cautious.
In a growing organization, all three aspects of distributed development will possibly coincide.
When working Agile with only one team, there is a collective backlog. This creates strict priorities, promoting a shared picture of the project. Nevertheless, it’s important that everyone discuss the definition of different backlog items, not only communicating by texts in the backlog. In case there are misunderstandings after all, the feedback comes relatively quickly by delivering to the product owner at the end of a sprint. That is, misconceptions are resolved early, instead of after months of development. Allowing the developer to make his/her own priorities was a big step at for example Telelogic, to solve several issues. Then again, everyone didn’t appreciate the responsibility and decision making. Including all the components a customer might wish was easier for the product owner, ensuring nothing was left out.
Using the Waterfall model might actually be suitable for some projects. Correct management combined with a stable list of requirements, makes it an efficient way of developing predictable software. It’s easily forgotten that Agile is not the most adequate method in all situations. The problem with these Waterfall project isn’t usually the Waterfall method itself, but rather employees of the organization not talking to each other, handing over documents without actually discussing them. As though there was a wall between them. This might be because individuals are placed on different locations or not working with the tasks at the same time. Awareness of these problems mostly helps solve them.
With this in mind, I recognize an impending risk that when shifting to an Agile method of working, we continue handling documents without discussing them. The distribution of the project’s team members must be overcome by promoting, or even imposing, interaction between individuals.
For instance, how does SAFe want us to solve the scaling of Agile development? There are various components but notably SAFe contains 4 backlogs. There is the portfolio backlog, the program backlog, and the team backlog, my interpretation being that SCRUM’s product backlog has been divided into three. Moreover, there is the SPRINT backlog. Each level uses their backlog, and the question is how these can be synchronized in an efficient manner. How are members of the portfolio backlog able to see how the project is proceeding? Is it a virtual backlog, or four physically separated backlogs being updated manually? Containing all the information in an Excel sheet doesn’t make it a backlog; the other day I heard a company referring to it as “Excel Hell”. There is a risk that each employee works within their own backlog, forsaking to actually comprehend each others’ backlogs. A shared backlog obliges employees to interpret what’s stated, henceforth making active choices. Otherwise there is a risk the authors of the portfolio backlog assume the receivers of this information, creating a program backlog does it correctly, similarly on the following level.
What possibilities of promoting interaction during scaling of projects do you suggest? Personally, I recognize a need for a tool, ACT, supporting us in creating different abstraction levels, additionally enabling changes at one level automatically reaching the others. A delay in one out of 100s of team should instantly be flagged at portfolio level, facilitating proceedings when there is still a possibility to affect the result, contrary to the time of delivery. Generally, the management calls for continuous “What if” analyzes. For instance, given that a customer requests a certain functionality, we are able to place it at the top of the backlog, enabling delivery without risking postponing another delivery.
So, is such an Agile Collaboration Tool (ACT) available today? Over the years, I’ve inspected various products claiming to handle larger Agile projects. However, these are based on case management, with a built-in obstacle in transforming them to project management tools, lacking the architecture necessary to solve the issues above. Finally, I’ve found a promising tool, which I will offer more information about in a future post.