“Be like water, flow.” - Bruce Lee
Being agile (note agile with a lower-case a) is not about sticking to a prescribed set of principles or methodologies. It’s about minimizing the prescribed set so that you focus on adapting to change. One of the biggest lessons to impart here is that you need to be agile in the sense that you can adapt to how your client works, but not give up on the course you feel is more “right” when you sense something needs to change.
Throughout this piece, you’ll note that I advise against certain things, but I also encourage you to understand the “why” behind your client’s motivations. I tend to be judgemental of client processes when they’re not as efficient as the ones I’m used to, but I also understand that not everything can be improved overnight.
I hope to illustrate how even when you come up against adversity and difficult situations it helps first to take a step back and relate to the client, understand the difference in values, and then try to be the mediator between those opposing values.
The Gig
Not so long ago we were part of a project in which the company decided that they wanted their Scrum teams to adhere to the Scaled Agile Framework and began rolling that out across their organization. Everyone got a JIRA license, a Scrum Coach was added to the team, and they split up into cross-functional teams. The teams were comprised of multiple Product Owners and their direct reports—almost all of whom worked on multiple projects. Lullabot was brought into the mix to help out on just one of these projects: the website.
Before continuing, I’d like to take a moment to reflect on the irony that presents itself when looking at the complexity illustrated in this graphic from the Scaled Agile Framework in the context of the word “agile.” I guarantee this is not what the founders of the Agile Manifesto had in mind.
Compare this to the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Upon introduction to the client, we found that there was a fairly extensive Backlog for the website project already written up as User Stories. Many of these User Stories were incomplete, and there were no other written requirements or specifications although the Product Owners possessed this knowledge and could answer questions we had about a given Story.
Soon after we started, our client’s upper management assigned the team a Scrum Coach from an outside consultancy. Part of the coach’s job was to sit in on our meetings and listen to how the projects were being run and to make suggestions on what should change about how the meetings were run and the projects planned out to adhere to the Scrum methodology.
Longer meetings resulted—some six hours long—in which all members of the team were present to groom the Backlog and plan our Sprints. Sprint iterations grew from two-week intervals to three. Time was spent going through the priorities of the Product Owners, the subsequent User Stories that represented those priorities, sizing the User Stories with Story Points, and planning which Sprint they would go into. Discussions consisted of what Tasks were necessary to accomplish a given User Story, and then estimating the Tasks.
Eventually, as we started to write better User Stories and, in turn, gain a better understanding of the work, we were able to get ahead of the meetings. We planned out the tasks ahead of time for the priorities that were set and the meetings became shorter and shorter.
Through all of this, I gained some significant insight into our client’s company and how it works. I also gained a better understanding of how the Scrum methodology can fit into a larger corporation, and where it does not. I learned where it makes sense to diverge from the process and where it does not. Here are some of my key takeaways from this experience.
Multiple Product Owners on a Scrum Team is Hard
We’re used to just one product being worked on by a team, but our client had a different structure where the team was cross-functional and worked on multiple products at once as well as supported them. Since there were multiple products, there were multiple Product Owners. Each product had a team, but each team member was responsible for multiple products, resulting in divided attention, and sometimes diverging priorities. After working in this way, it’s become clear that it is more ideal, if not practical, to have a team dedicated to one product. Multiple product owners were the key factor in why our Sprint Planning meetings lasted so long. We weren’t planning out what we were going to work on for just one product, but for many.
Competing Priorities
With multiple Product Owners on a team, there is competition for resources and priorities. Which product comes first? Which task for which product does an individual work on first? A developer now has multiple Product Owners to report to, and that means direction from more than one person, which can be confusing and frustrating. More time is spent discussing these priorities and balancing them than if you just had one product and one Owner.
Balancing the Work
Even though teams can be pretty cross-functional, the cross functionality is not always completely balanced. Some people have more knowledge about one system than another and so are more suited to that work. Or perhaps—as in Lullabot’s case—you’re an outside vendor only working on one project. If your overall team already has a target for your maximum amount of story points you can have within a sprint, and most of those points are allotted to a product that is unrelated to your work, you end up with a number of story points that may be less than what you can actually handle for a given sprint for your product. In short, it becomes difficult to make sure everyone has enough work to last them through the end of the sprint. The team spends more time trying to balance the work than doing the work.
In a truly agile scenario, you respond to the needs of the client, and to the bandwidth of the developers. If a developer runs out of work, you can pull that work and begin—not sit around waiting for the end of the sprint—without repercussions.
Estimating the Work
With multiple areas of expertise and responsibilities, it takes more time to estimate the work because the goal is to have everyone understand the work being estimated. Estimation sessions should be limited to just the people with the appropriate knowledge, and as more people become familiar with the work they can lend their input, but time is wasted having people in a meeting who don’t understand the work. That person also tends to feel devalued because their time is being wasted.
For instance, in this case, we have multiple products being worked on. In a sprint planning meeting, we have members of each product. Lullabot is one of them, but we’re only part of one product. So while estimation is happening around issues that are relevant to Lullabot’s work, the people in this meeting who have no work at all on the same product are having their time wasted and feeling devalued. By having sprint planning meetings around just one product at a time, you can have only the people who are relevant to the discussions at the meeting and avoid wasting anyone’s time.
People over Process
The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” This resonates with Lullabot’s values—especially Be Human. If a process isn’t working, we change it. We are always on the lookout for opportunities to make more valuable use of our time—Lullabot’s brand of continuous process improvement. Our affinity for efficiency extends to everything we do—whether that’s designing our processes, coding a migration to run as fast as possible, or optimizing the page load of a website. How does that relate to being human? It shows how much we care about our people. We value their time.
Since our first reaction to tedious processes is to cut them up and change them around, it was difficult to keep from trying to change this client’s processes. Considering the client was just starting to understand how Scrum works and to get the various Ceremonies into place, we felt it was more prudent to resist our typical reaction of trying to optimize the processes early on. They were already changing their existing process and had a guide in the form of a Scrum Coach to help them understand and implement this new way of working. Any changes to this process would have been more of a hindrance at this point. We’ve been through this before and can seemingly see into the future around this and where things would need to change to make them more efficient, but without a solid understanding of the Scrum Methodology first amongst the various team members, our words would fall on deaf ears which were already focused on the changes at hand.
“Progress is impossible without change, and those who cannot change their minds cannot change anything.” - George Bernard Shaw
Focusing on helping people understand the changes to their process was where we decided it would be best to spend our time. We let them know that certain things may take a bit longer this way, but we were dedicated to the team learning the new process and adhering to how they wanted to work. In this we established a base of trust and knowledge sharing, helping to position ourselves as experts. We kept the process optimizations in our back pocket for when the team was more solid and knowledgeable and could then make more educated decisions about which processes should change, and which ones should adhere to the typical Scrum methodology being implemented. With an understanding of what work may suffer because of this restructuring, we were now free to focus on the relationship and to meet the expectations of our Product Owner.
In this way, we didn’t take our typical approach of changing the process to help our people but instead focused on helping people understand the process. People understanding the process was the way Lullabot could put the people first and optimize the process later.
Create more Value than you Receive
One of the challenges in working with an inefficient process that cannot be changed is that you’re directly violating that value of efficiency that we hold so dear. When a value is violated, even for a short time, feelings of guilt and remorse set in. If this continues unchallenged and unchanged, apathy can result. You begin not to care about your work because you know you cannot make it as valuable as you know it could be. We want to avoid apathy at all costs. So how do we avoid it when there seems to be nothing we can do, or we’re too tired to continue fighting for our values
A poignant reminder came from one of our Lullabots facing a similar situation.
“…this is a necessary first step in a process, [and we] need to work toward activities that [the client] can look out the window and appreciate…”
This spoke to the need of going through these hoops while the company reorganized the way it works while continuing to strive to find those areas in which Lullabot has become known for improving any project. By sticking to our values and sharing them with others through our work and our daily interactions, we can slowly but surely improve not only the projects we work on but the relationships and by extension the entire team.
Putting such a value on hold even for a short time is difficult, so we’ve tried to find ways to balance it out. Participating in other more lenient projects, passion projects, and taking ‘mental health’ days are just some of the coping mechanisms we employed. But building trust and establishing a solid foundation for your relationship at the beginning is important. Don’t give up on trying to make positive changes to the project, but be patient instead of pushy. Establishing that base will lead to the conversations that need to happen to make your situation better.
Process for Process Sake
Another value of ours as developers is simplicity. We strive not to create complexity for its sake. And when a process is complex, it’s a double whammy. To cope with a tedious process, it helps to understand its origins. You might still resent that it’s a complex process, but at least you’ll understand the thinking behind it, if not the need for it. If you still don’t understand, then perhaps there is room for change. But you have to understand it first to change it.
We advise against doing any process just for the sake of the process in any situation. Strive to understand the why behind the processes being put into place, especially if you think they don’t make sense. In our case, there was always a factor that we weren’t seeing. Typically that factor had something to do with a side of the client’s business that we simply did not fully understand at the time. After it was explained, it became apparent why a process was so complex and why the complexity was deemed necessary. That doesn’t mean we don’t still strive to reduce the complexity. In fact, we look for every opportunity to reduce complexity wherever we see it.
Be Truly Agile
Agility can come in many forms. Agile with a capital “A” has become a “thing” in the business world and in the software world that has connotations that are starting to change the meaning of the word—for some in a negative manner due to the number of meetings and process overhead that can result. Being truly agile—with a lowercase “a”—is a thing of rarity and beauty. Be “agile” in the sense that you are nimble, quick, and alert. Be agile in the sense that you can respond quickly to change but also agile enough to recognize when it isn’t yet time to change a process. Seek to understand first, recommend changes second. Learn about the subscribed Agile methodologies that are out there, and be agile enough to adapt them as necessary to fit the needs of your project.