Getting Dirty with Scrum

By Pat Guariglia

I have been the Scrum Master for this one team for several years. The other day I arrived a few minutes early to the room we use for our daily Scrum and sat down to gather my thoughts before the meeting. I was in the room by myself when I noticed all of the scuffing and marks on the walls.  When we started using this room for our daily Scrum meetings, it was freshly painted and hardly used. Two years later, I am looking at the walls of a well-used room, a room that hosts our daily stand-up meetings… a room that gets dirty.

Seeing the dirt on the walls reminded me of how tactile the whole Scrum process really is. In Scrum, you cannot be afraid to get dirty. You work with your hands, body and mind. When Scrum is done well, the team becomes a well-oiled machine that takes on a personality of its own. The seasoned Scrum team reacts organically to change and knows how to process it.

Good Scrum involves taking yourself out of the virtual world and into the real world. Unlike other software methodologies (waterfall), Scrum is the framework that thrives on continuous hands-on experiences, plus tactile and verbal feedback. It works best when people are engaged and physically involved. Collocation, physical task boards, daily Scrum meetings, and customer collaboration all require the team to be there physically.

Continue reading this article.

Negotiating Scrum Through a Waterfall: How One CSP Navigates the Difficult Waters of Implementing Scrum

By Phil Southward

Negotiating a Scrum team through the often laborious processes required in a waterfall-based organisation without getting stuck between departmental snags or ensnared in the inexorable documentation eddies along the way is an arduous and, if I may be excused the pun, agile undertaking. Sitting out the umpteenth interdepartmental project sign-off meeting, a Scrum practitioner could be forgiven for thinking that the waterfall manifesto, if there was such a thing, would value:

•    Processes and tools over individuals and interactions.
•    Comprehensive documentation over working software.
•    Contract negotiation over customer collaboration.
•    Following a plan over responding to change.

In this clash of cultures, conflicts inevitably arise, yet if my experience in a couple of large (over 4,000 employees) waterfall-based companies is anything to go by, the two can be made to fit together. Somehow.

First up. Work around the keepers of the waterfall manifesto by negotiating a change to the contents of the waterfall deliverables to make them more Scrum-like. Second. Alter the Scrum artefacts and definitions to fit with the waterfall world negotiated above. Finally, as a last resort when nothing else is possible, create all the required waterfall process documentation and deliverables, while running projects internally using Scrum. Successfully negotiating the waterfall will involve some combination of all three.

Continue reading this article.

Ask the Coach

By Manoj Vadakkan

Recently I had an opportunity to speak with Alan Atlas, a Certified Scrum Trainer and Certified Scrum Coach who works for Rally Software. In this conversation Alan shares his insight on the state of Agile and Scrum. He also takes a stab at predicting what is to come in the future. This interview also includes some advice both for budding agile consultants and also for organizations that are trying to transform to an agile way of working.

Manoj: Agile has been here for a while; it is everywhere now – small and large organizations, distributed organizations, etc. What’s new in agile? Where is it going?
Alan: One thing I am glad of is that, in a certain sense, there is not a lot that is new. I think we understand it [agile]; I think it works and I really don’t want people messing with it a lot. Ken Schwaber is fond of saying that the whole thing that got us into trouble in the first place was our search for the perfect process. One reason that Scrum is so strong is that it is a process framework, not a process. It gives you all the important stuff and plenty of room to adapt.

It is true that agile does seem to be spreading everywhere. I saw a question in a trainer’s discussion group where someone was asking, "When is it going to be when the only option to do your project is agile? Then you don’t have to say you are doing agile or waterfall, you will just say we are doing a project." I think we will get to a state where that’s [agile] just the way to do things. Students will come out of school knowing agile, and they will know iterative and incremental makes sense; it will be just as logical to them as waterfall  was to us when we came out of school. When I came out of school, I thought, what possible other way there could be to do a project? It [waterfall] was so logical. You start by collecting things [requirements]; you go thru this orderly process; what could possibly go wrong? We discovered what it was – what could go wrong.

Continue reading this article

Three Things I Wish I Knew Before Jumping

By Pat Guariglia

Like many people trying to implement a Scrum/Agile project for the first time in an organization, I encountered a number of obstacles that were almost project killers. As I write this article today, I keep thinking, “if I only knew that when I started.”

