Don’t Resist Change, Embrace It: Agile Principles Revisited

1K
• by Bruce Nix
• 26th Feb, 2018
• Last updated on 27th Aug, 2019

“….a puzzling limitation of our mind is the confidence in what we believe we know, and our apparent ability to acknowledge the full extent of our ignorance and the uncertainty of the world we live in.  We are prone to overestimate how much we understand about the world and to underestimate the role of chance in events.”  Kahneman, D. (2013). Thinking, Fast and Slow. New York: Farrar, Straus and Giroux

In the first installment of our “Agile Principles Revisited” series, we discussed delivering value early and often to our customers.  To ensure we meet the value definition, it is often we find ourselves having to adjust mid-stream once a customer has the opportunity to see the concept come to life. It is within that moment that determines if you are becoming an agile organization or you simply want to stop change and adhere dogmatically to a plan that was crafted months and months ago.

Principle #2: Welcome changing requirements, even late in development.  Agile processes harness change for the customer's competitive advantage.
Change is not avoidable nor is it final.  Without change we would not have the tools and products we have today, although I am pretty sure the world would have been better off without Harley Davidson Perfume, HP Touchpad, New Coke and Clairol Touch of Yogurt Shampoo.

On the surface it certainly seems agile right?  Be nimble, adapt and pivot and use other buzzwords you heard on Huffington post. Well, like any effort worth doing, it takes discipline to apply the practices to this principle so that it does not get diluted to the point that it causes damage to the team and has negative impacts on the outcomes we are seeking. This also does not mean you get to change your mind every day. Let’s take a deeper dive to better understand this principle.

Welcome changing requirements: Dwight Eisenhower said “Planning is everything, the plan is nothing.” I am not saying don’t plan, you should have a roadmap that you are marching towards. What I am saying is that change is inevitable and your plans and process needs to leave space for this to happen with minimal impact to outcomes.  Attempting to “get all requirements right up front” thinking that it will reduce change is preposterous, and results in padding happening at every planning gate (analysis, design, development, testing, etc.) until you end up with a bloated and unrealistic plan that has everything to do with protecting someone from being blamed and nothing to do with focusing on what the customer needs.  If anything, by taking a big upfront planning approach, you are guaranteeing change will happen due to the uncertainty that is inherent in software and customer demands change once they actually see something. However, this also means you need to use collaboration, compromise and a whole lot of common sense to assess the change and determine the impact to cost and risk of your deliverables.  Practices that help support this principle are keeping stories small and independent and releasing frequently into an environment that would allow a level of usability testing to take place. Doing so will reduce risk to overall code health and communicating to your customers that you can meet their needs quickly.  Another practice is a daily collaboration event with teams to identify risks sooner and allow action to take place to correct as soon as an issue is raised.

Even Late In Development: Given that most agile teams operate in 2-3 week sprints, late in this context should not cause anyone great alarm.  In the old days of 12-18 month project deliveries, this would cause a spike in alcohol sales and severe liver damage for the teams that were affected.  If you are following the practices of allowing a buffer for unknowns and spikes to research and prove out a theory then changing a story late should not be a major undertaking. Obviously, the tighter the coupling, number of handoffs and number of dependencies will determine the risk and it should always be a discussion with the overall team and product owner on whether they can undertake the change now or later.

Holding costs play a role here as well.  The longer you wait to release, the more risk you have when a change does happen later in the sprints.  The more you hold on to, the more that has to be tested and the more that has to be released, the more potential for something to go wrong and the more cost you sink into the project.  Attempting to freeze change creates a risk averse environment which inhibits innovation.

Harness Change for Customers Competitive Advantage:  Taking an economic view, we have to be able to respond according to one of the market needs by meeting the customer wherever they are in their journey and making it easy to purchase and use the products we create.  As the demands of the customer change, we must change and utilizing practices of frequent delivery and feedback moments to harness that change to our benefit by shifting priorities and functionality that serve an outcome rather than ones that are serving a “plan”.

