Agile: Is Rework Bad?

I recently had an enlightening conversation with someone who was just learning about Agile.  She was deeply entrenched in a Waterfall methodology and legacy PMO practices.  She had lots of questions about how Agile works in a Stage-gate approval process and client contract negotiations.  But what captured my attention most was her frustration over rework.  She said, “we recently had a situation where a client came to us with a half-baked idea.  Before we had finalized the requirements, IT went ahead and worked on something.  That led to seven rounds of rework before we finally satisfied the customer.  How would Agile have handled that?”  It is a good question, but the answer is about far more than just a process change.

Image Source:

Image Source:

Re-thinking Rework

The paradigm shift that Agile suggests is that rework isn’t bad.  That is a challenging concept to get your head around.  Let’s look at the woman’s example again and shift the language slightly.  “Our IT department responded to a client and showed them an option based on the available requirements.  Upon seeing the working software, the client was able to refine their request and provide more clarity to IT.  After seven iterations, the client was thrilled.”  Mind-blowing, right?  If we simply pivot our expectations, we might find that we can be more Agile in our approach to solving customer problems.

Is rework ever bad?

Are there instances where our enthusiasm to get started might be impractical?  Absolutely.  One of the core tenets of Agile is the importance of understanding the Business Value of the requested work.  If your client, internal or external, cannot adequately express the business value that they are trying to achieve, then we might need to pause and ask probing questions.  Only when they can articulate what business problem (or opportunity) they are trying to solve for, should we get involved in finding creative solutions.

Wireframes and Prototypes

What if you want the goodness of iterating and learning but without actually coding, therefore avoiding rework?  This is where your User Experience people can add tremendous value.  Creating wireframes and prototypes allow you to collect critical feedback without utilizing your expensive development talent.  Wireframes are visual blueprints of the workflow and screens that you can walk a potential end user through.  They can present navigation and process flows on paper with enough detail to allow the end user to provide valuable feedback.    A prototype is an early representation of the product, typically something tangible that you can hold and play with, though it is not fully functional.  Both wireframes and prototypes allow you to gather user feedback to influence your requirements.

Rework is not a four letter word – literally or figuratively.  As long as you are learning and gathering feedback, then you are continuously improving and that, by my way of thinking, is always a good thing.


To learn more, please reference the book Change, Inc.: An Agile Fable of Transformation available on

4 Responses to Agile: Is Rework Bad?

  1. Dave Decker says:

    Great article! Totally agree about re-thinking rework. What are your thoughts about re-work around a user story? To give you an example, let’s say the user story is about developing a red flashing icon on a website. The team has groomed the story, given it a sizing, say 2 points, and there’s a list of acceptance criteria with the story. As the team is developing it, in conversation with the PO, it’s partially demo’d. The PO (that would be me) decides, you know, it really should be flashing blue, not red. And wants to change it. How do you handle that change?

    How we handled this was to go ahead and accept the change within the story since it didn’t really adversely affect the sizing/effort. But if the change was to affect the sizing, we could both change the story sizing (and remove something from the backlog) or create a new user story to address the change (and have it prioritized in another sprint) and accept the current story as it is. I would choose the former option. Either way, the modification is going to happen. Easier to do it now when it’s fresh in the team’s minds, than to pick up the work a week or two later. Anyway, would love to hear your thoughts! Thanks!

  2. John Peltier says:

    Good post, Kristin.

    When the roadmap is a sales tool, and client expectations are set for a number of upcoming capabilities, rework can be a non-starter. The organization that sets future expectations with time frames is deliberately NOT agile, even if its developers are. This frequently leads to “good enough” products, which may or may not actually be “good enough.”

    I suggest involving an engineer in creating prototypes. It’s easy for a PM and an interaction designer to draw up a workflow that cannot possibly work in the actual product. User testing can absolutely prevent rework, though!

  3. tim says:

    That is right. Long term planning is the opposite of being responsive to a market. It is the opposite of being agile. Doing it better won’t make a company better at agility.

Leave a Reply

Your email address will not be published. Required fields are marked *