When I started managing my first Scrum pilot project in 2007, I was new to the concepts of Scrum and Agile development. For years, I led projects using traditional project management methodologies common to PMI, i.e. Waterfall. During this time, I was a consultant to a New York State Agency. It was a typical Waterfall shop, with no history of using Agile or Scrum.

Sometimes you can choose the project you want to pilot, but oftentimes the project chooses you. In my situation, the Agency had its back up against the wall and needed to expedite the delivery of a critical project. Agency funding was in jeopardy and critical business dates needed to be met. In my opinion, certain types of projects are good candidates for Scrum pilots, and others are not. The project I led had none of the characteristics ideal for a pilot project; it was not the perfect candidate for a first-time Scrum implementation.

After being assigned to manage this project, I quickly realized that the project would never meet the deadlines within the constricted structure of the organization. It was necessary to break away from the Agency’s normal project management and development methodologies. The project sponsors permitted us to use the methodology of our choosing as long as we met the deadlines. I explored Scrum and various Agile methodologies and made the decision to abandon the normal Waterfall project path.

After one year, the pilot project turned into a program of three projects. Two of the projects used Scrum and the third followed a Scrum hybrid approach for managing a vendor’s customization of a commercial software product. The program was mostly successful, and the projects were delivered on time for all critical dates. The organization was satisfied with the use of Scrum and looked for other project opportunities to leverage some of our Agile best practices.

The first few months were difficult and outright painful as the team learned the practices of Scrum, the variations of Agile development, and the nuances of the customer’s business. Our team had little guidance and no one coaching us on Agile or Scrum methodologies. For months, we worked in the dark to avoid scrutiny and work out the details of our methodology, with only a few people aware of our voodoo methodologies. We had only one clear goal, to achieve the deadlines without failure.

Even though I had moderate success with the three projects, I discovered literally hundreds of things I wish I knew before setting off on my pilot journey. I want to focus on three critical topics for this article, which I believe anyone starting a Scrum pilot project should know. The three things I wish I knew most before jumping into my first Scrum project are: 1) select a project with medium criticality; 2) continuously communicate your chosen methodology; and 3) demystify the voodoo (this one needs some explaining).

These three topics are basic and straightforward, and should be universal to anyone attempting an Agile/Scrum pilot project for the first time. I chose three things that focus on the early stages of a project, but could also be valuable throughout the project’s lifespan.

Select a Project with Medium Criticality

In order to have a successful Agile or Scrum pilot project, it is important that the project chosen has enough importance or criticality to the organization. Projects with low levels of urgency will get brushed off and not given the resources, attention, and critical thinking needed to properly develop a Scrum project. Pilots with high criticality are not good for several reasons. The main reason is that there is little room for failure. If the pilot is not successful, it can be a huge black eye on the face of future Scrum efforts. Also consider that on a project with high criticality there will likely be many attitudes and influences on the project, which could steer it off the Scrum course.

Typically, good candidate projects have medium importance to the organization. It is important to understand this when choosing a pilot, if you are selecting one from your portfolio. An excellent resource on this topic is a book by a friend of mine, Greg Smith, titled Becoming Agile in an Imperfect World. He covers various aspects of a good pilot project in his chapter “Characteristics of a Good Pilot.”

Continuously Communicate Your Chosen Methodology

I cannot express the importance of this topic enough. In the years that I have been a project manager, I have never been able to communicate enough. Just when you think you have covered all bases, there is someone lurking in the shadows not paying attention. According to PMI¹, the amount of time a project manager spends communicating is 90%. This holds true for Agile project managers and ScrumMasters as well.

Since I have been using Scrum, I have been both a ScrumMaster and project manager on each project I manage. As a ScrumMaster, I have spent countless hours coaching and deflecting potential issues/problems away from my team. As a project manager, I have spent an inordinate but necessary amount of time reporting status, building relationships with stakeholders, and keeping the projects aligned with the organization’s standards, rules, and strategic goals.

When starting a Scrum pilot project of any type, it is of vital importance to communicate your chosen path (Scrum) to everyone you interface with. You should not communicate this path just once or twice. It will be necessary to continuously express, elaborate, and explain Scrum to every stakeholder and team member until they no longer look at you with confusion in their eyes.

After more than a year and a half into my pilot Scrum project, I was talking to a functional manager about our Scrum methodology and how we were using Scrum and Agile development. The manager appeared confused and disoriented by the conversation. This was not the first time discussing this methodology, but the manager reacted as if it were. This reaction is common in an organization heavily framed within a Waterfall methodology.

