Skip to main content

Author: Kevin Aguanno

The “Ideal” Iteration Length Revealed…

Written by Kevin Aguanno on . Posted in Articles. 3 Comments on The “Ideal” Iteration Length Revealed…

As agile project management methods are becoming more widely adopted in companies around the world, many of those companies struggle with one of the most basic decisions when starting iterative incremental project approaches: what is the ideal iteration length to use? Let’s see if we can tackle that question.

Definitions

First off, for those of you new to agile management concepts, an iteration is a defined timebox during which a portion of a solution is worked upon. There is a lot of misuse of this term, as many people mix up the terms iteration and increment.

Strictly defined, an iteration is a timebox used in an iterative project model. In an iterative model, a whole solution is developed over the course of a project, with snapshot views of “work in progress” being presented to the sponsor and/or stakeholders for feedback at the end of each timebox cycle, called an iteration. In this model, the solution is not completed and fully tested until the end of the project.

In an incremental project model, the aspects (features) of a solution are prioritized and are completed in order of priority. Each increment is a timebox during which a selected group of features are completed and fully tested. Under incremental approaches, there is no work in progress at the end of any increment. Instead, each timebox adds more complete, working features to the ones already developed, growing the completed solution over time.

Agile methods combine both iterative and incremental approaches. As such, a timebox in agile (also called an iteration) defines a cycle during which an increment of functionality is completed. Yet agile tends to have a broader view of the solution than pure incremental methods (more about that in a future article).

Standard Iteration Lengths

There is no consensus in the agile community on the ideal iteration length. The Scrum method suggests 3-4 weeks as an iteration length, while eXtreme Programming and Feature-Driven Development suggest 1-2 weeks.

When choosing a standard iteration length, you should consider your team’s maturity with agile methods. Generally speaking, teams new to agile should probably start with iterations on the longer side, and then choose shorter iterations as their expertise with the new methods improves.

That being said, the shorter the iteration length, the more a team needs to rely on automated tools to help with project work. In software development projects, this means automated build and automated testing tools, primarily. This is especially important in later iterations in the project, where there is a growing list of new features that need to be regression tested every iteration – eventually, they can’t be fully regression tested by hand in the available time.

Another factor to consider is the value that can be received through shorter versus longer iteration lengths. If you have limited opportunities to meet up with the sponsor and stakeholders to make end-of-iteration demonstrations and capture resulting feedback, then perhaps a longer length might be more realistic. On the other hand, if your sponsor is very concerned about eliminating risk in the project or if you want to build trust by showing rapid delivery of value in the early stages of a project, then perhaps shorter iterations are in order. You need to think about how you can optimize your delivery of business value through your iteration length. Business value is often measured in dollars, but it can also include other elements like strengthening relationships, risk reduction, improvements in service levels, rapid learning, and many more factors.

Variable Iteration Lengths

Having a defined iteration length for your project that does not vary helps the team “get into the groove” or adjust to the cadence/rhythm of working under, within a particular timebox. This iteration cadence is important in helping the team optimize their internal processes as the project proceeds through its multiple iterations. As well, it helps the team perform at higher levels, as the members can estimate more accurately and build more accurate plans.

There is a case, however, for occasionally varying iteration lengths within a project. While this can be a controversial position with some purists, it bears closer examination. In rare circumstances, it may make sense to break the cadence of the team to include a longer or shorter iteration for specific business reasons. Perhaps you have one large piece of work that cannot meaningfully be broken down into pieces small enough to fit into a single iteration. For example, if your project is to install and configure/customize some complex packaged software, perhaps the first iteration is to perform the base install, while future iterations are devoted to the customization of that package. In this case, the first iteration could be 3-4 weeks to get the base infrastructure set up and working, while future work could be a series of 2-week customization iterations. In another example, you may have standardized on 3-week iterations throughout a project to develop a new product, but then switch to a short series of 2-week iterations to rapidly adapt to feedback from key customers once the project has reached a critical mass of functionality, or after it has been announced at a key industry trade show. In both of these cases, there is a specific business benefit to varying the iteration length – though I am careful to point out that I am not suggesting that you vary the length of each iteration; what I am proposing is that there may be business value in switching iteration lengths during a project.

