Jan

28

Iterative Development Challenges Business Stakeholders

Posted by Keith McMillan

January 28, 2008 | 2 Comments

Software engineering teams everywhere are moving towards, or have already adopted, an iterative style of development, because it creates a number of desirable effects: better time to market, earlier feedback, easier to manage, to name a few.

But what does this mean to the groups they work with? In this, the second of 4 posts, I look at the challenges to business stakeholders (the customers) caused by an iterative style of development, and how you can address them. The previous post, Challenges in Iterative Development, gave an overview of this style of development, and some reasons why you’d want to adopt it. The next posts will review challenges to the data team, and the quality assurance team.

Unfortunate Lessons

Many development shops have done a very good job training their business stakeholders (who I’m going to refer to as customers). Unfortunately, we’ve trained them to expect a number of undesirable things, mainly that we’re going to go off and build a system for them based on what they’re saying today, and that we won’t be back for quite some time (months, if they’re lucky). This has led them to try to perfect their requirements before they give them to us, because they won’t see us again for a while.

In an iterative style of development, we’re going to build software in much shorter increments, typically weeks, and in many styles of iterative development, we’re going to be continuously asking for information from the customers, either feedback on what we’ve implemented, or the requirements for the next iteration, or both.

It strains credulity, and many customers don’t believe it. They’ve been told in the past that we’re going to build things quickly, but we’ve trained them that they only get one chance to get the requirements nailed down, and they’ve got to get it right on the first pass. This leads them to fall back into the waterfall style: get all the requirements written down, and then perfect them before saying they’re “complete” (or “frozen”, “signed off”, whatever catchword the business has chosen) because they won’t get a second chance.

Clearly, this creates unnecessary friction between the development team and the customers. The development team wants the best shot at the currently in-scope set of requirements. We understand, and in fact expect, that the requirements are going to change, either as we learn more, or because some external factor caused the requirements to change.

Conversely, the customers want to make sure they get as close to a perfect set of requirements, because they don’t think they’re going to get another chance.

The consequences of this impasse are catastrophic to a development effort. If we can’t find a way to get requirements flowing into the iterative development process, then we’re really stuck back in a waterfall mentality, where we have to have all the requirements completed before we can work with any of them, and we forgo many of the advantages we’re trying to achieve by iterating.

Iterative development also changes the frequency and length of interactions between the customer and the development team. Rightly or wrongly, waterfall style development doesn’t place the same kinds of demands on the customers’ time as iterative development does. Iterative development calls on them to provide input to use cases or stories, which are different and more detailed than the requirements they’re used to providing. It also calls on them to provide regular feedback to the development team, either continuously, or at the end of iterations. Some customers take the view that they didn’t sign up for this in addition to their day jobs, and are reluctant to provide this kind of input, which again is crucial to getting things right.

Facing the Challenges

These challenges are some of the most difficult that can confront a team moving to iterative development. Without the participation of the customers, your project will fail. When it fails, you will reinforce the customer’s perception that they were right, and quite possibly doom your move to iterative development at the same time. But much of what you need in order to be successful is in the hands of those same customers, the ones who don’t believe you when you tell them how it’s going to be different this time.

The only solution to this problem is to prove you mean what you say. You have to prove it to a customer who is reluctant to give you the things you need (requirements that are “complete” for at least the time being) because they don’t think they’ll get to change them later, and they don’t want to be wrong.

One way in which you can convince your customer that you mean what you say is to start small, involving the customers in your trials of iterative development. This gives them a chance to see that the process really does work like you said it does.

Another way to address this conundrum is to try to identify a less jaded member of your customer base, and engage with them on your project. This relies on finding such an individual, and having the support of their management to provide their time. Without customer buy-in, your move to iterative development will not succeed.

As with the other external communities impacted by your move to iterative development, the key to success lies in involving your customers in the process of transformation. The degree of your success will depend on your ability to find a way to bring your customers into the fold, to get them to suspend their disbelief long enough for you to prove to them that you really do mean what you say. That can be a difficult thing to do, but it’s essential to the success of your efforts.

Are you using iterative development?

  • Iterative what now? (57%, 4 Votes)
  • All our projects are iterative (29%, 2 Votes)
  • Rolling out to most projects (14%, 1 Votes)
  • Limited trials (0%, 0 Votes)
  • Considering it (0%, 0 Votes)
  • Iterative and waterfall are both used (0%, 0 Votes)

Total Voters: 7

Loading ... Loading ...

Comments

RSS feed | Trackback URI

2 Comments »

Pingback by Iterative Development Challenges the Data Team : Adept Technologies
2008-01-30 12:02:31

[…] overview of this style of development, and some reasons why you’d want to adopt it. The second, Iterative Development Challenges Business Stakeholders, reviewed the challenges faced by the customers of an organization moving to an iterative style. […]

Reply to this comment
 
Pingback by Iterative Development Challenges the Quality Team | Adept Technologies
2008-02-04 12:58:47

[…] overview of this style of development, and some reasons why you’d want to adopt it. The second, Iterative Development Challenges Business Stakeholders, reviewed the challenges faced by the customers of an organization moving to an iterative style. […]

Reply to this comment
 
Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll