Tag: Methodologies

I think people like a good fight. Certainly the media seems to, as is evident in the world of politics, sports, and entertainment to name a few. In the world of business analysis the current fight seems to pit Agile methods against the Waterfall approach. For the next several blogs we’ll have a Scrum vs. Waterfall match. In corner #1, representing the Agile methods, we have the Scrum framework. In corner #2, representing Waterfall, we have the “traditionalists.”

Round One

Relative Sizing of User Stories (Scrum)

• Tee-Shirt Sizes. For release planning we might use estimates of relative size. When less is known about the user stories (features or requirements) for a release, we can estimate using a broad brush approach. Based on such criteria as how complex we think the user story is, how much effort it will take, and the unknowns or doubt, we give it a tee-shirt size (XS, S, M, L, XL). We can then compare all the user stories and assign relative sizes. For example, we can take one user story and based on the above criteria assign it a tee-shirt size of “Large.” We can then compare all the other stories against this “Large” size and assign the relative value of each story. This relative size estimating can help the product owner (business representative) decide which user stories to prioritize for a release.
• Story points. We can then assign each tee-shirt size story points based on an arbitrary scale, such as the Fibonacci number sequence (1, 2. 3, 5, 8, 13, 21…). If a user story is Medium, for example, we might assign 8 story points. If Large, 13. We can then translate the tee-shirt size of all the user stories into story points. It’s important to remember that these story points are still relative. It really doesn’t matter if a Small is 2 or 3 points, as long as it’s consistently applied.

Relative Sizing of Projects, Phases, Deliverables, Tasks (Waterfall)

For years we have used relative size estimates on traditional projects. I have found this most effective when actuals have been collected over enough time to have confidence in the numbers. While I have only used relative sizing on deliverables (such as a small, medium, or large report), I know of teams that have used them on the whole project, project phases and tasks. As with Scrum, we usually base traditional relative sizes on complexity, effort, and doubt (risk), as well as on the history.

Round 1: Scrum wins, but it’s not a knock-out.

In my experience using relative sizes on traditional projects is often done to short-change the planning process. With Scrum the relative size of the user story actually gets refined as it approaches the sprint in which it gets delivered. While some traditional teams have the discipline to refine the estimates (as a project manager, I always encouraged it), many more give in to management’s pushback about not changing the date, scope, or cost. Scrum processes, by their nature, encourage change and refinement; traditional processes do not always do so.

Round Two

Scrum Planning Using Delphi (Planning Poker)

 Planning Poker uses a kind of Delphi technique to reach consensus on the relative size of the user stories. Each person on the delivery team (but not the product owner) uses a special “deck of cards,” which can be an actual deck or pieces of paper. Each card has a number. If using the Fibonacci scale, the deck would have cards, each containing a number in the scale (1, 2, 3, 5, 8, 13, 21, etc.) going as high as desired. The product owner explains the details of the user story and at the count of three, team members turn over the card with the points they think most appropriate. For example, two team members turn over a 3, one a 5, two an eight, and one a 21. They discuss their reasons for “playing” their cards. Then at the count of three they turn over a card, the same or different from the previous round. Again, they explain their rationale. This process continues until consensus is reached.

Traditional Planning Using Delphi

The Delphi technique involves a group of experts providing their estimates anonymously. Like planning, poker, there are rounds. The experts provide their estimates anonymously. A neutral party collects the estimates, shuffles them, and silently reveals them to everyone at the same time. No discussion is supposed to occur. Rounds continue until consensus is reached.

On traditional projects I have tried using Delphi anonymously only once. It didn’t work. I have found the real power of Delphi is in the discussion of each person’s assumptions about the estimates, so as a project manager, I modified Delphi to allow discussions between rounds.

Round 2: Scrum wins, but again it’s not a knock-out. I love the Delphi technique. I love having the team reach consensus on estimates, whether traditionally or through planning poker. It provides team accountability for the estimate, and increases the chance of team and individual commitment rather than compliance. So what difference does it make whether traditional Delphi or planning poker is used? Everyone can understand planning poker. I have seen teams take to this technique immediately. So while Scrum makes things easy and practical, the traditional Delphi, including its name, feels arcane.

So, the current score is two zip. But the match is not over. Much more to come…

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