Please note, however, that switching iteration lengths does not come without cost. As mentioned before, you will likely break the cadence of the team, possibly reducing their performance slightly until they adjust to the new rhythm. Also, you’ll have to be careful with how you are tracking and forecasting using velocity, as the metrics will recalibrate as the iteration lengths change. You may not be able to reliably compare pre-change metrics with post-change metrics, at least not without detailed explanations and careful consideration.

Conclusion

Ultimately, there is no ideal answer to the iteration length question. What is important is that you choose a length that is suited to your team, the technology available, and the project context, and the business case. While you may start with a default iteration length for your organization, it is wise to consider all of the above factors and adjust that default length if it will help optimize your project, while still respecting overall organizational objectives.

Don’t forget to leave your comments below.

Project Managers vs. Scrum Masters; Agile Project Management Matures

Written by Kevin Aguanno on . Posted in Articles. 5 Comments on Project Managers vs. Scrum Masters; Agile Project Management Matures

There is a lot of resistance in the agile community against project management.  Many (though not all) proponents of agile methods feel that project management is the root of all evils.  To understand this perspective, we need to look at how agile methods were evangelized in their early days.

Even though you can trace the roots of these methods to the 1930s, most of them were developed in the 1990s with the name “agile” being adopted in 2001.  Early proponents of these methods had to make bold claims and controversial statements to be noticed, as the new methods they were proposing were outside of mainstream development management processes.  Of note, is that these early agile proponents came (almost exclusively) from the technical world, being software architects and developers.  These development team members felt that traditional processes were causing them endless grief and lots of waste on high-change or highly-complex projects.  The person enforcing these traditional methods was the project manager; thus, the project manager was put forth as the representation of all that was going wrong on traditional projects.

To be fair, in the early 1990s, very few people had heard of these new methods, and when facing a troubled high-change project, project managers were baffled with why their traditional management methods were failing.  Business executives, determined to make things better, pushed the project managers to apply the traditional methods even more vigorously, often to the point of complete project dysfunction.  This just further reinforced the image among the technical team members that project management was the root of their problems.

Since project management is a key role on most projects, the agilists created new roles that they refused to call “project managers” as an expression of their rebellion against traditional project management.  These new roles took on names like Scrum Master, Development Manager, Delivery Manager, and several other titles that all encompassed all or part of the traditional project management role.  Nevertheless, many in the agile community will strongly deny that Scrum Masters perform some of the job of a project manager.

Now that project managers have more tools available to them such as agile project management techniques, they have a different set of options for responding to high-change projects.  Still, many people in the agile world recall the early days of the agile movement when technical team members often saw project managers as the enemies.  They are shocked to find that project managers have now joined the agile movement and are looking to apply agile principles to traditional project management practices.

To overcome this criticism of project management, we first need to look at good (or even excellent) project management when we are assessing its applicability to a situation. There are a lot of incompetent or mediocre project managers running around out there, just as there are a lot of incompetent Scrum Masters running around with the ink still drying on their certifications. To be fair to everyone, let’s look at what each role should look like.

An excellent project manager does not try to attack all problems with the same tool; rather, he (or she) analyzes the situation, figures out what problems should be dealt with at all, then prioritizes them, and then chooses the appropriate tools. This is all done in cooperation with the sponsor and other stakeholders, as well as the senior project delivery team members — after all, if you don’t get buy-in from the stakeholders, sponsor, or team, then the approach is just not going to work. (At this level, it is very similar to agile.) The key skills here are collaboration, communication, and negotiation.