So where do we start ?

Decrease the time from Identify to Satisfy: When a customer identifies a problem to the time we can satisfy that request is the critical path in the digital world—the shorter the lead time the better the outcome (at least we hope so and should have analytics to determine that).  We can do this by leveraging or building services and processes that help us deliver quicker and frequently to satisfy a customer’s needs and meeting them where they are in their customer journey.  Your customers don’t’ care about your solution or your bureaucracy, they care about their problems and how quickly they can be solved.

Build Small, Deploy Fast, Learn Quickly:  If it takes us an extended and inordinate amount of time to deploy a change a customer asked for, that generates frustration and creates a secondary need for that customer to seek fulfillment elsewhere.  A practice that can help this is when teams slice their stories as responsibly small as possible.  The larger you make a story/feature the longer it takes to get out the door due to dependencies and coupling issues.  Most scaling practices also have a 10-12 week cycle for larger integrated releases, which still allows predictability but also allows responsible planning in a short time boundary which aids when having to say no to things that could disrupt the current cadence. Even for this to work well, your portfolio budgeting process must take a leaner approach as well, but that is for another day.

Starting your feedback cycles as soon as you have something to show will also reduce the risk of change due to delivering something your customers never wanted.  You should be setting goals, hard goals, of being able to deploy on a frequent basis. This does not mean you have to deploy to customers daily, just that you are building the habit of feeling confident that if you needed to, you could as frequently as you needed to base on market or customer demands.

Enemies of the (to be) State:

Over Processing:  Bureaucracy in any environment is a form of waste if it adds an extensive amount of wait time to the request – fulfillment pipeline.  Over processing can also translate to how much “non- value added” administrative overhead is the team having to endure to meet the customers’ needs or react to the change.  Measuring this wait time and delays in your throughput will help identify areas that the environment needs to optimize in order for the teams to decrease lead time and react quicker to change. “Gold Plating” also plays a factor here. Attempting to put more into a system than the user is asking for or needs wastes time and effort and adds incremental delay costs due to having to write and execute tests for these less used features and integrating into rest of the product.

Lack of Quality First Approach: Reacting quickly to change requires discipline in your testing approach and if the majority of your testing is being done manually, then that is slowing down the opportunity to meet a commitment to a customer.  Quality first means;

• Ensuring adequate and understood acceptance criteria is applied to features
• Including estimates for writing unit tests built off acceptance criteria
• Including estimates for writing automation for each delivered story
• Including buffer for defects to occur and be corrected within your timebox (this should be included in the sizing of your story)
• Doing enough to meet the immediate need and take time to build on more later (if customer needs dictate)
• Everyone is responsible for quality.  Quality is not a “phase” or a single person/title, it is a collective and shared activity that any person on the team can undertake to meet  the predictability commitments.

Change will happen and no matter how much planning you do, you cannot avoid it, you can only prepare for, and adapt to it.  Make sure your practices allow for change in the most productive and responsible manner possible that allow a problem to be solved for your customer and keep the teams safe.

Bruce Nix

Blog Author

Bruce Nix, one of the highly experienced Agile coaches at Lokion, applies two decades of experience in information technology and innovation management to his projects. He trains and leads cross-functional teams in innovation practices, ensuring the best possible outcomes for teams. An avid researcher of leadership and innovation principles, he continually strives to make processes leaner and more efficient.
As a Scaled Agile Framework (SAFe) 4.0 Program Consultant, Certified Scrum Professional, and Scrum Master, Bruce provides improvements in processes and project delivery for clients. He has years of daily experience in Agile project management methodologies and helped found the Memphis Agile Practitioners Group.His deep experience in technical operations management and business analysis has allowed him to manage multiple projects involving enterprise scale ecommerce  initiatives, user experience, web and mobile design, and process improvement.