Preventing agile project becoming demo-driven

[Paul Sturrock]

Hello. Does anyone have any good pointers as to how to prevent a project using an agile methodology becoming too demo driven? We are seeing the issue that the visual aspect of user stories are being given a higher priority to other considerations by the business representatives. How do others for example deliver an iteration where all the user stories are not really that visual? And how do other prevent the focus being delivering for the iteration review rather than the final delivery.

Or are we just doing this stuff wrong?

[Ilja Preuss]

What problems are you facing with giving those stories higher priorities? Why are those problems not apparent to the business representatives? How could they be made apparent to them?

For example, do you have a chart that shows when all "must" stories will likely be done, projected against a planned delivery date?

[Paul Sturrock]

Ilja Preuss wrote:What problems are you facing with giving those stories higher priorities? Why are those problems not apparent to the business representatives?

Business representative buy in is the problem really. We have the issue that senior management has really bought in to the hope that the agile approach will result in possibly small, but always deliverable output from each iteration. We have a diffuculty then convincing them that we need to have user stories that stress the bigger picture. For example the need to follow an overall architecture or pattern, or other issues like the possible negative performance outcome of a narrowly focused user story.

There is an often heard glib comment in the office these days along the lines of not to think of the future becasue that is the agile way.

How could they be made apparent to them?

This is our issue. Do you use "elaboration" iterations to design and prototype stuff before hitting a real construction phase? Or do you successfully manage to convince business representatives that the result of one iteration will be what appears very, very basic functionality when it is actually very complex?

For example, do you have a chart that shows when all "must" stories will likely be done, projected against a planned delivery date?

No, or at least its pretty vague outside this and possibly the next iteration.

[Ilja Preuss]

Paul Sturrock wrote:
Business representative buy in is the problem really. We have the issue that senior management has really bought in to the hope that the agile approach will result in possibly small, but always deliverable output from each iteration.

Mhh, that actually sounds good to me. Are you saying that you are struggling with actually making it deliverable?

We have a diffuculty then convincing them that we need to have user stories that stress the bigger picture. For example the need to follow an overall architecture or pattern, or other issues like the possible negative performance outcome of a narrowly focused user story.

I don't think I understand this, yet. Can you give an example?

There is an often heard glib comment in the office these days along the lines of not to think of the future becasue that is the agile way.

I hope you are aware that that's clearly wrong?

This is our issue. Do you use "elaboration" iterations to design and prototype stuff before hitting a real construction phase?

How would that help you?

Or do you successfully manage to convince business representatives that the result of one iteration will be what appears very, very basic functionality when it is actually very complex?

I assume by "very complex" you mean something along the lines of "no, we really can't implement more than that in an iteration"?

For example, do you have a chart that shows when all "must" stories will likely be done, projected against a planned delivery date?

No, or at least its pretty vague outside this and possibly the next iteration.

Would it help to have it? What would you need to do to have it?

[Lisa Crispin]

Paul Sturrock wrote:Hello. Does anyone have any good pointers as to how to prevent a project using an agile methodology becoming too demo driven? We are seeing the issue that the visual aspect of user stories are being given a higher priority to other considerations by the business representatives. How do others for example deliver an iteration where all the user stories are not really that visual? And how do other prevent the focus being delivering for the iteration review rather than the final delivery.

Or are we just doing this stuff wrong?

Hi Paul,
When we work on "behind the scenes" functionality that the customers can't see, we spend a lot of time with them to understand what the code should do, but we don't have anything we can demo to them. In fact, when we don't do any "visual" stories in a sprint, and the stories delivered don't change the way the business people work, we don't bother with a sprint review.

I think a lot of this is about establishing trust. From the beginning, we were careful to limit the scope of what we committed to deliver each iteration, so that we didn't "blow a sprint" and disappoint the customers. They always feel confident about the minimum amount we will deliver. So the fact that they can't "see" delivered functionality doesn't bug them.

We often err on the side of not demonstrating UI functionality enough while it's in progress, so we make a special effort to involve the customers during the iteration when it's appropriate.
-- Lisa

[Ilja Preuss]

Lisa Crispin wrote:In fact, when we don't do any "visual" stories in a sprint, and the stories delivered don't change the way the business people work, we don't bother with a sprint review.

Can you give an example on such a story? I'm a bit puzzled - if it doesn't affect the users of the system, why would you want to implement it at all? Thanks!

[Lisa Crispin]

Ilja Preuss wrote:

Lisa Crispin wrote:In fact, when we don't do any "visual" stories in a sprint, and the stories delivered don't change the way the business people work, we don't bother with a sprint review.

Can you give an example on such a story? I'm a bit puzzled - if it doesn't affect the users of the system, why would you want to implement it at all? Thanks!

