Great! Your business has decided to move from a Waterfall paradigm to Agile Scrum and now you’re waiting patiently for the benefits to kick in. You’re hoping your Scrum teams start self-organizing soon and are inventively solving customer problems faster with better efficiently. You’re also waiting for the team to become major contributors to the business decision process based on their intimate knowledge of customers and their pains. And you’re waiting … Still waiting …
You ask yourself what’s holding the team back. The Scrum Master has trained the development team on the agile manifesto including the principle:
“The best architectures, requirements, and designs emerge from self-organizing teams.”
The Scrum Master has also trained the development team on self-organizing as described in the Scrum Guide:
- defining the Scrum Team: “The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. … The team model in Scrum is designed to optimize flexibility, creativity, and productivity.”
- defining the Development Team role: “Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.”
- defining the Scrum Master role: “The Scrum Master serves the Development Team in several ways, including: Coaching the Development Team in self-organization and cross-functionality.”
- defining the Sprint Planning Meeting: “The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint…By the end of the Sprint Planning meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.”
- defining the Daily Scrum: “Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated increment in the remainder of the Sprint.”
It’s clear the Scrum Guide expects the Scrum team, and more specifically, the development team, be a self-organizing body. It’s also clear that training people that they should be self-organizing isn’t always enough. The organization must want and the businesses actively support the team becoming self-organizing.
Getting a Scrum team to self-organizing is hard primarily due to the fuzzy nature of what ‘self-organizing’ actually means. If you were to ask 5 people to define what a ‘self-organizing’ software team is you’ll probably get 5 different answers. But even in that result some truths are seen, it’s not how I define self-organization, it’s how the team defines it.
In Nitin Mittal’s Scrum Alliance article, “Self-Organizing Teams: What and How“, he describes 5 essentials of self-organizing teams:
- Competency: Individuals need to be competent for the job at hand. This will result in confidence in their work and will eliminate the need for direction from above.
- Collaboration: They should work as a team rather than as a group of individuals. Teamwork is encouraged.
- Motivation: Team motivation is the key to success. Team members should be focused and interested in their work.
- Trust and respect: Team members trust and respect each other. They believe in collective code ownership and are ready to go the extra mile to help each other resolve issues.
- Continuity: The team should be together for a reasonable duration; changing its composition every now and then doesn’t help. Continuity is essential for the team.
I was once Scrum Master to a team during which I did training on the advantages of setting priorities, of sharing work, and of getting stuff done. The team was very good at their jobs and helped each other out whenever asked. However, I didn’t realize helping out had a limit until one day at the daily standup when the person working the most important story, the highest priority story, was out. I asked who could pick up the work to move it forward? No one raised their hand. One of the quietest people then said it was massively inefficient to have someone else pick up the work. For me personally this was a sad, sad day. After talking priorities, talking of sharing work, talking of getting stuff done, and talking how the team best works together, the team couldn’t let go of their own personal task responsibilities. The team couldn’t find it in themselves to embrace a team responsibility of getting the most important work done first. A self-organizing team would have kicked into a self-managing mode and re-allocated work so the highest valued work could continue. At the end of the standup, team members felt a stronger bond to their own work in areas they were most comfortable with than to the whole. It wasn’t competency but rather motivation that was holding the team back.
What makes it so hard to motivate a team to feel responsible for the whole? When a business pushes individual roles & responsibilities over team commitments or when survival and blame permeates an environment, it’s very unlikely that the team will move beyond the ‘forming’ stage (team members sticking to what they know best individually and doing what they feel most comfortable with).
In some business environments, the dip in productivity while transitioning from ‘Forming’ to ‘Storming’ is unacceptable. This would be especially true in a strong hierarchical or Command & Control environment where those in the hierarchy are held responsible (accountable) for team performance. If the business is clinging too tightly to a hierarchical and Command & Control environment, the likelihood of birthing self-organizing teams is diminished. At one company I was at, one of the most senior software engineers was a team lead. The team was always seeking his approval for any decisions and if the manager thought otherwise, the team changed their ideas to conform. This wasn’t the worse thing to happen but it was heavily reliant on the team lead always being right. A consequence of this was lower scores on the company’s engagement evaluations especially around empowerment and feelings of trust.
It’s worth the attempt
Adopting Agile and Scrum will not automatically cause people or businesses to change. For Agile and Scrum to make a positive impact, people will need to see that they need to change their own behavior. It’s possible to see that in an environment where individual knowledge or individual skills are the most sought after commodity, Agile may not be the right tool. In a business where rigid hierarchies and Command & Control are dominate, it may be a long journey to establishing self-organizing teams but certainly worth the effort.
David Ticoll in his Harvard Business Review article, “Get Self-Organized”, states that, “It would be difficult and risky—even foolhardy—to try to wholly transform a hierarchical business model into a self-organizing one. But the potential of self-organizing systems to enhance competitiveness is becoming clear to managers of some conventionally structured businesses.”
David Tricoll further states, “Today, the ability to stream complex, real-time information to the front line gives hierarchical companies greater power than ever to exploit self-organization.”
One approach might be getting the team to participate in business events such as creating business plans, working with customers and users, and respecting them as contributors to business success. Teams with greater insights to business and customer problems are more likely to be engaged with solving these. To be quick and competitive, businesses must relinquish control to the teams in the front lines and the teams must be willing to accept the responsibility. When the business leaders and development teams shared these insights, I’ve seen the development teams rise beyond their own specialties to rally around both the customer and the business.
For a team to become self-organizing, it will take more than a business to want and support it, it requires the team itself to see advantages in self-organization. If you’ve ever seen how an assembly line worked in days gone by, you’ll see an environment where self-organization would have been detrimental. Your job was to put nut ‘A’ onto bolt ‘B’ period. Repeat this for 8 hours a day, 5 days a week and you got paid pretty well for what to some people would be the most boring job on earth. The business wasn’t holding out hope that the workers would self-organize and the workers had no motivation to do so. In the factories, piecework was common. Workers were told what to do, how to do it, and when to do it. Software development is not piecework, if it were, robots would be doing it today. It is knowledge work where thinking both inside and outside the box are assets to the business.
In the situation above when a team member is absent, the moment the remaining team members decided that doing and completing individual tasks is more important, all advantages of self-organization were lost. Instead of adding value for the customer and business, the team had elected to follow a plan. The decision essentially comes down to: I have my own work to do and don’t have time to do yours.
To some, this kind of dedication is how you advance in the company. However, if the company were to emphasize customer and business value of work being done, it would cause a fundamental shift in team thinking, from doing tasks to getting the highest value work done quickly. When the business puts emphasis on value, the team is more likely to devote their combined efforts to achieving value. It would come to pass that even when one of their numbers is absent, progress won’t stop, although it may slow down. If the team is accepted as a fully participating business team member, not just a partner, the team will genuinely feel the success of the business is also their own success and act accordingly.
To me, one of the principle tenets of Agile is the team. The great power of Agile comes from a group of intelligent people working as one. Collectively they are more knowledgeable than any one individual although the shared experience may be less. To ignite the team requires the business to openly give the team responsibility and accountability for the outcomes of each iteration. For the business to move forward and empowering the team, they would need to establish safe boundaries from which the team can safely operate in.
When business leaders, product owners, and scrum masters attend the daily standup, what’s more important than hearing team members say,
“I completed task <x> yesterday”,
is hearing them say,
“we added <some> value to the product yesterday”.
The role of managers and customers on the self-organizing team
- Senior management at the teams’ organization must be able to provide freedom to the teams so that they can self-organize themselves.
- Customers must support the teams by being actively involved in the development process through providing regular requirements, clarifications, and feedback as required.
“Self-organizing Agile teams … require organization structures that are informal in practice, where the boundaries of hierarchy do not prohibit free flow of information and feedback. In an informal organizational structure, the senior management is directly accessible by all employees (maintaining an ‘opendoors’ policy), and accepts feedback—both positive and negative.”
– from “Supporting Self-Organizing Agile Teams What’s Senior Management Got To Do With It?” by Rashina Hoda, James Noble, and Stuart Marshall
For the business leaders, giving development teams insights to both business and customers plus giving development teams space to operate, will motivate teams to accomplish amazing things. When the business states these are our goals and asks the team to solve it in the best manner possible, you’re likely to see a team self-organize to meet the goals. No one goes to work hoping they fail.
When the business has a strong hierarchical and Command & Control environment, moving a team toward self-organizing is made more difficult but not impossible. Building a bridge of trust and respect is essential. By establishing a strong partnership between the business and development team, followed by full membership, the team can exercise their collective knowledge and capabilities to contribute to business successes.
In the end, it’s a mutual effort on the part of both management and the development team to become self-organized. It will probably be a bumpy ride along the way but with a clear goal as a guide, both should arrive at the destination together.