Typically, few people in traditional Waterfall organizations have been exposed to Scrum. I made the false assumption in the beginning and middle of my pilot project that stakeholders and the accidental support person were familiar with Scrum or Agile development, because I gave several overview presentations to them. This assumption was way off on my part. In order to understand Scrum, one needs to be involved in Scrum. Observing Scrum from the outside can be odd for some, and for others it can be confusing.

After many months of trial and error, our Scrum team finally reached a cadence and became better at estimating and delivering. The people who interfaced with us on a regular basis, who were outside the immediate Scrum team, including support units, infrastructure, and the PMO, began to better understand the Scrum process. If your pilot project is progressing successfully, it will become easier to communicate your process because everyone will want to know how you are doing it. On the contrary, if your project is lagging or plagued with issues, it will be hard for you to find an audience that you can convince that Scrum is the way to go.

Communication on any project is the most important part of a project manager or ScrumMaster’s job. The sooner and more frequently you communicate what you are doing the better off you and your project will be at surviving the first Scrum attempt.

Demystify the Voodoo

In my attempts to “demystify the voodoo” of Scrum to the outside observer, I have realized that this is not always an easy task, and is one that requires frequent attempts at demystification. When I first started using Scrum and Agile it was painfully obvious that others in the organization, including some stakeholders, were uncertain about my methodology and had a preconceived notion about Agile and Scrum. This misconception was something I continuously confronted throughout my project, as it was an impediment to my progress.

The reason voodoo becomes an impediment is mainly due to the reasons mentioned above in the communication section. It is important to communicate the methodology, which means define, describe, demonstrate and illustrate, thereby demystifying whenever possible. Most of the voodoo comes from not understanding the methodology or having the wrong information. Agile and Scrum are demystified every time one communicates or explains their pros and cons to the outside observer or reluctant stakeholder.

Unfortunately, as a project manager and ScrumMaster, it is possible to contribute to the voodoo perception. Performing Agile “in the dark” or “under the radar” can sometimes make the methodology even more taboo or misunderstood. Performing this style of clandestine Agile can be beneficial for a short period while the project team is getting up to speed and processes are being defined, but continuing too long in this mode will eventually be counterproductive. Stakeholders want to understand how the project is being managed. At some point, it is necessary to communicate the methodology before others begin forming their own opinions of what you are doing.

Using examples of public success stories also helps to demystify Scrum. After articulating various definitions of Scrum and Agile development processes to my stakeholders, I looked for examples of successful implementations of Scrum in both the private and public sectors. Illustrating how a CMMI²level 5 company can successfully put a Scrum project into place certainly got the attention of some of the stakeholders. I showed quantifiable results from Systematic, a CMMI 5 company who measured productivity and quality before and after they implemented Scrum. Their overwhelmingly positive results put many of my stakeholders finally at ease.

Wrapping Up

Though there are many things I learned along the way, the few that I have described here are the ones that would have been the most helpful at the start of my Scrum/Agile experience. If you have any choice in the matter, remember that when starting your first Scrum pilot project, it is important to pick the right project. Also, communicate your methodology, risks, and plans continuously. And finally, provide accurate and substantive information to support the use of Scrum and Agile in your organization, which in the long run will demystify the aura of Scrum.

Scrum is not a cookie-cutter mold that you can throw your project into. Scrum is adaptive and can be customized to some extent to fit the unique situations and conditions of your environment.

Unlearn What You Have Learned: Ten Habits You Must Break To Be Successful with Scrum

By Nimesh Soni

In the Star Wars movie The Empire Strikes Back, Luke tries unsuccessfully to rescue his X-wing fighter from the swamp. After some time, he gives up. He tells Jedi Master Yoda that lifting the fighter is impossible with the force, the new approach Yoda is trying to teach him. Yoda has these words of wisdom for him:
“You must unlearn what you have learned.”
Scrum is no different! Like the Jedi force, the Scrum framework is conceptually easy; it’s putting Scrum into practice that is difficult. In order for a team to be successful, the team members must unlearn what they have learned so far in their careers.
Here are nine habits you must break in order to be truly successful with Scrum.

Habit One: Create email trails