Here's an example: Our application manages retirement plans. When people contribute to their retirement account, withdraw money, or change their investments, we have to do trades through a trading partner (they actually do the buys and sells of the mutual funds). We had a story where for certain mutual funds, we had to mark trades as "new money" if they were the result of new contributions to the account. In other words, if someone merely switched from fund AAAAX to BBBBX, that wasn't new money, but if they sent in money to buy new positions in fund BBBBX, that's "new money".

This wasn't anything that our plan administrators could see - it was a new field in the trade file sent to the trading partner, based on a value in a new column in the database. So there was nothing to demonstrate to our internal users.

However, not all mutual funds had this rule, so we needed a UI that allows our administrators to mark a fund as requiring this "new vs. old" flag in the trades. That UI was something we could demo to the internal users.

Does that make sense?
-- Lisa

[Ilja Preuss]

Lisa Crispin wrote:
Here's an example: Our application manages retirement plans. When people contribute to their retirement account, withdraw money, or change their investments, we have to do trades through a trading partner (they actually do the buys and sells of the mutual funds). We had a story where for certain mutual funds, we had to mark trades as "new money" if they were the result of new contributions to the account. In other words, if someone merely switched from fund AAAAX to BBBBX, that wasn't new money, but if they sent in money to buy new positions in fund BBBBX, that's "new money".

This wasn't anything that our plan administrators could see - it was a new field in the trade file sent to the trading partner, based on a value in a new column in the database. So there was nothing to demonstrate to our internal users.

Are you saying that non of your internal users cared about fullfilling this requirement? Who came up with it? How did you know you had to do it? Just curious...

[Jelle Klap]

Couldn't acceptence tests (ideally acceptence test driven develoment) help you out here? Getting customers involved with writing acceptence tests (using Fit/FitNesse for example), having them watch these tests fail at the beginning of an iteration/sprint and presenting them with beautifull "green bar" at the end of the iteration/sprint. That way you get the customer involved, and the customer should have a pretty good grasp of what's kept the development team busy during an iteration/sprint. And you can present them with a visual payoff at the end of the iteration/sprint that's completely decoupled for the application's (G)UI, so you don't get burned by the demo-driven effect.

[Paul Sturrock]

Thanks for your comments people! Much appreciated.

Ilja Preuss wrote:

Paul Sturrock wrote:
Business representative buy in is the problem really. We have the issue that senior management has really bought in to the hope that the agile approach will result in possibly small, but always deliverable output from each iteration.

Mhh, that actually sounds good to me. Are you saying that you are struggling with actually making it deliverable?

Not quite. What we struggle with is differentiating between "deliverable" == there is a complete, styled, polished, fully funtioning GUI with all bells and whistles, and "deliverable" == basic, functioning GUI allowing users to access the new functionality. The styled, polished etc. part run the risk of use spending a disproportionate amount of time making the GUI components look good for a demo.

We have a diffuculty then convincing them that we need to have user stories that stress the bigger picture. For example the need to follow an overall architecture or pattern, or other issues like the possible negative performance outcome of a narrowly focused user story.

I don't think I understand this, yet. Can you give an example?

What I mean is how you avoid short term goals creating larger amount of rework. For example we know our application will need to be internationalizable, but that particular user story is further down the backlog (so it could drop out the release). Going through an application written for one locale and unpicking it to support mulitple locales is a big deal we want to avoid. We are accutely aware of this because one legacy app. we support took three developers solidly nine months to do just this task. How do we avoid painting ourselves into a corner on this one? Would you argue the priority of this user story? Or guess it will be something we have to do an let it flavour all user stories (and hence reduce our velocity)?

There is an often heard glib comment in the office these days along the lines of not to think of the future becasue that is the agile way.

I hope you are aware that that's clearly wrong?

Oh yes, its a sarcastic comment.

This is our issue. Do you use "elaboration" iterations to design and prototype stuff before hitting a real construction phase?

How would that help you?

I suppose it would de-risk a project that covered new technologies/ambitious functionality. How would you approach an agile project using a technology that is completely new to a team for example? Or does Agile really require the team to know this sort of stuff up front?

Or do you successfully manage to convince business representatives that the result of one iteration will be what appears very, very basic functionality when it is actually very complex?

I assume by "very complex" you mean something along the lines of "no, we really can't implement more than that in an iteration"?

Yes. And since asking this we've already decided we need to break more of our user stories down into multiple stories, se we've maybe answered this one ourselves.

[Ilja Preuss]

Paul Sturrock wrote:

Ilja Preuss wrote:

Paul Sturrock wrote:
Business representative buy in is the problem really. We have the issue that senior management has really bought in to the hope that the agile approach will result in possibly small, but always deliverable output from each iteration.

