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.

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.

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.

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.

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.

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

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? :)

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.”

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.

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…

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!

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.”

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.