Often, on traditional projects (i.e., waterfall), team members create trails—written proof to cover themselves. Scrum, like all agile methodologies, values communication and collaboration among team members. Individuals are encouraged to pair with other team members, discuss the story or task at hand, and drive it to completion (and not worry about getting it in writing). Team members must unlearn the mentality of creating a trail and learn to trust and depend on their teammates.

Habit Two: Use command and control

In traditional project management, the project manager uses a command and control approach to steer her project in a certain direction. She generally is responsible for the success or failure of the project. On Scrum projects, team members must learn to take collective ownership of the project. In turn, the project manager has to learn to facilitate and empower rather than dictate and drive.

Habit Three: Create disciplines and silos

On traditional projects, each team member is assigned certain tasks and is responsible for completing theses tasks. Generally, the tasks assigned are discipline-specific, focused on the primary skills of each team member. A systems analyst, for example, will be assigned only the tasks that relate to requirements gathering. This creates silos and requires hand-offs.

On a Scrum team, each member has to unlearn the tendency to specialize and instead should use pair programming and role sharing to expand his or her understanding. No more staying in your own lane. Scrum team members are encouraged to venture into others' lanes.

Habit Four: Be a hero

Our traditional work environment promotes heroism. An individual team member is applauded for her achievements on a project. This often encourages individuals to look after themselves. This behavior must be unlearned by the team members on a Scrum project. On Scrum teams, there are no heroes! For the greater good of the project, the team members must be willing to work with each other to drive the stories to completion. The team, as one unit, is responsible for success or failure of the project and must take the collective ownership of the project.

Habit Five: Sign off on a detailed requirements document

It is difficult for management to accept the fact that you can work on a project that has a fluid top line or scope. This is the most difficult trait to unlearn. On Scrum teams, we adjust the top line of the project at the end of every sprint. With each sprint, the team gets better, smarter, and learns more about the project and the environment. Based on what the team learns, the team adjusts the top line of the project.

Habit Six: Stick to the iron triangle

The traditional approach to project management refers to scope, schedule, and cost as the iron triangle. This iron triangle, though, is broken because it does not take into consideration the quality of the project deliverables. The requirements and priorities of the customers might change as they see more working software.  The management must unlearn the urge to box customers into committing to a pre-defined and well-documented set of requirements. Instead, Scrum teams should emphasize the quality of the product that the team creates through various levels of testing and inspections to achieve a done state. The team must learn to focus on quality and make it a central requirement of its work and deliverables.

Habit Seven: Be plan driven

The world is not standing still, so why should your project plan be written in stone? Traditional project management is very stubborn about setting the project plan and sticking to it no matter what. Project Managers spend many hours trying to come up with a perfect plan; the truth is, no project plan is ever going to be perfect. It might be perfect for the moment; however, the world is changing constantly. Your customer’s requirements and priorities will change, the work environment for the team will change—the plan must change in response. Management must learn to accept the truth of change, and allow teams to respond and adjust accordingly.

Habit Eight: Be IT driven

How many times (in your career) have you come across a situation where the IT management is driving the projects? Where IT is dictating what it can and can not do for the business? In Scrum, IT must learn to play a supporting role. The business must drive the projects (priorities, scope, what gets delivered and when—all to increase the ROI). IT should work with the Business to deliver the required artifacts. The Product Owner, thus, is the single most important factor for the success or failure of an agile project.

Habit Nine: Have a big bang delivery

With waterfall projects, you typically get a single, big-bang delivery, where the finished product is delivered to customers at the end of the project. The big misconception with the traditional waterfall approach is that any complexity can be effectively dealt with in a "big-bang" approach.
Scrum emphasizes the delivery of the product in an iterative manner. On a Scrum project, the team must learn evolutionary (and iterative) delivery of the product. With each delivery, the team learns from the customer’s feedback and communication of changed priorities. What the team learns is applied toward making subsequent deliveries better, delivering value to the customers, and in turn to the business.

Habit Ten: Tell teams “How,” not “What”

Management has learned to dictate how the team should complete the tasks at hand. In Scrum, management must unlearn this urge to tell the troops how to execute the tasks. Instead, they must learn to provide the priorities, and then trust the teams collective instinct and experience to complete the tasks. Let the troops on the front line (the folks who are actually going to work on the tasks) decide how to execute and get things done within the boundaries established by management.