Excellent project managers will chose techniques (or even methodologies) to address specific problems. For example, if requirements are fuzzy or stakeholders are having trouble understanding the solution being proposed or a technical solution is experimental and high-risk, then an iterative, incremental approach is best. If the requirements are very stable, stakeholders in alignment, and technology is low risk (such as building yet another package of custom reports for a system for which you have developed custom reports many, many times before), then a more linear approach (a.k.a. “waterfall”) may be the most efficient way to deliver the project. (With the complex solutions we seem to face more and more these days, projects tend to resemble the first example far more often than the second.)

Another key point is one of leadership, communication and collaboration styles. Excellent PMs will understand that they need to vary these styles based upon the needs of the individual team members and the nature of the situation. Excellent PMs choose skilled team members, help everyone converge on a common vision of the goal, facilitate a consensus on the approach, gain agreement (signoffs, etc.) and then let’s the team do what they know how to do best. A PM trying to tell a Java programmer how to do his or her work is a recipe for disaster — the PM should focus on overall risk, communications with stakeholders, financial tracking and management, delivery strategy (alignment between interdependent projects, alignment with key business dates), and helping the team stay productive by taking project issues off of their hands.

Senior (and “enlightened”) PMs tend to take a more collaborative approach to working with their teams. These PMs work alongside the others as part of the team — NOT “leading” the team — and act as team members with an equally-important but separate role. When I manage projects (agile, traditional, or somewhere in between) I see my job as serving the team, not running it. The team members can delegate things to me that they can’t or don’t want to deal with such as finding support for a product they are using, escalating on a group that is not providing materials on time, shielding the team from interfering stakeholders, etc.

The PM role (when done properly) pretty much covers the job of a Scrum Master.  They do the same things: manage scope (backlog), build schedules/plans (iteration plans, release plans), manage change (backlog maintenance, updating release plans, etc.), track and report on progress (burndown, velocity, etc.), track and manage quality, manage risk, manage the overall delivery process, etc.

In Scrum, a Product Owner is responsible for the contents and the prioritization of the contents of the backlog (the overall project scope). When looking at real-world situations, however, you find that you are often lucky to get an hour a day with the Product Owners as they are busy running their existing businesses. In many situations, it is the Scrum Master who makes the backlog updates, guides the Product Owner through the agile process (especially since many POs have had no formal training on their role), and influences the prioritization decisions by explaining some of the impacts/tradeoffs of prioritization decisions (along with the technical team members). These can be seen as some aspects of “managing.” Note that managing does not mean “owning.” But even that explanation does not go far enough.  If you are a Scrum Master of a project with an external customer (meaning a separate company) then someone needs to manage the scope of the contractual commitments. Depending upon how your contract was written, that may require a one-page change order at the start of each iteration detailing the stories (scope) that is being authorized for the upcoming iteration. You cannot ignore the legal obligations of the agreement, and to ignore the paper trail authorizing scope changes leaves you open to claims of negligence and litigation. (I’ve seen it before in some of my troubled project recovery work. There are lots of troubled agile projects out there where newly-minted Scrum Masters failed to take basic financial management or scope management steps –largely because they were not mentioned in their Certified Scrum Master training — and left their company open to lawsuits.)

On all agile projects, the team members (including the technical members, the Scrum Master, PM, sponsor, and others) need to all work together to come up with a plan that works for everyone. There are lots of technical and business tradeoffs that need to be balanced during the planning process, and everyone needs to have their perspective included. However, at the end of the day, someone takes notes, someone builds the “plan” that gets posted and communicated outwards (if relevant) — this person is usually the PM or Scrum Master, as the technical team members are busy sizing stories, doing design, etc. and the Product Owner doesn’t have the skills (nor the motivation) to do this. As for the iteration scope (sprint backlog), the data to build it and update it comes from the team, but the work to do the initial build or update is an administrative task that usually gets assigned to the Scrum Master — unless you have a tool like VersionOne that makes the updates quick and easy for the team.  Even though there are good tools out there, most people I’ve seen still end up using Excel spreadsheets for their backlogs.