Mhh, that actually sounds good to me. Are you saying that you are struggling with actually making it deliverable?

Not quite. What we struggle with is differentiating between "deliverable" == there is a complete, styled, polished, fully funtioning GUI with all bells and whistles, and "deliverable" == basic, functioning GUI allowing users to access the new functionality. The styled, polished etc. part run the risk of use spending a disproportionate amount of time making the GUI components look good for a demo.

Sounds like a styled, polished etc. GUI seems to be quite important to your business representative(s). Do you know why that is the case?

What I mean is how you avoid short term goals creating larger amount of rework. For example we know our application will need to be internationalizable, but that particular user story is further down the backlog (so it could drop out the release). Going through an application written for one locale and unpicking it to support mulitple locales is a big deal we want to avoid. We are accutely aware of this because one legacy app. we support took three developers solidly nine months to do just this task. How do we avoid painting ourselves into a corner on this one? Would you argue the priority of this user story? Or guess it will be something we have to do an let it flavour all user stories (and hence reduce our velocity)?

What did make that change so hard in that legacy app? What could you do in your app to ease later implementation of that feature, without having to actually implement it now?

How would you approach an agile project using a technology that is completely new to a team for example?

When a technology is totally new to a team, that typically means that the team can't estimate stories involving that technology reliably. As good estimates are of business value, the business representative can schedule stories to let the team explore the technology (typically implementing a timeboxed spike solution).

[Lisa Crispin]

Ilja Preuss wrote:

Lisa Crispin wrote:
Here's an example: Our application manages retirement plans. When people contribute to their retirement account, withdraw money, or change their investments, we have to do trades through a trading partner (they actually do the buys and sells of the mutual funds). We had a story where for certain mutual funds, we had to mark trades as "new money" if they were the result of new contributions to the account. In other words, if someone merely switched from fund AAAAX to BBBBX, that wasn't new money, but if they sent in money to buy new positions in fund BBBBX, that's "new money".

This wasn't anything that our plan administrators could see - it was a new field in the trade file sent to the trading partner, based on a value in a new column in the database. So there was nothing to demonstrate to our internal users.

Are you saying that non of your internal users cared about fullfilling this requirement? Who came up with it? How did you know you had to do it? Just curious...

The internal users wrote the story based on the requirements imposed by the mutual fund companies. There were other, related stories - for example, some mutual funds send "concessions" which are compensation for us doing some of their administration. Some pay concessions only for "new" investments. That functionality is also invisible to the users, except for the resulting balances in accounts.

We had a meeting with our internal customers where they explained what was required. As I recall, this involved some examples on the whiteboard. Then, a senior programmer who understood the back-end processing really well (at the time, he understood it best; now we all understand it but this was a few years back) walked us through the current processing, and what would need to be changed to accommodate the new requirements.

We tested this with FitNesse tests as well as through the application in real-time. I don't recall now, but it's possible I went over the FitNesse tests with the internal customers to verify we were doing the right tests. Sometimes they are comfortable that we understand the requirements and don't feel a need to see the actual executable tests.

In these stories, there actually was a visible component - reports that showed how the different types of funds were processed. We actually failed to involve the customer enough with these while we were developing them - we showed them the reports but not enough different scenarios, and we ended up having to fix them later. That happens when we get complacent and we have to renew our efforts to collaborate more closely with the customers.

Does that help explain what we did?
-- Lisa

[Paul Sturrock]

Ilja Preuss wrote:
Sounds like a styled, polished etc. GUI seems to be quite important to your business representative(s). Do you know why that is the case?

We do - the app. we are working on will be a principal sales tool. It needs to look very good in demos etc. The point we are struggling to get across to the business representative is the "we want the UI to look amazing" user story might be high priority but is best served coming a little later in the backlog, or that functionality will suffer if we have to apply too much polish too early.

What did make that change so hard in that legacy app? What could you do in your app to ease later implementation of that feature, without having to actually implement it now?

The technology used was the issue. We (as a development team) want to avoid introducing the same future overhead, and we face some of the same decisions the original developers of the legacy app decided to ignore. We are using Flex for this and as yet there is no RTL support in an official release and certain existing components have poor support for localisation. We have a decision of using a beta release of Flex now and hoping not much changes, or custom building components ourselves. This is doable, but either makes the project much riskier, or slows our velocity down considerably. In a case like this would others push this as a user story in its own right and suggets it is high priority?

When a technology is totally new to a team, that typically means that the team can't estimate stories involving that technology reliably. As good estimates are of business value, the business representative can schedule stories to let the team explore the technology (typically implementing a timeboxed spike solution).

Ah right. Well it looks like our business representatives are maybe being a bit hopeful or possibvly we've not successfully argued our case.

Thanks for you input Ilja - all good stuff!