Scrum is a simple framework, but executing it properly is not easy. You must unlearn certain long-held beliefs to be successful, and as we all know, breaking habits is never easy. Keep in mind the words of Jedi Master Obi-Wan Kenobi to Luke Skywalker: “Luke… Let go. Trust the force.”

Yin Yang & Project Management

By Jann P. Thomas

The Chinese philosophy of yin yang is based on four laws.

1. Yin and Yang are opposing. Yin and yang describe the polar effects of phenomena.  For instance, winter and summer would be the yin and yang for the year.  
2. Yin and Yang are mutually rooted. They are complementary qualities that make up the whole phenomena, just as daylight and night together make up a single day.
3. Yin and Yang mutually transform. That is, a change in one quality causes change in the other.  For example, snow melting in the spring cause a rise in the river.
4. Yin and Yang mutually wax and wane. There is a dynamic equilibrium between Yin and Yang; even as winter days grow shorter, the night grows longer.

Agile and traditional management methodologies have a yin yang relationship that is felt quite keenly by many project managers charged with moving a software team toward agile practices. Handed an edict from on high or a mandate from the software team’s own grassroots effort, the manager must figure out how to function in his new reality. Will the developers now have free reign to do whatever they want to do?  Who will be in control?  What is the job of the manager on an agile development team?  How can I move from command and control to cooperation?  Learning agile’s guiding principles and how their inherent balance translates to concrete actions is the first step to a truly productive conversion to Agile.

Balanced Principles

Like the yin yang philosophy, agile also has four guiding principles—principles that are also opposing, mutually rooted, mutually transforming, and mutually wax and wane. These principles are captured in the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Let’s examine the yin and yang of these guiding principles and see how it can help guide a project manager in converting to agile.

Individuals and Interactions & Process and Tools

This principle lends itself to several concrete actions. If possible, remove cubicles and have the team together in one shared workspace. Schedule daily stand-up meetings for each team member to discuss what they did yesterday, what they are doing today and what blockers stand in the way of completing work. Remove any blockers or impediments to delivery, whether that means buying tools or putting a process in place to encourage productivity.  

A process? Yes. Agile is not anti-process. For example, take the familiar case of bringing in an enhancement to a product in mid-iteration rather than completing the work originally scheduled for that iteration. To do this effectively and transparently, the agile project manager must create a process for bringing in new, unplanned work. This process must also include recording what tasks were moved out of the iteration to make room for the new work so that the whole team, including the customer, can see and understand not only what changes occurred, but what the costs of those changes were.

To be an agile project manager is to be introspective. A good agile project manager should review and question all of the organization’s existing and developing processes. Is the process appropriate in an agile environment? Does this process help or hinder the team’s efforts to deliver working software? In addition, iteration reviews (retrospectives) give the entire team the opportunity to evaluate any changes they have made to their processes; the team keeps the ones that work and drops the ones that don’t.

Working Software & Documentation

Working software is the goal of every software project. Traditional approaches, such as waterfall and spiral methodologies, rely on the concept that the requirements of the product can be precisely defined before implementation begins. Agile development practices differ in that all software project activities, from requirements to installing production-ready code, are delivered in small time chunks called iterations. An iteration can range from one week to four weeks. The only fully defined requirements are the ones that the development team is working on in a particular iteration.

Agile teams and agile project managers are not opposed to documentation; rather, agile is focused on just enough documentation, just in time to create working software. On agile teams, requirements are developed only when they are ready to be used (just in time), which often results in a smaller set of architectural diagrams, use cases, and functional specifications. The documents that are created and maintained are only those that are necessary for development (just enough). If a document has outlived its usefulness, it is jettisoned by the team. Producing documentation is appropriate as long as it supports the working software.

Collaboration & Contract Negotiation

All software projects have some type of contract, whether implied or explicit.  Implied contracts are used most often for internal software teams; explicit contracts are used for things like hiring an outside software team for a temporary project. The one thing that both of these contract types have in common is a date.  Most project managers are familiar with the three sides of the constraint triangle: scope, time, and quality. If time (completion date) is fixed and high quality a priority, the only area for compromise is scope. Negotiating with the customer or product owner on scope is a key component of agile project management. Only the product owner knows the importance of a feature. Only the product owner can make decisions on the relative position of features and which features must be delivered first. Only the product owner can decide that rework of an existing feature is more important than new feature development. The fact that the product owner is part of the team and can see the work as it is completed allows agile teams deliver value earlier than they could using traditional software methodologies.