Tracking and reporting progress is, again, an administrative task that the development team likes to get off of their plates. The building of reports and communicating that information usually falls to the Scrum Master so that the technical work can progress most efficiently. Yes, the team does get together to review metrics and discuss progress; however, in most large companies, the teams have almost no say in what gets reported. There are standard financial reports to prepare (Sarbanes Oxley, anyone?), project portfolio management tools to feed, and many, many information stakeholders to satisfy. To say that the team can decide what to report and in what format only works in theory or in smaller companies. Try that in a major bank, utility company, or (gasp) a government department.

And when you are trying to do agile within large, complex and bureaucratic organizations, you’ll find Excellent PMs have a leg up on Scrum Masters. Scrum Masters get little or no formal training (there are significant variances between the offerings of Scrum trainers) on subjects such as mandatory earned value reporting for agile projects, adding governance structures to deal with compliance and audit requirements (e.g. FDA), and much more that you will find on real-world projects that make our projects less agile than the theoretical model people are trained in, yet are nevertheless constraints we have to live with every day. This is where an Excellent PM will bring all of the other management skills and experience that go beyond agile to the table to help the project navigate through the complexity.

To manage complex projects, Scrum Masters need more than just the governance-type issues above. There are other traditional management skills needed to make a successful project such as negotiation, interpersonal conflict resolution (when team members don’t get along with each other), communication strategy (for stakeholders – called “chickens” in Scrum parlance), political awareness… and the list can go on and on.

Agilists who think that project managers can only prevent agility from working reveal that they have too narrow of a focus. Perhaps in a truly agile organization with appropriate agile-friendly processes and agile-trained stakeholders, this may work; however, from what I have mentioned above, in large, complex organizations, where agile is an experiment or only used in some pockets of the business (which is very, very common) the PM can help by working to create an environment (bubble) where agility has a chance of succeeding while the PM protects the team from outside non-agile forces.

In conclusion, I think that I have shown the complexities and subtleties of the Scrum Master role when employed in large, complex, real-world projects. Classically-trained PMs are often the ones who will be governing a Scrum project in a large corporation — whether there is a Scrum Master assigned to the team or not — to help the agile projects fit in to the complex governance structures in place (often for very good reasons) in these environments. Do I think there are opportunities for removing some of this governance? Yes, of course — that is one of the first steps I take in recovering troubled projects using agile methods — the bureaucracy is often holding back progress; yet, some of it is there for a good reason.

I don’t care whether you call the role a project manager, solution manager, delivery manager, Scrum Master, technical lead, project coordinator, or some other name — the work of project management still needs to get done on complex projects.  The new agile project management movement is one very good way to address this need.

Don’t forget to leave your comments below

Kevin Aguanno, PMP, IPMA-B, MAPM

is an Executive Project Manager specializing in troubled project recovery using agile methods.  He is the author of over one dozen books on agile, is an award-winning trainer specializing in teaching “disciplined agile” to project managers, and is the thought leader behind the new Certified Agile Project Manager qualification available from the Project Management Association of Canada (www.PMAC-AMPC.ca). Kevin is also a regular blogger with Project Times.

Getting PM Training without Breaking the Bank

Written by Kevin Aguanno on . Posted in Articles. 6 Comments on Getting PM Training without Breaking the Bank

In these troubling economic times, companies are slashing their training budgets as a means of getting costs under control and more in line with dramatically-reduced revenues. Classroom training opportunities are being cancelled every day, with the excuse that tuition, travel costs, and lost productivity makes the whole exercise financially unviable.

Yet, project managers still need ongoing training. People new to the profession need basic training; new hires need training on specific company management policies, practices and systems; and experienced managers need ongoing training to keep their skills current as the processes and tools they use evolve over time. Without training, an organization’s capacity quickly diminishes, eroding the project delivery team’s ability to successfully deliver new projects. We cannot allow these training budgets to be cut any further; or we won’t be positioned well to take advantage of the economic recovery that will eventually come our way.

