5

We are currently developing an in house solution. The trouble that we are having is that the main stake holder is cultivating the idea as he goes along, leading to endless change requests.

I am currently managing the project in an agile scrum way, and I have tried to lessen the change requests by agreeing on the deliverable for the first version. Previously this wasn't the case, and although that has helped, the problem that we are having is that the stake holder often agrees to the feature to be developed one way, only later on (when he realises that there is a better way to do it) to tell the team that he wants it y way instead. This has left my dev team extremely frustrated since it often leads to lost development time and rewriting old code to behave differently.

What is the best way to prevent this?

  • Can you provide more context via some typical change requests and what leads to them, or at least what aspects they cover and how big they are? For example, are the changes UX tweaks once the stakeholder has the feature in front of them or does user testing? Are they totally re-envisioning features, or even the goals/vision of the software itself because they weren't sure of the original concept? Is it technical, changing the way the devs actually implemented it in the architecture? Providing more info along these lines will definitely steer any advice I would give. :) – Jeff Lindsey Dec 2 '15 at 14:36
  • Both really - UX and re-envisioning how a feature works. So for example, we had an issue recently where the main stakeholder agreed to do a code generation feature one way, only 4 weeks later (2 weeks before the end of the project) decided he wanted it to be done another way, because he realised at that point the current approach was flawed for y reason. This ended up disgruntling my dev team because they had to re write how it is done. – bobo2000 Dec 2 '15 at 14:54
  • This also delayed the delivery of the first version of the project, since my plan for the remaining sprints got affected. – bobo2000 Dec 2 '15 at 15:00
  • 1
    Isn't that the point of agile methods? Inspect & adapt? – nvoigt Dec 3 '15 at 7:46
  • I guess the problem you have is not the one you're thinking about. One of the points of using a framework like Scrum is exactly about welcoming changes, at any stage of the project, otherwise you're better off with a traditional approach. If the stakeholder wants a change because he realizes there's a better way to do feature x, then the team should follow him/her, instead of being frustrated over a quite straightforward thing (Or you really prefer to follow the initial plan and ship the wrong thing?). – mamoo Dec 3 '15 at 7:53
5

From Agile Manifesto - "Responding to change" over sticking to a plan.

It is a good practice to respond to a change so that your product/project evolve in right direction. It will lead to client's satisfaction.

But there are some precautions you can take. 1. Please start writing the requirements in the form of Stories (As a user<>.. etc) and also with Acceptancy criteria/Conditions of satisfaction.(Given, When , Then) 2. Acceptance criteria is a must, it will help developers/testers to get clear idea about what satisfies the customer. Your main stakeholder who is changing requirements every time, should provide this. Or Involve him also during backlog refinement.

Once the sprint is over (stories passed definition of done), if your main stake holder is asking for a change, please provide a new estimation and start the work. Do not allow any change in requirements during sprint is in progress.

  • Yep, doing user stories and user acceptance tests. The trouble is not that at all, at the end of a sprint we deliver an increment based on it. The trouble is that after that sprint is over, he sees the working feature and then decides that he wants it differently leading to frustration for the team. In an ideal world, if we had unlimited time and budget I can just keep creating iterations of the product, in reality I need to deliver things by x date. – bobo2000 Dec 3 '15 at 10:59
3

This is a common frustration especially on newer agile teams. There are two sides of it:

1) Backlog management. The idea of the backlog is that it is changeable, but because everything is listed in a single-column priority, the impact of any changes is immediately clear. If your stakeholders are coming back with changes over and over, you can accommodate them, but it pushes other work further down the backlog, either pushing out the delivery or pushing features out of the release. It sounds like you're acting as product owner - remember that as product owner it's also your responsibility to say no to stakeholders when making more changes is not the right thing to do.

2) Be comfortable with rework. Sometimes the only way for a stakeholder to understand what they want is to put something in front of them and see if they like it. In agile we acknowledge that it isn't possible to have the perfect design and plan up front. Otherwise we'd do waterfall. It should be made clear to the team that their initial work was not wasted. It was very valuable in helping stakeholders understand their needs better.

1

The best way that I've found to deal with this is to make your customer/stakeholder/Product Owner understand the cost of change. Agile, and Scrum in particular, are designed to be flexible and respond to user needs. In a lot of cases, especially when you have a PO without a clear vision of their product, this can lead to a lot of iteration and change.

