Agile – Making It Work By Dr. Thomas Grisham

The Dream

Liam: Good morning Arjani; thank you for coming on such short notice. We are delighted that you could make time to help us with this new project. As you know, the CEO and Chairwoman of the Board are the impetus behind the idea of creating a new cell phone with 100% of the applications driven by eye movement. They both know this will give our company a big leap ahead of the competition if we can roll out a prototype within six months. They specifically asked that you lead this project, and have asked me to give you whatever support you require.

Arjani: Thank you Liam; I look forward to working with you. We will need to run this project with an Agile approach. I know you are unfamiliar with the technique, so let me tell you the four major components for success:

First, we will need a dedicated Tiger Team location for the team that is supplied with the technology and supplies that I will itemize for you later. I have chosen an offsite resort on the beach that will enable us to take our down time in an atmosphere that will enhance creativity, and let us recharge quickly.
Second, we will need the best of our staff dedicated to the project full time. During the project, they will be required to devote their time to this project 100% of the time. This means no email, no SMS, no phone calls, no meetings, and no work on anything else.
Third, we need the customer on the Tiger Team full time.
Fourth, the duration for the project will be a two week sprint. During the project, we will make all changes necessary, and, at the end of the sprint, we will measure our progress against the overall six month goal. We can then determine what the scope will be for the next two week sprint, after we have had a rest.

Liam: Wow, that will be difficult, but I will see that it is done immediately.

The Reality

If you are thinking “in your dreams,” you work in the real world. The idea of Agile Project Management has been around for quite a long time under various pseudonyms. The idea is to focus a dedicated team on a high priority project, for a fixed time frame, and adjust to the changes that occur. It is normally used on IT projects, but can be used in any industry. Like other forms of project management (SCRUM, Crystal, conventional project management, etc.), there is no one format of process for Agile, it offers a range of possible approaches. As with other forms of project management, Agile is adapted to the culture (corporate and societal), business unit, technology, and product lines. If a Project Management Office (PMO) exists, Agile is more likely to mirror some of the dream world blessings described above, but it does not guarantee it.

Also, there is a tendency to misuse terminology in Project Management. Agile can mean “SCRUM”, or it can mean “conventional but with a few twists”, or it could be “Crystal”. Getting agreement on the terminology is obviously important because it conveys the accurate meaning to the other stakeholders, and to the customer. There are aspects of Agile that I will not address in this paper. Not because they are unimportant, but rather because they are not as important as the ones I will cover. So what follows is an overview of Agile compared to other techniques, and some ideas that may help you implement it in the real world.

Agile making it work

Agile holds the promise of faster project durations. In a global economy, all organizations are struggling to keep quality high, costs low, and to customize products for local consumers. Organizations are all striving to reduce cycle time from customer request to product availability. These dimensions are continually in tension and often increasing one decreases the other. They need to be in balance and need to be continually adjusted just as the global economy does. In a dynamic global environment, change is ubiquitous, and so organizations must find ways to inculcate a culture of change. So, in order of importance, I will cover the four pillars of Agile Project Management and some suggestions on how to make it work in the real world.

First though, let us look at the basic differences between conventional Project Management, SCRUM, and Agile, three of the most popular techniques. The figure below provides a basic overview of these options. SCRUM and Agile “fast track” a project by overlapping the major process groups to start. Changes are normally completed as part of the project, but not always. In SCRUM, changes are not accepted as part of the project but rather recorded and done in a later project. In Agile, changes are incorporated into the project. The obvious advantages to SCRUM and Agile are that they offer the promise of shorter cycle times. The disadvantage is that they are more difficult to control because of the multitasking, and they require more effective and frequent communications. SCRUM outboards changes, which may or may not lead to shorter cycle times overall. Agile includes changes as part of the project, but that dilutes the initial scope work since the time frame for the project is fixed. So, there are advantages and disadvantages to each approach.

SCRUM and Agile are normally used on IT projects, but their use is certainly not limited to that one discipline. “Fast track” projects have a long history, and the lessons have been mixed. In my experience, an Agile technique is a superb way to define the scope for a larger project. The time frame can be limited to 2 or 3 weeks, and what emerges is effectively the end of the Initiate process group in conventional project management. Alternatively, for a project with an anticipated overall cycle of six months, the project can be subdivided into eight Agile projects of 3 weeks each for example. This enables a project, or program manager, to identify changes and problems earlier than in a conventional project management approach. And now to the four pillars

Pillar #1: Dedicated Team

In classes around the world, corporate students tell me that they work on five to ten projects concurrently, and they are most often spread around the globe on virtual teams. When I ask how many emails and SMS people receive, they typically tell me about 150 emails and about 50 SMS. Then, there are the meetings, business trips, and changes. When I ask how many hours they work each week (except for parts of Europe), the answer is generally 50 to 60. The table below shows the numbers. You can plug in your own of course, but the idea is that people are working longer, and are connected 24/7. To use a metaphor, that means many are playing ping pong in that they are simply reacting to the changes and circumstances of each new day.

This is a problem for any project team, but it is especially difficult for an Agile team. There is a growing body of research conducted on young professionals who believe they can multitask effectively. The research consistently shows that productivity quickly drops to 50% and continues to decline as more than two tasks are attempted at the same time. People also need time to rest during work, especially if they are knowledge workers and must concentrate fiercely on the work. Simple walks, playing, swimming, or talking during the work day will actually increase productivity in my experience. I know it seems counterintuitive, but the two or so hours of work lost may yield four or more hours of progress. A student of mine in Koreasays it is a time to “catch the idea from the air.” That is exactly it. Professionals are knowledge workers; they get paid for what they know, and for thinking. To benefit from knowledge workers, a company needs to provide time to do just this.