So, how do we balance the company’s need for cutting costs while still preserving training opportunities for our staff? Well, many companies are turning to remote training offerings as the compromise between these two extremes. Webinars, teleseminars, and e-courses are training offerings that eliminate travel costs and generally cost only a fraction of their classroom equivalents. On top of that, by breaking courses down into small bite-sized modules, students can choose which modules they need, reducing the amount of unproductive time spent sitting in a class reviewing material that the students already know.

Teleseminars are lectures and group discussions delivered on a group conference call over the telephone. Some of them have web interfaces where students can type in questions for the speaker or click a button to “raise their hand.” They are generally the cheapest of the three remote training offerings. Calls may be recorded allowing for later playback.

Webinars are like teleseminars that have a visual element. Often, these visuals exist as slides in PowerPoint or a similar application. As the teacher is presenting the slides, students can see them change automatically through a web-based online interface. The student view changes in synchronization with teachers. Many of these systems allow for online messaging (chat) between students or with the instructor. Some also have the ability for one participant to take notes that can be shared with the rest of the participants. Students hear the instructor speaking either over a telephone line or through their computer speaker or headset. In some systems, the students can even ask questions via their headset microphone.

The “poor man’s webinar” is a teleseminar where the PowerPoint presentation is distributed to participants in advance, and the students follow along with the teacher by manually switching slides as the teacher announces the slide changes.

E-Courses are online course modules with both audio and visual elements, typically without an instructor, that students can take at any time. This ability to take the course modules at any time is one of the most powerful features that distinguish this option from webinars, which are pre-scheduled events. E-Courses may also have tests, simulations, and other interactive features that can improve the learning experience.

Major project management training providers have been offering all three options for years, with more and more getting on the remote training bandwagon. Thousands of project management-related webinars and teleseminars take place each year. Some are free, while others have a registration fee. It pays to research the training provider. Many vendors of products offer webinars or similar events on general PM topics that are thinly-disguised advertisements for their products. Also, you tend to get what you pay for; meaning, free training often only gives very high-level overviews of topics where the real meat of the subject is delivered via follow-on offerings that have a cost associated with them. Training companies use these free training events as teasers to attract students who can sample the quality of their instructors. Some of the viewers will buy the follow-on training offerings.

Don’t get me wrong – many excellent inexpensive or free training offerings are available. For years, the PMI ISSIG (www.pmi-issig.org) has been offering top-notch webinars free to its members. Other non-profit groups such as the Project Management Association of Canada (www.pmac-ampc.ca) offer high quality but low-cost teleseminars and webinars. There is no comprehensive central directory of project management remote training providers, but a simple Google search will reveal many available offerings.

Don’t forget to leave your comments below

Best Practices are Still Best Practices

Written by Kevin Aguanno on . Posted in Articles. 3 Comments on Best Practices are Still Best Practices

I do a lot of consulting on the adoption of agile management techniques. What I keep seeing are the same issues popping up time and time again. While lots of good information has been circulating about agile project management for the past decade or so, misperceptions abound.

One problem that I find puzzling is the frequent appearance of misunderstandings about the need for “best practices” on agile projects. Yes, agile methods promote different techniques for requirements management, scope management, estimating, scheduling, communications, and quality management. However, these techniques are not new – many were developed in the middle of the last century and have been often used on large, complex projects. Agile management frameworks simply gathered together the existing “best practices” for complex or high-change projects. So, saying that agile methods are not “best practices” is false – agile methods are one set of “best practices” for managing projects with certain common characteristics.

This battle between factions with their own methodology preferences does not surprise me, however. The issue that really puzzles me is the confusion over best practices for project startup.