Iteration in and of itself is not a bad thing, and in some cases should be encouraged. What is important is to make it clear to your stakeholder that it will cost in time/money/hours, especially when we are making major changes to the system early on. Here are a few key actions you could try:

  • Explain the concept of velocity and show your PO how his changes are affecting your velocity towards completing all of the items in your backlog. "We got 30 points done last Sprint, 12 of them were changes to previously-existing functionality. If it's what you need, great--but we should consider to think about things like this."
  • Groom thoroughly and with the goal of getting a "version one" out. As you groom through items in your backlog, remember to ask your Product Owner to prioritize them. "Is this really needed in v1, or is this more of a phase 2 item?"
  • Remember YAGNI--You aren't gonna need it. Getting a version 1 out will really help your PO prioritize and help clarify the vision of the product, especially once you start getting user feedback. Suggest to your PO that you complete whatever remains that is the absolute minimum marketable feature set, then put out a release and see what users say.

Hope this helps!

1

Agile-scrum is a fairly rigid set or practices and patterns that work well together. I hear red flags when you say you are "managing the project in an Agile-Scrum way."

You should avoid cherry picking Scrum practices, especially on newly forming scrum teams or with organizations that have little Agile experience. Scrum works best as a complete system.

Sounds kind of tangential, but the root cause of your problems (if my assumptions are correct) could stem from the issue that you do not have formal product owner, scrum master, and team R&R defined on your Scrum team.

Scrum teams serve many stakeholders, but they are represented by 1 product owner. This product owner sets the priority of WHEN/WHAT to do and is responsible for answering the WHY question. The PO may also makes some decisions on WHAT UI implementations look like because the PO is often closest to the user. (UX and Agile is a whole different topic with its nuances, however).

The PO works with stakeholders to negotiate priorities and manage expectations. Stakeholders don't provide designs or implementation details and the PO and Scrum master work to coach technically capable stakeholders out of these behaviors.

The team determines the HOW and WHO does it of everything else. Stakeholder or PO doesn't like HOW a feature was implemented in the code; too bad. The team owns the quality and implementation of the features, and is accountable for delivering to standards they explicitly share with PO and any interested stakeholders.

That's how Agile teams stay empowered and bought into the work they do.

The scrum master is the servant leader on the team. They don't ever define the HOW, WHAT, WHY, WHEN, or WHO of the actual work items, but they coach the team on improving their delivery processes, product quality, and eventually help the team understand how all the scrum practices work together. The SM also facilities ceremonies like the stand-up, planning, review and retrospective. SM's have no authority to tell anyone on the team to do anything, but generally have worked in a developer, QA, or PO/PM capacity previously. They are sounding blocks and facilitators for the team to continuously improve.

  • The initial post seems to indicate the "stakeholder" is basically filling a PO role, and the follow-up comments also seem to back this. So even if the OP were to move things into the rigid Scrum role paradigm, the team would still be plagued with constant (and seemingly wasteful) iteration and pivoting, which frustrates them. I've seen many teams become extremely agile and exhibit high ownership, but following a PO who has no idea how to drive towards true value, and the result is always disastrous for all involved. – Jeff Lindsey Dec 2 '15 at 20:41
  • That is exactly what is happening, the stakeholder is the product owner. I have assumed the role of product manager. It is a start up so we do not have the resources to have a formal scrum master, product owner, stakeholder etc The main problem right now, is that the team is plagued with constant iteration because the stakeholder/product owner cant make up his mind on how he wants the features to behave until AFTER he sees it implemented. As a PM, this is annoying because I need to deliver a completed first version of the product by x date since we have a limited budget etc. – bobo2000 Dec 3 '15 at 10:55
  • You shouldn't have both a product owner and a product manager on a scrum team, that's just asking for trouble. Also the premise of delivering a completed first version by x date sounds very waterfallish to me. The advice given by other posters on coaching on the cost of change is valid, however you have an R&R problem to deal with as well. – WBW Dec 3 '15 at 18:02
  • @bobo2000 Similar to my other comment, I still feel that your problem is two-fold: one, as most have mentioned here, is that in agile, you measure and re-plan as you go and adjust expectations accordingly. If a date must be hit, provide visibility on what is likely to be done by then (original plan + average iteration time per item/sprint/etc). The other problem is that your PO seems to be iterating based on subjectively using the software and then changing their mind. What are they using to validate the need to iterate at all, or mitigate that need earlier? – Jeff Lindsey Dec 3 '15 at 19:05
  • Customer feedback from an older version of the software. Before I joined they had an existing start up product on the market, so based on the user experience using that product, my PO makes change requests once new information about the efficiency of features from the old process is discovered. Since it was only released to the market (the old product), my PO is still in the discovery phase. – bobo2000 Dec 4 '15 at 10:07