Responding to Change & Following a Plan

As anyone who has built a house can attest, having a detailed set of blueprints is only the beginning. Compromises and changes are expected and inevitable prior to final delivery. The same holds true in software. Just as a homeowner would not give the blueprints to a builder and never visit the construction site, product owners for software projects shouldn’t just hand the development team a list of requirements and then never see the interim product.

Agile projects allow the product owner to visualize the progress on his project as code begins to work. The product owner is empowered in agile projects to finalize details as work progresses. Returning to our building analogy, during construction, the homeowners pick out fixtures, choose cabinet colors, and sometimes move walls as they begin to see their home emerge. Similarly, the agile product owner fills in the details of his own requirements (or changes his mind about his requirements) as he begins to glimpse the working software. If the product owner decides there needs to be a change in something already developed and that change is more important than new undeveloped features, the project team makes that change. Agile teams, like home builders, respond to change.

An Agile Coexistence

Just as yin cannot exist without yang, the elements that agile practitioners value (working software, collaboration, change, and interactions) do not exist without their corresponding yang (documentation, contracts, plans, and process). These mutually inclusive agile principles also follow the laws of yin and yang. Agile principles are opposing: there must be a plan but the plan will change. Agile principles are mutually rooted: the contract, whether implied or explicit, will require negotiation, so invite the customer to collaborate with the team. Agile principles mutually transform: the team needs some sort of blueprint of what to build but only as much as makes sense and is reasonable to maintain. Finally, Agile principles wax and wane: all software teams need processes and tools to know their boundaries but individuals interacting daily build the best software.

Scrum Meets Waterfall

By Dave Prior

Editor’s Note: You can choose to view the video or read the transcript (provided below).

Dave Prior: Hi. My name is Dave Prior and I’m chair of PMI’s IT & Telecommunications SIG … About a week and a half ago, I was fortunate enough to be able to attend the 2008 Scrum Gathering in Chicago. It’s an event where about 250 practitioners of Scrum get together to share ideas and thoughts about what’s working, what’s not; ways to promote it, bring in other agile practices; how to make it just all around better. I wasn’t really sure what I was going to experience walking into it, being as I’m a PMP-certified, waterfall-background project manager. But I was very, very surprised and happy to see that it’s not just [a bunch of] developers and agile-minded developers who hate waterfall guys. There was an even mix of project managers and software developers; a fair amount of PMPs [and] non-PMPs who consider themselves project managers. But overall I found the environment to be very welcoming and friendly, which was a nice thing because I wasn’t really sure that was going to happen. I learned volumes at this event and if you get a chance to attend this or one of the agile conferences, I absolutely recommend it. It was a great, great learning experience.

While I was there, I had an opportunity to sit down with Mike Cohn. If you’re not familiar with Mike, he’s one of the rock stars of the Scrum world. He’s one of the founders of the Scrum Alliance; [at the time of this interview he was] serving on the board of the Scrum Alliance.  He runs Mountain Goat Software and he is also a Scrum certification trainer who teaches all over the place. I took Mike’s class last year and it was a great time—I got a lot out of it.

When I sat down with him, one of the first things that I asked him was, “For a project manager who is just coming into the agile world, just kind of becoming aware of it, what is the best place, or the best way, for them to get started understanding what’s going on and how can they break themselves free of that waterfall mindset that would basically lead them to believe that a lot of agile practices are basically taking your hands off the wheel and seeing what happens?”

Mike Cohn: Well, I am associated with the Scrum community, as you mentioned I am a founder of the Scrum Alliance. One of the things I like about Scrum is that it’s a good place to get started. Scrum is kind of the default agile process in a lot of ways—it’s been around the longest. I like that it is the lightest-weight kind of starting point. We don’t start out by mandating you do twelve different practices or anything like that. Scrum, at its heart, is really just about getting a team to be iterative and once you’re iterative then moving towards becoming agile. So I really like Scrum as the starting point. Although, as much as I like Scrum, my preference is actually for what I call unbranded agile. I just kind of wish all the brand names would go away—Scrum and XP and Crystal and everything else—and we just call it agile software development, or even better just call it software development. But for now, we still have the brands and Scrum is the right starting point in my mind.