In most organizations, there are certain management control points (also known as “stage gates”) to manage the funding allocations and project approvals. Usually it follows a pattern something like this:

  • Someone comes up with an innovative idea and presents it to management to get approval to spend some time and money thinking through the concept and coming up with an initial guess at what the business case might be. The management approval to spend that time and money doing the investigation is called ‘Passing through Gate 1.’
  • Next comes the development of the initial business case. This will include high-level numbers, many of them educated guesses or placeholders for items where further research is needed. This initial business case is taken for review by a funding committee who determine if the benefits of the idea adequately exceed the costs of implementing the idea. They challenge some of these initial business case assumptions, and may discount the benefits or increase the costs in order to reflect their confidence in the ‘guesstimates’ used in preparing the figures. The committee may decide to stop further investigation into the idea, or may provide further funding to build a ‘real’ business case that contains numbers with something behind them other than a best guess. Such as decision passes the idea through Gate 2.
  • Once through Gate 2, the goal is to do some up front work to see if a project is truly feasible. This work includes gathering and documenting high level requirements, performing initial analysis, high-level design of a solution, documenting scope, preparing effort and duration estimates, building an initial implementation schedule, and documenting estimating assumptions. In essence, preparing a traditional project proposal. This proposal is again presented to a funding body that makes a decision whether to proceed or not with the project. Approval means passing through Gate 3.
  • Finally, the project can begin for real, with the detailed requirements analysis, detailed solution design, refined estimates and plans, and validation of assumptions that happens at the start of a complex project. There may be a pilot or proof of concept phase that may validate the estimates and plans (and ultimately the business case costs) with real metrics captured from the proof of concept. If proof of concept is reviewed and approved before a project can proceed in full, it is called passing through Gate 4.

There is a lot of misunderstanding about where agile management techniques fit into this model. For an agile team to come up with its initial list of scope (expressed as ‘user stories’) there needs to be some requirements capturing and analysis and some high level solution design work completed so that the project team knows the solution for which they are providing development estimates. And, these estimates feed the construction of an initial schedule, called a ‘release plan.’ This work needs to get done in an initial iteration, often called ‘Iteration Zero’ or ‘Sprint Zero.’ If you think about it, you’ll see that this is the work we normally do to pass Gate 3 – the development of a proposal for funding of the development work of the project.

Some individuals have misunderstood how agile projects work in the real world. They believe that the project should start immediately with developing a solution in the first iteration. Some even say that doing up front analysis and design is going against agile principles. This could not be further form the truth. No matter whether you are following serial/waterfall-type management methods, or agile management methods, the work that needs to get done at the start of a project does not change – best practices are still best practices. You cannot build a plan (even an agile one) without some estimates. And to estimate, the team members need to understand the scope they are estimating to build, and some characteristics of the architecture/design of the solution. And who can prepare a scope and design without knowing at least the high-level requirements? The difference is not in the nature of the work that needs to be done, but rather in the level of detail needed in this first instance. Most serial/waterfall teams will do much more analysis and design work in this initial proposal phase than agile projects, mostly due to the difficulty of incorporating changes later in the serial/waterfall processes. Oddly, the business cases for serial/waterfall projects still often present ranges in their budget and schedule estimates, even with the extra analysis and design work that is usually done.

Regardless, best practices declare that some up-front work needs to get done before estimating and planning. Both agile and serial/waterfall methods require that this work get completed before the real solution development work begins. Many agile teams seem to forget or deny this and end up in trouble. Unfortunately, I find too many of them in my troubled project recovery consulting work. This is not a flaw in agile project management methods, but rather one in maturity in understanding the nuances of how agile methods get deployed in real-world scenarios. Classroom learning is not enough – for initial attempts and using agile methods, organizations need some agile-experienced help to coach the teams through the process.

Don’t forget to leave your comments below

Ending the Methodology Wars

Written by Kevin Aguanno on . Posted in Articles. 1 Comment on Ending the Methodology Wars

I was in a meeting the other day when I encountered a bizarre exchange between a project manager and her project sponsor. I followed up after the meeting with both of them individually to try and figure out what was going on behind the scenes. Clearly, such strange reactions indicated some political intrigue was brewing in the back rooms and hallways of the organization.

