This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams.
Essential Steps in Implementing Agile Technologies
The Agile movement provides alternatives to traditional project management. Agile approaches help teams respond to unpredictability with incremental, iterative work cadences and empirical feedback. Agilists propose alternatives to Waterfall, or traditional sequential development. — The Agile Movement (edited) [cf. AgileMethodology, 2008]
Scrum is an Agile software development model based on multiple small teams working in an intensive and interdependent manner. The term is named for the scrum (or scrummage) formation in rugby, which is used to restart the game after an event that causes play to stop, such as an infringement. — What is Scrum? [cf. TechTarget, 2007]
When clients ask me to help with implementation of Agile techniques by using Scrum, my first question is: “What do you mean by ‘Scrum’?” Usually, I then hear that the company has its own special version of Scrum (or other Agile technique) because, according to the people with whom I’m meeting, their company is a special case.
First, yes, your company is a special case. Each company is unique and in a special market niche. Second, if you followed the evolutionary approach of improvements in small increments, you have adapted your process to the environment of the company. No two companies are alike. Hence your need for an external consultant to examine the special conditions in your company.
Introducing (and running) Scrum means that you want to change your company according to proven methods. You can’t have your cake (Scrum) and eat it, too (changing Scrum to suit your company)—you can’t improve your company by adapting the Scrum process to your company.
As a consequence, the reality I see all too often is that the company hires a Scrum Master who merely acts as a supporting firefighter, accompanying the former project manager (now “product owner”) and running around the company putting out fires. This kind of extra resource is justified to upper management by pointing to “Agile” and its use in other companies…
WATERFALL · Waterfall is a project management method where a product moves through a number of phases before a final version is finished for release. Compared to Agile, the problem with this method is that it requires additional communication channels between the individual phases and that the time until a team or company gets feedback from a customer is generally much longer.
SCRUM · Scrum is a set of management tools that focuses a project back on the team level and uncovers internal and external impediments of the production process. By reducing communication paths through small, multidisciplinary teams, as well as frequent releases to the customer for review, the probability for project success can be improved even if the scope is not clear from the start. In addition, work is divided into units of fixed lengths (sprints) which helps to plan future sprints with your team working at a sustainable speed.
SPRINT · A sprint is a timespan of one to four weeks within which a certain selection of stories should be finished by the team. Given the fact that the whole team spends 10 percent of the time (depending on the sprint length) planning and reviewing each sprint, the goal is to reach 100 percent completion of all stories while meeting the project’s quality standards and without overtime. Like a marathon runner needs to carefully plan her energy, planning a sprint requires very good estimation skills by the teams.
SCRUM MASTER · The Scrum Master controls the Scrum process. Besides proactively identifying and removing impediments to the process, the Scrum Master also supports the team in meetings as a moderator and individually in personal talks. The Scrum Master also stands up against outside influence on the process, ideally by propagating the Agile idea throughout the organizations and by explaining why certain restrictions are necessary for the overall project success.
PRODUCT OWNER · The product owner is part of the Scrum team and represents the stakeholders. The main task is stakeholder management as well as having a deep understanding of what the project is about and being able to make decisions. A product owner fills and prioritizes the backlog, keeping the complexity estimations of the team in mind. The product owner should have full authority and the final say about the prioritization of the backlog. During the sprint, the product owner answers questions from the team about the scope of the project, as well as gives feedback about finished (but not necessarily done!) tasks, but otherwise does not interfere in how the team manages its work.
Looking at the actual causes of problems
One of the techniques used in project management is to find the cause of an issue. Digging deeper, my next set of questions to the client usually focuses on the greater picture or vision of the company. Instead of telling me about their mission, they typically respond that they want to “test” Agile and then implement it in other parts of the company.
Besides noting the obvious misunderstanding of Agile as the new (local!) management technique, questions arise: What would success look like? What would failure look like? What are the concrete, measurable business objectives of the project of introducing Agile?
I am convinced that introducing Agile itself should be managed with modern project management techniques, PMBOK being my favorite. Managing Agile goes far beyond the scope of this chapter, but you certainly must have an idea about where you are going with it and what you want to achieve.
PMBOK® · PMBOK stands for Project Management Body of Knowledge and describes a generic system of workflows within a project. While it is mainly applied to Waterfall projects, many of its parts can also be used in an Agile project, like defining how the team communicates with the outside world, defining the vision and scope of the project, or defining why one would want to use Scrum at all. [PMI, 2013]
To illustrate this further, I recommend reading Ayn Rand’s introduction to philosophy that looks at the example of an astronaut stranded on a planet:
Suppose that you are an astronaut whose spaceship loses control and crashes on an unknown planet. When you regain consciousness and find that you are not badly hurt, the first three questions on your mind would be: Where am I? How can I find out? What should I do?
You see unfamiliar vegetation outside, and there is air to breathe; the sunlight seems paler than you remember it and colder. You turn to look at the sky, but stop. You are struck by a sudden feeling: if you don’t look, you won’t have to know that you are, perhaps, too far from Earth and no return is possible. So long as you don’t know it, you are free to believe what you wish—and you experience a foggy, pleasant, but somehow guilty, kind of hope.
You turn to your instruments: they may be damaged, you don’t know how seriously. But you stop, struck by a sudden fear: how can you trust these instruments? How can you be sure that they won’t mislead you? How can you know whether they will work in a different world? You turn away from the instruments.
Now you begin to wonder why you have no desire to do anything. It seems so much safer just to wait for something to turn up somehow; it is better, you tell yourself, not to rock the spaceship. Far in the distance, you see some sort of living creatures approaching; you don’t know whether they are human, but they walk on two feet. They, you decide, will tell you what to do.
You are never heard from again.
This is fantasy, you say? You would not act like that and no astronaut ever would? Perhaps not. But this is the way most men live their lives, here, on Earth. —Ayn Rand, Address to the Graduating Class of the United States Military Academy at West Point New York (adapted) [cf. Rand, 1974]
In terms of a company, your immediate goal is of course to survive the next month. But then, you have to establish where you are on the map. You have to open your eyes, look at the sky, and check your instruments.
In terms of Agile, I recommend to my clients that they run it like a project. We know what works from hundreds of studies, and we can create a list of items that are implemented in Scrum. In that list, we simply mark the current state of the process. Often, even in non-Agile companies, some processes have already been implemented because the people who are managing projects notice which processes work. A simple approach is to check again the Principles Behind the Agile Manifesto [cf. Beck, 2001]:
- Welcome changing requirements.
- Trust and motivate individuals on your team and other teams in the company.
- Developers and non-developers (e.g., marketers, salespeople) must work together daily.
- Face-to-face is the most efficient and effective method of getting things done.
- Progress is measured in terms of working software.
- The entire team must promote sustainable development, they should be able to maintain a constant pace indefinitely.
- The entire team must work together to continuously improve technical excellence and to enhance agility.
- Keep in mind that simplicity is valuable; simplicity is the art of maximizing the amount of work not done.
- The best solutions emerge from self-organizing teams.
- Effective teams reflect regularly on how to become more effective.
- An Agile company satisfies customers through early, frequent, and continuous delivery.
Together with the client, for each point, I detail how this is implemented in the company—this is the first step of documenting the current process. If I can’t explain how it is implemented or if we find that it is not implemented, I focus on those points and try to find explanations for each: why the company is not able or not willing to fulfill this part of the Agile process. And I do not just ask, “Why?” I ask, “Why why why why why…?” until I find out the actual reasons something has not been implemented. [cf. Ohno, 2006]
And at this point, the real work starts: addressing those issues that hinder the Agile process on a daily basis.