In terms of getting started with Scrum, Ken Schwaber has three great books out on Scrum. But what I really like is for somebody to read one of those and then go to something like a class. I’ve always thought that I could do a great two-hour Scrum training class if I could get somebody for one hour at the end of one day and then one hour at the beginning of the next day. There’s something that happens when you sleep on it over night. You know, I couldn’t do a two-day class and get somebody’s mind changed, but if I could get them to get the right things, kind of sleep on it and come back the next day, I think you could kind of start shifting your mindset away from traditional thinking towards a more agile mindset.

Dave Prior: I took Mike’s Scrum certification training in Dallas last year and I was the only project manager in the room, which surprised me, I was sort of expecting a lot more. And I asked him, generally when he teaches a class, what is the mix? Is it mostly developers, mostly project managers, or maybe a mix of both? Here’s what he had to say about that.

Mike Cohn: Well, the mix is really different. If I teach a public class (you know where I rent a hotel and invite people to just show up in my classes), the mix there is probably 70-80 percent on the management side. It’s either a project manager or it’s a tech lead who soon would be a project manager, kind of thinking in the traditional way, and a few developers that show up—but typically skewed toward a people who are in leadership or management positions at the public classes.

When I’m invited into a company to talk, one of the ways I structure the classes and just do my pricing with companies, is I want everybody there—it might be three managers and twenty technical people there—because I’m trying to get the whole team mindshift to happen. Earlier, when I started doing this I’d have companies that would say, “OK. You price per person, we’re going to leave the testers out.” I’d say, “No!” Right? And so I would price per day, right, with people, because I want the whole team there. … Otherwise, people don’t hear it. One of the things I’ve found with training, having been doing this for a long time now, is I have to be careful with what I say because people will hear the one sentence they hear, they doze off from the rest, and you’re quoted back the one sentence out of context that--people hear what they want to hear. And so I really want all the groups there. So when I go in to work with a company, that’s how I set it up, I want everybody there.  So I typically don’t just teach just a management class inside a company. But those choosing to come to a public estimating class or ScrumMaster class, much more on the management side.

Dave Prior: One of the projects that I’m working on right now is a Scrum project that’s being run inside a  waterfall organization. So everything within IT is happening from a Scrum perspective and that’s going off like gangbusters. But we still have to find ways to communicate with the folks upstairs, the people who want to see Gantt charts. And Scrum’s great, but they have to able to know when everything is going to be done.

Obviously there’s a lot of conflict there and one of the challenges that I’ve had in working on it is trying to find a way to come to grips with the fact that, yes we’re doing an agile practice or Scrum, but we’re doing it in a place where we still have to be able to answer to people who want to see a Gantt chart or a network diagram. So I asked Mike if he had any tips for project managers in a similar situation. How do you address that? How do you deal with the fact that you are doing an agile methodology inside an organization that is anything but?

Mike Cohn: There are a lot of myths in agile about things like, you know, “documentation is horrible.” Documentation is not horrible, right? The Agile Manifesto says we value working software over comprehensive documentation. It doesn’t say get rid of all documentation. And a lot of agilists are opposed to Gantt charts and things like that. Those are mistakes. Gantt charts are wonderful communication tools. So I don’t go in and want to try to change how a, how a company looks at things.

I was working with one company that had maybe twenty projects going on; they were experimenting with agile on two of them, and when I got there the two agile teams were trying to change the, kind of the, dashboard reporting that their VP wanted. I was like, “No. You’ve got eight teams doing it the other way, eighteen teams doing it the other way, you figure out a way to make yours look like theirs. “ Right? You don’t have to go in and change all those things as part of this initial battle. Again that’s part of starting in a lightweight manner and kind of pushing to constantly improve.

So a thing like Gantt chart is an absolutely wonderful way to communicate; it’s a horrible way to do day-to-day management. I’ve always had an issue [with a situation where] a project manager would walk in and say, “It’s Tuesday. The Gantt chart says you’ll be done with this. I don’t know what ‘this’ is but where’s you’re corrective action plan because you’re not done?” Right? None of us think that’s a good way to go. But as a way to communicate overall progress and just kind of map out high-level expectations, it’s wonderful. So I don’t necessarily look to change a lot of those things.

Dave Prior: In places where I’ve worked where agile has been a part of the mix, it’s normally been introduced by somebody from the development side. And walking into that situation as a project manager who is certified in being able to do things from a waterfall standpoint, it’s a little bit of an uphill battle for me, especially because you don’t have a developer background.