What came out of my investigation was a better insight into how poorly we communicate when discussing change initiatives – and most projects could easily be classified as “change initiatives.” The project manager and the sponsor thought they were miles apart in their perspectives and were arguing over their different approaches. The project manager, after assessing the unique characteristics of the project, strongly believed that agile management methods were best for optimizing the delivery of that project. The sponsor was concerned about governance, control, and risk. As a result, he went with the only approach that he knew that provided the maximum control: a serial/sequential (a.k.a. “waterfall”) approach to project delivery.

Ah, it was the old “waterfall versus agile” argument – many have seen this before in their own organizations. What was interesting here, though, was that what the two parties were saying about the other’s approach shone a clear light on the problem underlying the whole argument. The project manager and the sponsor were not arguing over methodologies; rather, they were poorly communicating their concerns (fears) about the project and their own hidden desires for what they want to get out of the initiative.

The sponsor had deep concerns about the ability of the IT team to deliver. In the past, they had surprised him on numerous projects with requests for additional time and money due to a range of reasons that he felt they should have been able to predict better: unstable technologies being used, inadequately-skilled resources assigned to the project, the impact of assigning people to multiple simultaneous projects and the conflict in priorities that this creates for them on a daily basis, significant design defects uncovered late in the testing cycle at the end of the project, and many other examples. In short, the sponsor had no trust in the IT team. As a result, he wanted to fall back on what he knows best: a strong command and control approach to this mission-critical project. So, he was trying to impose a sequential phasing approach, with management stage gates for control points, and requests for detailed plans up front that incorporated risk mitigation activities and accounted for all of these possible problems.

The project manager, understanding the critical nature of the project, wanted to ensure a quality delivery in the most efficient way possible. She used agile approaches for the benefits of continuous prototyping and testing flush out any serious defects early on in the project, with lots of time left to correct them and still make the delivery date. She also liked the ability of the agile approach to minimize overall project risk on such a complex initiative. In the past, when her IT team had tried to do an up-front design for a similarly-complex system, the team got mired in trying to come up with a “complete” design, when the detailed requirements were still emerging. She saw agile methods as a way of dealing with the change and the complexity of the solution.

What really struck me as interesting was that both parties wanted the exact same things: a reduction of risk, a high-quality output, and the completion of the project in a relatively short period of time. What was underlying the argument was a misunderstanding of each others’ terminology and unstated desires. Let me address these separately.

If the two parties trusted each other enough to share what they really hoped to achieve with the project – on a personal level – then they would have more quickly come to agreement on the approach. The sponsor had made commitments to his own boss about the quality of the product and about the final delivery date – which was tied to his own performance review – so he was fearful about schedule delays, which was why he was insisting on so much up front planning and management involvement; he wanted a level of comfort that his commitments could be met. The project manager was using agile methods that would likely deliver a higher quality output. And agile methods, by building in short iterations and always working only on the next most important items, would ensure that if problems arose and something had to give to make the sponsor’s key deadlines, then the scope items to drop would be naturally the sponsor’s lowest priority ones (especially if his performance bonus was on the line).

The terminology differences would perhaps be easier to resolve. The sponsor was concerned over the use of extreme programming (XP) techniques on such a critical project. In his mind, he didn’t want anything “extreme;” rather, he wanted stable, predictable, and guaranteed. As soon as the word “extreme” gets mentioned, his back goes up and his fear increases. Instead of continuing to push the use of XP, the project manager should have discussed the practices in XP that would minimize risk, improve quality, and improve communications and visibility thereby addressing the concerns of the sponsor. We often get caught up in the extra meanings that we layer on to words and end up dealing with the emotional response which clouds our rational thinking. We need to be aware of this issue, and take care in choosing our words. My advice to the project manager would have been to suggest that she focus on the business benefits of the various practices, describing them in non-technical business-stakeholder-friendly terms. In that way, she would have been talking in her sponsor’s own language, describing how she is addressing his personal concerns, and showing how his business case needs were being addressed.

So, these methodology wars that we come across in our organizations can be avoided. We just need to be more careful with our communications. In the end, both parties usually are trying to achieve the same thing.

Don’t forget to leave your comments below