Organic Scrum

Whenever I step into a coaching engagement, one of the first pieces of information I track down is where the initiative for the move to Scrum originated. The answer is invariably one of three: a top-down initiative; a move from the middle outward; or an organic, bottom-up approach. The first two types present challenges of their own, of course, but the third, what I have taken to calling Organic Scrum, presents many special circumstances and difficulties not generally found in the first two.

The usual path into an Organic Scrum setting is that a functional manager or technical lead either learns about Scrum or has been in a Scrum/Agile environment previously. The leverage is usually a troublesome project that is either in progress or on tap. The troublesome part of the proposed pilot project is that it is either stuck or has already failed at least once using traditional project management practices and needs to be restarted afresh. Either of these situations produces the right mix of management desperation and therefore openness to new ideas to make an Organic Scrum push possible. And despite the deck being stacked so unfavorably, troubled projects are often ideal candidates for Scrum.

Under the best of circumstances, the person championing the move to Scrum is able to coax management at a higher level to devote some resources to training and coaching, which is, of course, where I usually enter the scene. Under less favorable circumstances, the entire Scrum transition ends up without management support or resources and takes on the character of an insurgent movement. I'll try to cover insurgent Scrum in a later posting. Now, back to Organic Scrum....

The greatest challenges in an Organic Scrum environment, both for me as coach and for the people who want to get Scrum moving, are setting up a truly cross-functional, self-organizing, self-managing team and getting some level of cooperation from the business so that the team can work from a prioritized backlog. Let's examine each issue separately.

Most US companies are organized along functional lines, creating the very skill silos W. Edwards Deming decried over 60 years ago. Unless the silo walls can at least be bent or stretched, the nascent Scrum team will not be able to deliver a working product increment each Sprint. The major silo division is almost always between development and QA, although there can be others, equally insidious, that divide development into specialized segments that maintain a mutual over-the-wall mentality. Architecture and design also commonly form another silo. Punching holes in these functional silos is the first priority in an Organic Scrum movement. Breaking the shared-resource organizational model -- the "matrixed" organization -- is a common follow-on activity. The members of the Scrum team must be allowed to focus on the project Scrum is supposed to deliver. Failure in either of these areas generally proves to be a hard stop in the development of Organic Scrum.

Assuming the silo walls can be made permeable enough to allow the formation of a cross-functional product team and that the company allows the team members to exit the matrix, the next big step is to find a courageous ScrumMaster to support self-organization/self-management and protect the team from the inevitable distractions. The new cross-functional team members almost always report to different functional managers, yet as members of a self-organizing, self-managing Scrum team, that reporting relationship must change. It is often the ScrumMaster's unpleasant duty to inform various functional managers -- and sometimes higher-level managers as well -- that no one gives orders here anymore. The team commits to work and delivers on its commitments however the team members collectively see fit to do so.

A common area of team distraction is outside interference with the team's Sprint work in the form of requests to do something unrelated to the Sprint. It is not unusual for this form of interference to come from the very same functional managers who garner the ScrumMaster's attention for other reasons. It's really not the functional managers fault -- they have other projects that need to get done so they call on their direct reports, assigning work as they always have. The problem is that distractions are a common source of a team's failure to deliver on Sprint commitments. Delivering on Sprint commitments is the Scrum team's only way to build trust with the organization and with the business. Finding the right person to take on the ScrumMaster role is so vital that failure in this area also constitutes a hard stop.

The final major ingredient needed to grow Organic Scrum is cooperation of the business. When I coach in Organic Scrum situations, I invariably spend a huge amount of time and energy working with the business to help build an understanding of what the Scrum team is trying to do, why they're doing it, what the benefits are for the business, and how the business plays a vital role in making it all possible. In most cases the benefit side of the equation is an easy sell: the business gets a fully tested, working product increment at the end of each Sprint. The required input from the business can be more difficult to sell, however. It can be difficult for people schooled in traditional project management to let go of the detailed requirements document, delivered to development before a line of code gets written. It can also be difficult for traditional project managers to give up the perception of control that comes from telling people what to do and how to do it. If we can overcome those hurdles, the business must then at least agree to provide a Product Owner for the team or work with a Product Owner the team designates. The business must also agree to prioritize a backlog from which the team can work, to define acceptance criteria (the all-important definition of "done") for each user story, and to review the output of each Sprint.

The business can certainly be skeptical of the idea of Scrum, but must play by the rules, even if grudgingly, in order for Organic Scrum to have a chance to succeed. When I coach, I emphasize the inherent trust-building that takes place when a team commits to a Sprint backlog and then delivers on that commitment, Sprint-after-Sprint. As long as the business is more interested in results than in control, trust is the Scrum team's most powerful incentive to continue and indeed expand Scrum within the organization.

All for now....

...-.-