1

One of the main reasons scrum exists is because it was observed that change is inevitable, and it should be embraced rather than feared. The first thing you need to do is to accept that a stakeholder with changing priorities is a common thing. It isn't something that needs to be fixed per se. Rather, change needs to be embraced, recognized, and prioritized appropriately.

I suggest using a physical scrum board for a while to drive the point home. There should be a place for enough backlog items for the current sprint, as well as the top items that will likely make it into the next sprint. It also helps to have room for all of the other backlog items so that the stakeholder can see the growing pile of stories.

Whenever a change comes in, write it on a card and then get the stakeholder to agree to either:

  1. abort the current sprint if the new item is if higher priority, or
  2. remove some item from the top of the backlog to make room for the new item.

Those really are the only two options.

I think having a physical board with actual cards makes the disruption more tangible since they have to physically change something about the current plan.

0

Agree with JDRoger in that showing the cost can help, but you should also consider how to mitigate the need to iterate in code, or at least the cost of it. From your example, it sounds like the main pain point is validation after something has been built (either subjectively via the stakeholder or objectively via results).

Here's some "low-hanging fruit" I would suggest investigating to start that mitigation:

  • Ensuring the vision and validation strategy is solid: what are the pillars of the user experience (i.e. "users should feel X"), what features or UX will directly support them, and how will you actually prove that they have been achieved? This can also include comparisons to competitors. This goes a long way towards reducing subjectivity as well.
  • Identifying personas: who are the actual users, what are their needs or goals, and which features matter to them? How will they fit into the validation strategy?
  • Boosting alignment and clarity: look into story mapping, also good for ferreting out iteration-likely areas or complexity/risks if you involved the dev team.
  • Paper prototyping, motion mock-ups, hacked prototypes + user testing: what can be created and validated faster and cheaper than waiting for production-ready software?
  • Tracking iteration vs. thrash: simply tracking the %s and sources of emerging work can open up healthy discussions around how to reduce them, live with them, or optimize them.
  • We did most of that, one of the challenges for start up projects is that the PO is constantly cultivating the idea based on his experiences. Unlike traditional dev projects, there is no specific way to develop it. For example if I am delivering an e commerce site I can just look at the standard way of building features and use it as a guide. – bobo2000 Dec 3 '15 at 11:27
  • I've worked with a few startups, and directly on projects that were very subjective, interaction-heavy and hyper-exploratory, and I would still posit that a good PO uses a framework that includes the things above (and much more) to validate the value and "fail faster and cheaper" in certain areas that don't require delivered software. – Jeff Lindsey Dec 3 '15 at 19:00
0

Job Security. Rejoice, you are in a contract that will never end and you'll be able to bill till the end of time. Your children and your children's children will be able to process the same change requests over and over.

The trick is to make sure that the customer knows this. Every change request should be documented in terms of the effect on the milestone delivery date and the ultimate delivery date.

We're happy to make that change - the rework will delay this milestone by 2 weeks and the project completion by somewhere between 3 and four weeks. Total cost impact is an additional 80 hours of work for 2.5 developers, so let's call that 300 hours @ a burdened rate of $80/hour. On the back end that's looking like 1500 hours. As always, a pleasure doing business with you. Of course if you decide that the status quo is good enough and you don't need this change, we can return to the original schedule.

Clarification based on OP's question - we're paid to accomplish the scope. If the customer changes the scope through an official change management process, then I believe we're held accountable for the new scope. Part of our job is to ensure that the change management process takes into account the impact of the change on cost, schedule, quality, security, requirements, suitability for business, etc.

  • Fair enough, but if you are a project manager (like I am) isn't your performance judged by your delivery rate (on time and in budget?) – bobo2000 Dec 14 '15 at 17:05
  • My performance is judged by on time and under budget as determined by the scope So long as the customer keeps making (informed) material changes to scope, my daughter can stay in college as long as she wants. – Mark C. Wallace Dec 14 '15 at 17:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.