There’s really only one way to travel down a waterfall – in a barrel. A lot of people died this way, but some survived. Software projects have been predominantly waterfall projects since the start of software projects. And stakeholders rode down those projects, basically in a barrel. The people riding Niagara Falls 100 years ago didn’t know if they would survive until they got to the end. Stakeholders in waterfall projects don’t know if they will succeed until the end.
An agile project is dependent upon tight interaction (and feedback) with stakeholders.
If you’re running an agile project, and your stakeholders are old-school barrel-riders, how do you make it work?
Expectations, Documentation, and Communication
The success of any project is dependent on setting and managing stakeholder expectations. In Managing Stakeholder Goals, we talked about assuring that those goals are addressed by our requirements. And in a later article, we proposed a way to balance the goals of different stakeholder groups when those goals are in opposition. Those are good tools for making sure we are initially aligned with what we are hearing from stakeholders.
We need to also apply active listening techniques to assure that what we thought we heard is what the stakeholders thought they said. One way to do that is to write use cases (or user stories) so that we can communicate the intent of the product back to the stakeholders. This still primarily helps with kicking off a project, in the desired direction, with the correct goals.
There are many ways to document this initial intent of the project and stakeholder goals. It is analogous to a stakeholder selecting a sturdy barrel and picking a good spot on the river bank to push off. We’re well positioned to eventually succeed, assuming nothing changes. After a harrowing fall, we find out how well we did.
A well-run waterfall project will provide status updates to the stakeholders along the way. Imagine your stakeholder wearing one of those in-helmet headsets that NFL quarter backs use. We publish effective status reports to let the stakeholder know what’s going on. Like the falling barrel, however, a waterfall project has inertia. The project, barring significant outside influence, will keep going in the direction it started. Projects have change control boards to manage that change, but emotionally, I find that a formal change-approval process tends to inhibit change, rather than encourage it. That barrel will keep falling.
Some project teams will try and do very heavyweight documentation to maximize the likelihood that the project will end up where it should. The problem is, this heavyweight documentation only improves the chances that the project will end up where we used to think it should go. It does not help us change the trajectory of the project as new insights are gained. Just as responding to those changes provides a competitive advantage, ignoring those changes exposes a competitive weakness. Someone will come along and exploit your weakness if you don’t respond to change.
From these dynamics, we can conclude that “big up-front requirements”, while better than “no requirements,” are actually a waste of energy and time, relative to an ongoing adaptation to change. That adaptation to change, however, should also be documented. It needs to be documented for two reasons – to manage expectations of stakeholders, and to keep the implementation team focused on creating the most valuable capabilities in your product. As you get smarter about what is valuable, you need to apply that knowledge and change the path of the project.
This is where communication becomes critical with stakeholders too. Especially the old-school barrel-riders. They are used to being in the barrel, maybe with an occasional “looking good – you’re still falling straight down” message along the way. They are not used to hearing “we’ve decided that gliding over the rocks is more valuable than falling – please extend your wings now” messages. The shocked “what wings?!” response is what they immediately think.
Agile Expectations
An agile project will avoid the big up-front requirements, and gather just enough requirements for right now. What your stakeholder might hear is “agile is magic – we don’t need detailed requirements.” The real message is “agile is better – we don’t need details about the requirements yet. But we will need them later.”
A given team needs the same amount of specificity in requirements to achieve the same result, regardless of project approach. One team I worked with would not set the tab-order in a form to go from top to bottom if you didn’t specify that. It simply didn’t occur to them. Another team was very effective with “gather the following data in a form…” – and they would layout the form, manage tab order, add reasonable field validation, assure proper markup and support for screen readers (for visually impaired users), and implement a candidate error-message/feedback design for users. The first team would never succeed without details, the second team would view those details as wasted effort by me to write them, and by them to read them.
I think most of the initial creators, proponents, and early adopters of agile processes are members of the second camp. They designed agile to not require detailed documents, but to allow it when needed – because they acknowledged that some people need the details. They were reacting to heavyweight processes that were designed to work for “any team” at the cost of slowing down the best teams. Kent Beck told me once that when people tell him about the importance of testing, his response is “so, lack of testing burned you before?” When people stressed the importance of gathering requirements, his response was “you’ve been burned by a disconnect with stakeholders.”
Enough is the operative word here. You have to document enough. You have to communicate enough. You have to set expectations with your stakeholders that things will change. And as those things change, you have to stay joined at the hip with your stakeholders to validate those changes.
While your team is responding to changes (based on feedback from stakeholders and the market and competition and implementation discoveries) with new plans, you have to feed that information back to the stakeholders. It is a two-way communication. And it needs to be a continual communication.
I joined a six month project once in the last month of the project. Here’s a sanitized sequence of events describing what happened.
- Initial vision for the project was defined and requirements defined and tied to goals and value.
- The estimates came back and said “no way it will happen before the business-imposed deadline.”
- The team said “let’s be agile” and chose a component of the vision to do first. That component could be completed by the deadline, and stakeholder expectations were set – (a) do this visible thing first, “meet” the deadline, and then (b) regroup, re-prioritize, and then do the next thing next.
- The team started developing the solution, and worked for 5 months. After 5 months, someone concluded “we won’t finish by the deadline.” A couple weeks later, the estimate was that the team still had between 1/3 and 1/2 of the work remaining to complete the first component of the vision.
- In presumably unrelated events, all but 2 of the internal stakeholders left the company. Literally.
- When the CIO and president of the company engaged the project team, they weren’t thinking “we have an over-run on the first component of our vision” – they were thinking “not only is it not done, but what you’re trying to do is not the right thing.”
- Project was stopped one week after the original deadline for the first component (which was not completed).
It may be that this was unavoidable, but one thing was clear – the “build the first thing first” expectation was not communicated effectively. It didn’t help that the team did not track velocity, so it wasn’t until the end of the project when the “you’re going to hit the rocks” message was first heard by the stakeholder in the barrel. Way too late to affect change. For this and other reasons, I contend that the project was not agile. It was a Chevrolet with a Ferrari sticker on it.
We can ignore the labeling of the process and focus on the lack of ongoing expectation management as the ultimate doom of the project.
Evolving Expectations
Patrick Masi had a couple great comments on our Simple Agile Model article. Patrick pointed out a problem with simple documentation artifacts like this. The early “here’s all we need right now” artifacts were insufficient to capture the full extent of what the stakeholders needed. I’m not sure exactly where things broke down, but Patrick implied that the ongoing clarification with stakeholders was not happening.
This is a completely different manifestation, I suspect, of the exact same problem described above. Thinking about Patrick’s comments is what got me heading down the whole “barrel rider” path in the first place.
I don’t believe I’ve worked with any stakeholders who would say “yes, ignore what we learned this year – it is more important to build last year’s product.” I’ve definitely worked with stakeholders who did not have time to commit to the support of an agile project. The ironic thing about agile projects is that they may do more requirements work through the course of the project than non-agile projects. An agile project will respond to change. That means some work is re-done. It also means that some valueless work is avoided. You can’t categorically say which influence is larger.
One possible source of the pain Patrick’s team felt is mis-set expectations of what is being delivered when. Imagine developing a checkout-process for an eCommerce website. The complete checkout process is too large for a single sprint, so you break it down into valuable atomic deliverables for each sprint:
- Registered customers can buy any products, using previously saved billing / shipping info.
- Individual product and “per order” discounting works and customers can use gift cards to pay for all or part of the order.
- Anonymous customers can place orders (without accounts) and registered customers can modify billing and shipping information.
- Orders can be placed as gifts (with gift receipts and wrapping services), and online call-center reps can interact with customers real-time to help with the process.
This is a nuanced message – basic checkout in sprint 1, with increasing capabilities in each sprint, until “complete checkout” is done in sprint 4. That is a reasonable plan, but requires a more detailed conversation with stakeholders so that they know what is coming and when. You don’t want someone freaking out after the 3rd sprint when they can’t place gift orders.
Another possibility is that the elicitation process before the third sprint (re-visiting checkout again with the same stakeholder) did not tease out that anonymous users must provide an email address (for order confirmation email, and to secretly create a “shadow account” for that customer). All of those details need to be gathered, and it can be harder to spread out the conversation over multiple sprints than it is to have it all up front. This is just incomplete discovery, but with delayed (and recurring) impacts.
In User Stories Applied, Mike Cohn stresses that the brevity of user stories is intentionally designed to facilitate (and I would add “dependent upon”) conversation. I find it to be both a strength and a weakness of user stories. It is strong because you can cover a lot of ground quickly (breadth) and capture a number of stories, much like the list above. It is weak because the requirements documentation does not stand on its own – it requires conversation to fill in the details. I’ve had some success using the “Verify that…” user acceptance tests as the method of documenting those details (depth), in conjunction with the brief, easily consumable stories.
You can write the stories quickly to decompose and schedule across sprints (revisiting the schedule as things change), and then write the verify statements as UAT for each sprint as it occurs.
Another benefit of the UAT is that it is explicit and cuts through the walls of the barrel for a stakeholder who “doesn’t get agile” as Patrick puts it. “Here’s our lightweight multi-sprint plan – now lets define the specific acceptance criteria you need” is a pretty effective conversation.
Conclusion
You have to stay closely connected to your stakeholders – not just for messaging, managing, and changing the big-picture direction of the project, but also to drill down into the details at the last practical moment.
Great post and an excellent analogy for projects. It brings up an excellent question, is there a compelling reason to get in the barrel? Is there a compelling reason to do a project?
One could have a methodology that fits the project and organization, clear communications, talented people and still have a project fail. Maybe it never should have been started or maybe something in the business environment changed or maybe the company ran out of money or maybe people in key company positions rejected the project.
Other times there can be poor communications, competing interests, disobedient people and faulty systems and if the goal is obvious, intuitive and adds enough value, it’ll succeed in the absence of any project planning. I’m pretty sure there were no gantt charts or use cases or WWII or the pyramids.
The best user stories, documentation and communications cannot make up for foggy thinking, unfocused goals and project sponsors who don’t want to take personal responsibility. However, if you have clearly understood goals which add real value so people can intuitively see where their part fits into the overall goal and so see what they should do; then you can probably succeed without any project planning methodology.
“Defeat Hitler” has a compelling ring about it that “improve company processes” somehow sort of lacks.
Thanks Andrew! You raise a bunch of points, I’ll try and address them individually. This blog runs on wordpress, and now supports (at least behind the scenes) threaded comments. I’ll create several response-comments, and eventually the multiple threads may be visible to other readers. Hopefully, at a minimum, all of the comments will show up.
@AM: On ‘improve company processes’ as a compelling goal…
Depends on why the team is trying to improve the processes. Which highlights that this isn’t really a valuable goal. Is process improvement a goal so that the company can reduce costs, increase competitiveness, or is it just busywork? Dell had a compelling ‘process improvement’ when it started – having very rapid turnaround on custom-built computers, plus very low inventory levels gave them both differentiated products and cost structures. Automating a daily 5-minute task to improve “quality of work” for people doesn’t have the same sort of value. Of course neither is as compelling as “Defeat Hitler.”
@AM: On methodology as a panacea – Completely agree. In a way, I guess this is why every project doesn’t succeed. Each stage of (or perspective on) a project provides a veto opportunity. It could be a bad idea, the idea could get mangled in transition to the implementation team, the team could follow a flawed process, or the team could follow an effective process but fail to execute. In keeping with the ‘veto’ theme, stakeholders can ‘pocket veto’ a product or project too. Maybe that’s the analog to stakeholders being disengaged (in a barrel).
I also like that you point out that any or all of these things could be true and a product could still succeed. I remember working on projects that succeeded primarily because of the heroics (both in effort and skill-level) of individual contributors. They made things succeed in spite of vetoes. Maybe the analog is the super-majority, over-riding a veto. As the company I was in discovered the strong correlation between the presence of heroics and success (and the converse!), we started maturing our development model to try and reduce the dependency on heroics. “Just enough process” is a good mantra – don’t depend upon heroics to succeed, but don’t create so much process that you inhibit the heroes either.
This is a really excellent post and analogy that I could really identify with on so many points. Very well done!
Another thing I can think of to add is the point of not just “saying” you are doing agile development (using all the tools, user stories, and “models” but then stalling month after month after month on iterative releases since “not quite done”). Really cutting every now and then is SO core, to actually see “how undone” or “broken” you still are; to learn exactly what is still failing in the whole picture, sometimes with surprises (or to avoid falling into the waterfall mode, like in a barrel).
In my experience, the agile team desperately needs these “reality check” iterations (despite the truth hurts feeling, initially, perhaps), or falling into waterfall syndrome in inevitable – with lost benchmarks at the detail level of the previous release. The previous release becomes so long ago – who knows if we are doing better. I can’t remember the little details of that many many months ago old release anymore – and metric charts are really just glossing over the details at this stage.
Even with the best agile tools, forcing the iteration release is so core.
Again – this barrel analogy is so on target! Great and thanks for the good read!
@EF: Thanks Ellen, and welcome to Tyner Blain!
There used to be a website called beaterz.com, where people would take pictures of cars and upload them. These cars would be low-performance, junky cars, adorned with stickers (think “high performance brand”), painted yellow (because yellow = fast), with over-sized exhaust pipes (for low displacement engines), irrelevant wings (for cars that can’t go fast enough to need them), or with other obviously showy and irrelevant modifications. Sadly, the site appears to be down now.
I think of those cars, the posers of the auto world, when I think about teams applying agile “stickers” to their waterfall processes, or mis-applying agile “wings” and “blowers” to cars (processes/teams/environments) that can’t take advantage of them. It demonstrates a lack of perspective and understanding about why the elements of agile (or any methodology) can work and what can cause them to fail. Things like doing a build every two weeks, but not sharing those builds with stakeholders (both internal and customer). You get the minor benefit of a potentially self-regulating build cycle, but you miss out on the huge potential benefits of managing expectations and staying tapped into the market’s needs. Like the wing on the back of a car going 45 mph – which gives you the equivalent traction control of putting a bag of Cheetos in your trunk.
For ‘reality check’ releases – are you talking about getting the feedback loop working, or something else? I do think that is critical. You also mention “many many months ago” – which touches on another challenge of “reduced documentation” – having some organizational memory about “why we did X” or “why we chose not to.”
Scott,
Dell started with an approach of custom building computers from stock parts, it didn’t come about as the result of process improvement project.
As an industrial engineer, there’s a problem with ‘process improvement’. Businesses only improve financially if you either decrease costs or increase sales. Sometimes projects increase sales, more often their designed to decrease costs. Fixed costs aren’t generally decreased, it’s variable costs which get decreased. The difficulty with reducing variable costs is that most often reducing variable costs equals firing people. For some reason, managers seem to resist these types of cost reductions.
Processes may improve quality, but then all competitors will implement similar improvements. This is a great gain for consumers, but it is not beneficial for businesses. ERP, CRM, KM packages and the like become a cost of doing business, which is not the same as process improvement.
To your point, ‘reducing costs’ isn’t an effective rallying cry, because reduced costs equals layoffs – not so motivating. ‘Increasing competitiveness’ usually means working harder – also not so motivating.
A much better use of technology, from an employee perspective, is to look busy while you’re playing on Facebook or reading blogs…
@AM: You’re right about Dell’s start – but let me put on my “academician’s hat” and say that he was improving someone else’s process. The other manufacturers could not compete on costs even with the same components and the same goal (custom built computers).
Regardless, too much ‘process improvement’ is done for the wrong reasons – I completely agree. I think turning sour on process improvement is like saying email is bad because 90% of it (by volume) is spam. Process improvement is also such a generic term that we could talk circles around it. Much better over a beer than a blog post.
On quality improvement not being worthwhile – I guess it depends on your time horizon. In the 70’s the Japanese auto manufacturers got an opportunity to enter the US market because of fuel economy. They stayed because of quality. It took the big 3 US auto manufacturers 20 years to catch up (or to at least reduce the importance of quality as a differentiator in purchasing decisions). I would argue that many billions of dollars of business exist for Toyota, Honda, and Nissan (then Datsun) precisely because of their quality.
Anything I can do to make it easier for people to read blogs and “look busy” at the same time? Particularly this one? :)
Hey Scott,
Good follow-up article. I think you summed up our situation best with this statement:
“All of those details need to be gathered, and it can be harder to spread out the conversation over multiple sprints than it is to have it all up front.”
It was especially difficult to spread the requirements conversation over multiple sprints considering that we are over 2,000 miles away from our customer. WebEx and phone calls are not sufficient for teasing out the details that can sink a project.
After reading your thoughts, I’m thinking that we didn’t do a very good job of keeping our customer in the conversation. We do routinely deploy to a test environment that the customer can access, but we did very little to help them with using that environment. If you’re going to be delivering a system that can’t place gift orders after the third sprint, it would be a good idea to be very clear to the business user what they can (and should) do at that point, otherwise the only message they hear is “ordering isn’t done yet, so I’m not going to look at it.”
As you suggested, ready-to-run user acceptance tests might have been a good thing do deliver along with the contents of the iteration to help the barrel-riders through a conversation that they weren’t used to having.
Patrick
A very insightful article. However it doesn’t adress one thing – for me the most important one. How to force/encourage stakeholders to participate in discussion.
In some organizations I find it very hard to get any decision in less than a couple of weeks. A vendor would have to guess anyway to move the work ahead since getting instant feedback on design decision is impossible. In that situation having just rough requirements on the beginning isn’t a very good idea.
Another thing is understanding of the agile. There are clients out there who will change the course of the barrel (main requirements) several time and will still exepct to reach the goeal in the same time.
For me decision about going agile is always more on the client/stakeholders than the vendor. That’s great if the team wants to go agile but as far as there’s no support from the other side it won’t be the best choice.
The motivation for stakeholders to keep away from agile is quite a different subject, but you can treat is as one of sources of current situation.
Thanks Pawel, and welcome to Tyner Blain!
Forcing or encouraging stakeholders
If an organization is not ready to benefit from agile, you should not use agile. That’s pretty straightforward. But an organization is not one person. Where this gets tricky is when there are one or two stakeholders who are not prepared to collaborate in an agile process but everyone else is. You have to handle those situations one at a time. And you do that with individual conversations. Those conversations are about two-way education.
Agile is not just a “deliver in two week chunks” timing pattern. That’s incremental delivery. And it has value, but that value is limited to improving execution.
Agile is incremental delivery plus a “learn from the market, and incorporate that knowledge every two weeks” philosophy. This is what provides a compelling and differentiated value to organizations who are able to learn and interested in learning. If you have a stakeholder who already knows exactly what needs to be completed six months from now, and who has intransigent certainty that his ideas will not change or evolve, that stakeholder will not get any benefit from an agile process. I have not met a business leader who believes (1) the market will not change over the course of the project, (2) the company will not get smarter during the course of the project, and (3) the company will not find opportunities to critique and improve what is being developed over the course of the project.
Framed that way, everyone I’ve ever worked with is interested in the benefits that can come from an agile project.
Some of those people are not able to dedicate the time to realize those benefits by learning and responding to that knowledge. Having stakeholders that can not dedicate themselves to the process is no different than having developers who can not dedicate themselves to an agile cadence.
If you ask the question whether circumstances will change over time you’ll always hear a positive answer. However it you were able to hear honest answer for the question “do you care?” many answers would be negative. That’s the problem with convincing people (especially in big organizations) to move toward agile methods.
Personally I’d prefer to work with my stakeholders agile-way with a lot of feedback and changing product as we go. On the end you usually make requested changes this way or the other because it’s better choice to allow some scope creep than to have a clash with the customer pointing all tiny details in formal agreements. However it is still quite rare to find stakeholders willing to change the way they work even if they’d agree it might have been a better choice.
Another reason is that client prefer to get more predictable result even if it’s worse than it could have been. If you work with banks or mobile operators as customers you should be familiar with that approach.
For me until stakeholders are willing to work on the project using what we call agile methods it’s wrong choice to force it alone.
Thanks again, Pawel.
As to “do you care?” being negative – a better question is “should you care?”, which sometimes will also be no.
If predictability wins, then it wins. Another dynamic I’ve seen – especially in channel (distributor or retailer) sales models – is that predictability is a literal constraint. Companies sometimes have to commit to policies, SLAs, or product features (yes, “ugh!”) for a period of time that is much longer than a scrum sprint. Those commitments can be things like “will run a specific operating system” or “will have the following dimensions” or “will integrate with version X of software Y.” And there can be enough of them that the team is so constrained as to all but eliminate insight-driven changes to the product.
When you can’t benefit from the (market) learning that comes from agile, don’t do agile. Just do incremental development and benefit from the (internal) learning that comes from rapid cycles. You can still improve the bottom line that way, even if you can’t address the top-line.
“When you can’t benefit from the (market) learning that comes from agile, don’t do agile. Just do incremental development and benefit from the (internal) learning that comes from rapid cycles.”
That’s exactly where we are at. Looking for opportunities to change the game towards market-focused innovation cycles as documented here at Tyner Blain, but still needing to deal with the reality of not being there yet.