As with all things in project management, and business management, there are a range of opportunities. An Agile team can be fully dedicated to the project at hand, or at the other extreme they can be working on five simultaneous projects. The chances of success, in our experience, increase asymptomatically as the number of distractions decrease. Can one run an Agile project without a dedicated team? Certainly, but it should not be called Agile, perhaps Agile lite or sugar free Agile, or project management. In my judgment, a dedicated team is the foundation of Agile project management. No email, no SMS, no phone calls, no meetings, no other projects – dedicated.

Pillar #2: Dedicated Customer Representative & Changes

This is often very difficult, especially in finding a customer representative who is available, and who has the ability to make decisions. And, of course, this person has the same issues about being dedicated we discussed above,. In addition to the dilution of productivity, the other aspect of dedicated personnel is communications. In an Agile environment, there is not time to swap emails, call on the phone, wait until the customer meeting is arranged, or wait until someone with adequate authority becomes available. As we will discuss shortly, in Agile, changes are done as the project proceeds. It is essential that the customer be intimately involved in every single one, so that they know why the change is necessary, and what the ramifications are. Changes provide valuable information about the scope, and enable the Agile team to anticipate future changes. This is the second most important part of Agile project management. If there is no customer representative, many decisions will be taken, and changes made by the team. They are professionals. That is what they do. If the customer is not a daily participant, it will be time consuming to explain why each decision was taken, and it will perhaps not be viewed in the same light as synchronous thinking. An authorized customer representative needs to be a full time dedicated member of the Agile Team.

Pillar #3: Agile War Room

There are numerous ways to set up an appropriate work space for an Agile team. I use the metaphor of “war room” to give a feeling of urgency, importance, and dedication to task when the team is inside its walls. It is a problem for many companies that utilize global matrix resources to create Agile teams. It is, of course, possible to build a virtual Agile team, but the issue will ultimately become one of communication. Communication at distance takes time. One could run something like an HP Virtual Room, but the costs are huge. Or Skype, meeting software, conference call centers, or some combination. But it is not as effective as a co-located team. Everyone reading this that has done both knows this. Also there has been substantial work done by Ray Leavitt of Stanford University into co and virtual team location: http://cife.stanford.edu/online.publications/TR154.pdf. The bottom line conclusion is that co-location is essential for teams where there are complex project interdependencies that cannot be easily addressed by written guidelines/instructions. Depending upon the cultures, personalities, technology and physical locations, the productivity of a virtual team will be less by a little, or less by a lot. Again it is cost/benefit. To get the most benefit out of Agile, you need a co-located team.

The accoutrements (computers, testing software, whiteboards, meeting tables, and such) also have an impact upon productivity. When I have asked students to design rooms, the results are fascinating. Some have individual work areas around the perimeter walls to enable them to work solo. Some have drop down partitions between the individual areas for two person teams. Some have a conference table in the center so that they can simply swing their chairs around to talk. Some have Google type distractions to let the team relax and recharge. Each team will be different, and I believe it is best to let the team decide what will enable them to work most effectively.

Pillar #4: Sprint

For this paper, the last item is the timing. I believe this should be flexible and that it should be determined based upon the type of project:

Cutting edge R&D to operational enhancement
Market share critical
Large complex or small straightforward
Highly visible or mostly unknown

The items above are by no means an exhaustive list, but rather are a few examples to illustrate the idea. There is also the issue with the team. A sprinter trains for say a 100 meter dash that requires huge amounts of energy, and it cannot be extended to a marathon. People burn out, and people who sprint burn out faster. There are no fixed rules again, but I can suggest a few ways to think about how to pick durations for the sprints. Imagine that you are writing a book under pressure. How long do you think you could work on it without a break, and still be highly productive? In the educational literature it has been shown time and again that most students can only retain information for about 1.5 hours. I have seen students in corporate training attempt to sit through 40 hours of training in five consecutive days. At the end, they are burnt out, as am I. Is then a weekend enough to recharge? Perhaps for some people. Six day weeks - I suggest - do not provide enough down time, from experience. I think that 4-3-4-3-4 (four days working, three days off, etc) is a workable model if the sprint is to be over three weeks, or in this case 12 working days. Perhaps better to limit the sprint to 5-2-5, or two weeks.

Conclusion
It is not a perfect world and the likelihood of Arjani getting her wish in the real world is indeed small,. She will have to compromise, as have I, and as do you. Agile is intended to be a dedicated, intensive sprint, with the subject matter experts and the customer co-located. Each, or all, of these demands will have to be negotiated, but at some point too much departure from the essence of Agile means it is a different type of project management. When does this happen? I’m not sure. But when I think about it, if you do not have a war room or no co-location for example, you are near the edge. If you do not have a reasonably dedicated team or a reasonably dedicated customer, you are not doing Agile in my opinion. Remember, Agile is intended to provide high productivity, and quick results and to achieve this, certain core elements need to be present.

© 2011 allPM.com

Dr. Thomas Grisham (BE, MBA, Doctor of Project Management, PMP, PE) has over 36 years of Project Management experience in 53 countries in the power, infrastructure, transportation, education, commercial, communications, manufacturing, business development, and dispute resolution sectors. He also has over 11 years of research and teaching experience at the undergraduate and graduate levels, and in the for-profit and executive education sectors.

Artykuł opublikowany dzięki uprzejmości International Institute for Learning, Inc.

Użytkownicy, którzy przeczytali ten artukuł, przeczytali również

Komentarze do tego artykułu

BOX REKLAMOWY

POLECAMY

PM Podcast

WARTO WIEDZIEĆ

Agile – Making It Work By Dr. Thomas Grisham