Changing requirements. Moving milestones. Unanswered questions. These things can make people uncomfortable and frustrated. As a result, I often see people trying to limit change or uncertainty as much as possible.
With this in mind, does it surprise you that the second principle of the Agile Manifesto is, “Welcome changing requirements, even late in development”?
Does this principle somehow hinder others like sustainable development and becoming more effective? Building projects around motivated individuals?
In an industry where some aim to follow the Agile manifesto to a T (whether they achieve this or not) and others question its current relevance, a lot of companies are still somehow working in a way influenced by the Agile Manifesto. That is to say, they’re not following the traditional Waterfall approach of locking in all requirements before any development or testing actually starts (let’s leave “mini Waterfall” to the side for now, though it’s very relevant). That means, whether you love it or hate it, change is gonna happen. I’ve even seen job adverts requiring candidates to be able to handle uncertainty and frequent changes. Is that a sign of a bad company, or an honest one?
So what should we do? Should we put pressure on Product Owners to make a call and stick with it? Enforce strict adherence to a definition of ready? I won’t lie, these things make for an easier life in many ways, but do they make for the best solution; frequent delivery of value; the best outcome? What about our beloved feedback loops – should we take the feedback and do nothing with it because, “sorry, too late, log a change request”?
Responding to Change
Let’s assume there’s a good reason for changing requirements, milestones and directions: feedback. In this scenario, change is good. Change says, “yes, we hear you, and this is what we’re going to do about it”. Change is flexible; change opens up possibilities. Change is what we do when we keep an open mind and explore.
I’m a huge proponent of fast feedback, exploratory testing, and doing what makes sense. As a tester, I do my best work when I’m involved from the very beginning – pre-coding, pre-conception; right over there where we’re still trying to define the problems our target market has. I test everywhere, so you get the benefit of my knowledge and experience asap. My feedback informs what we do next, just like how the results of our little exploratory testing experiments inform what we investigate next. It changes our course.
But things happen. Testers get involved later; clients give feedback later; we realise or find something later. Say we were selling made-to-order muffins instead of software. The client ordered twelve blueberry muffins, so you start making them. Part way through, the client calls saying they got it wrong and it’s actually chocolate chip muffins they need. None of your other clients have ordered blueberry muffins, so you can’t give them to anyone else. Would you finish making the blueberry muffins anyway, then pick out the blueberries later and replace them with chocolate chips? No, you would probably change your course of action and just add chocolate chips instead of blueberries. That just makes sense. Why be any less flexible when making software?
What if you’ve already added the blueberries by the time the client calls? That sucks, there’s no denying it. But spending the time and effort on finishing an unwanted product anyway doesn’t help anyone either. I understand the pain, I really do. But change is inevitable. Why give yourself unnecessary work and risk increased delivery time and unsatisfied customers if you could just change your course of action?
Earlier, we assumed good reasons for change. If there’s a well-grounded, reasonable basis for change, let’s be glad we found it now rather than even later. “We’re reasonable people,” you say, “we know this,” you say. But sometimes there is no good reason. Things just seem to change because… There’s always a “because”. It may not seem clear to you, but there’s always a reason. Not communicating with the customer early enough; the Product Owner being stretched too thinly between too many teams; testers not being involved early enough. Instead of putting up walls, restrictions and resistance to change, I propose that we investigate the root cause of the issue and use our abilities to change that.
By addressing root causes and embracing change, we embrace information, whenever it comes, keep ourselves current, and show that we’re able to respond appropriately in an industry where things move quickly.
Responding to Uncertainty
Okay, but what about uncertainty? How can we complete a piece of work with so many open questions? Get creative. Think about the problem, user scenarios, solutions, delivering value. How can we make progress and deliver something now, even if we don’t have all the answers? We can be smart with the way we split work; consider whether iterations or increments are more suitable. Work simultaneously in a kind of just in time approach, implementing what we can while the remaining points are clarified. Determining the minimum viable / valuable product; assessing what information we really need to deliver value and what’s extra.
In testing, we deal with uncertainty all the time. We’re constantly asking questions (coming up with things we’re uncertain about) and finding out the answers. There’s no reason we can’t take a similar approach in other uncertain scenarios.
To be clear, I’m not knocking things like a definition of ready. I think they’re great. I just don’t think we should use them to the detriment of our own progress. Instead, we can use them as a tool to determine how tickets should be split, such that we have something that’s already good to start working on now, rather than wasting time waiting for information we don’t necessarily need yet.
To return to our analogy of making muffins, maybe the client also wants to have some decorative icing on them, but they’re not sure which flavours they want yet. If you know that the order needs to go out today, would you hold off from making the muffins altogether until the client confirms the icing flavours? No, you would probably save time by making and preparing the muffins as much as possible already, knowing that the final details will come later. This way, the order isn’t delayed unnecessarily. We can do the same thing when producing software.
Embracing Change and Uncertainty
Uncertainty is an opportunity to communicate and ask questions; change is a sign that we’re finding answers and learning. We can use that to move forward.
By embracing change and uncertainty, focusing on delivering value, and breaking down our work into more manageable, actionable pieces, we work more sustainably and effectively. By understanding the value we can bring and having clear steps to delivering it, we become more excited and motivated about our work. So our Agile principles from earlier don’t need to be at odds, and neither do we, as teammates.
Embrace change and uncertainty, and embrace progress.
How do you deal with change and uncertainty in software production? Share your tips in the comments.
I would say that Because of these uncertanities, shift left is gaining traction, even though the team will always will be in dilemma regarding the requirement as client can change the requirement anytime, but still some bugs will be early caught which can somehow decrease the work load at the very last moment. If bugs are early caught it will save cost & time as well as team can easily handle the change in the requirement. Still even if the team is not following shift left approach, atleast they should follow qa process like creating qa documentation, keeping transparency with stakeholders regarding testing process and priortizing quality as the highest priority.