So I asked Mike, walking into that type of situation, if you’re a project manager and you’re not a software developer, how do you overcome that? What steps can you take to kind of even the playing field so that the developers who have brought agile in, or turned to it, turned to Scrum or XP or whatever it is, how do get yourself raised up to a level where they see you as an equal as opposed to the waterfall guy who is just going to be in the way?

Mike Cohn: I think if we make up a list of all the desirable attributes of a, kind of an agile coach or what Scrum teams would call a ScrumMaster, on a project, certainly having the knowledge of how to do the job is on the list. Right? I mean, I would love to have, even in a traditional world, I would prefer to have project managers that have done the job in the past. It’s going to help you when the team says, “ten days,” when a developer says, “This’ll take ten days.”  And if you know something about it you might know, you know, “Is it really going to take twenty and this developer just isn’t seeing part of the problem?” Or maybe you’re looking at it thinking, “[wow] ten days is kind of  a long time for that … is he sandbagging…what’s going on?” So having technical knowledge of things is certainly a desirable attribute, but there are so many other things that need to happen on the project, that that’s just one of many factors for me.

I mean, I’ve hired plenty of project managers into agile teams that did not have a technical background, a coding background. Right? They knew how to manage people; they knew when somebody said ten days they could look at their body language and other things. You know, is the guy confident in that? Is he kind of looking down at his feet? Those type of things that help you make up for that. Just knowing people is a big advantage there. So to me, technical ability is just one of many attributes-- love to have it, but to me it’s not a make or break aspect there.

Now in terms of the project manager, I don’t typically see a project that needs both a project manager and a ScrumMaster. Right? Typically the project manager becomes the ScrumMaster if they have that type of process and impediment removing desires. If the project manager is somebody who’s worked in that company or that domain for a long time, and they really know something about the product or customers, they shift into more of a product owner role, defining what we’re going to build. A lot of times, project managers shift in either direction.

Dave Prior: And if you want to find out more about Mike, here’s where you can go to learn more about him, Scrum, Mountain Goat Software, all of it.

Mike Cohn: The easiest place to find out about me is www.mountaingoatsoftware.com. … I’ve got a ton of presentations up there; every time I teach at a public class like this, I put my slides up there and sample chapters from books, and things like that. Good site to [visit].

Why switch a failing waterfall project over to agile?

By Anthony Heath

Many people assume that only new projects should switch to Agile. That’s not necessarily true. Switching a failing waterfall project can inject new life into a project, giving it a chance for success.  Moving to agile has both long-term and short-term benefits. 

Long-term benefits

Long-term benefits include increased project awareness for new team members, restored confidence in the original project concept, and the inclusion of clear and present business critical design requirements that were not evident at the project inception and thus fell out of scope.

While waterfall projects fail for many reasons, there is a direct correlation between failed projects and overall project timescale. Part of the reason for this is that long projects often see a fair level of staff turnover. New team members may not understand the original project or may have never been fully integrated when coming onboard. After a certain period of time, even the original team members have difficulty maintaining a clear view of project goals, no matter how well they were articulated at the onset of the project. Switching a failing project from a waterfall-based form of project management to agile methods gives organizations the opportunity to review project goals, analyze past performance, and refresh the project team’s understanding.

Short-term Benefits

There are clear short-term benefits in switching to agile.  As costs rise and no deliverables are produced, failing projects often fall under the critical eye of top-level management.  A switch to agile allows a project to start producing recognizable results in the short term.  This will help to raise the falling opinion and remind the organization of the initial perceived value of the project.

A switch to agile is especially beneficial when a project is struggling to pass the test and review stage. The agile method is especially suitable in this situation as it inherently promotes quick turnaround, fast response, and instant solutions.

For a project with an out-of-control budget, switching to agile will allow for tighter financial control across the much smaller agile iterations. When planning a far-reaching waterfall project, budget is often calculated incorrectly, as it is almost impossible to foresee every possible future problem. Agile, on the other hand, allows for shorter budgeting periods, clearer indication of future budget requirements and tighter controls on overspending.

Conclusion

Waterfall projects often bog down when plans don’t match reality. Switching these failing projects over to agile can yield both immediate benefits and long-term improvements. The implementation of the agile methodology, including its iterative approach to software development, allows a failing project team to quickly revisit and redevelop problem project areas as needed.  This single benefit alone is often enough to save the project, as results no matter how small are deemed preferable to no results at all.