In this post, we will be talking about Principle #2 of the Agile Manifesto, which discusses the concept of change. Change is a sensitive topic within teams because once a plan is in place, a team should should stick to the plan, right?! In order to react appropriately to the needs of the business and continue to bring business value, the team needs to be ready to react to change and deliver results in a short amount of time. They need to welcome change.
A quick note, I will be discussing the concept of change from a Scrum approach where change can be accommodated in the next Sprint. There are other methodologies, such as Extreme Programming “Small Releases” for example, where change can be accommodated within a few days. I also briefly discuss change management and the importance of including it in your backlog planning.
The Principle is as follows:
- Principle #2 – Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
“Welcome changing requirements, even late in development.”
Talk about a slippery slope! As a business stakeholder with no experience in Agile, or care for the impacts of change, I see this statement as a welcome mat to get what I want, when I want – because, change is welcome, right?! Indeed, the glossy shine of this statement looks great but it’s not what it seems most times. As the Scrum Master of an agile team, we regularly welcome change, when it’s added to the backlog and prioritized. We will kick and scream if you try to change the scope of a well-groomed story that’s currently active in a Sprint. So, what is this really saying?
As the team is delivering tasks, after each iteration, if a change is needed, we can definitely take it on in the next Sprint. If you (as a business stakeholder) learned something new about the market and we need to accommodate, it gets added to the backlog, groomed, re-prioritized and pulled into the next available Sprint. It doesn’t matter if it changes what the team just completed. We, as a cohesive Scrum team, are here to plan the next Sprint, not complain that “we just did that!” As a Product Owner, you have the right (and assuming the budget power/influence) to request the team do the next task, even if that next task is a change from the thing they just did. However, if this kind of change becomes a regular habit, I would hope the Scrum Master would reach out and help coach or guide the planning process to get ahead of the curve on changes.
“Agile processes harness change for the customer’s competitive advantage.”
AB-SO-LUTELY! We live in an agile society where attention spans are under ten seconds and change needs to happen NOW. There’s always a new competitor or startup that’s taking market share and businesses need the ability to react sooner than later, and it’s up to the team to make that change happen as quickly as possible.
As a non-classically trained Project Manager, I’ve always had a challenge with this. On one hand, I see the need to implement the change and want my business to succeed, but my role tells me that I need to follow guidelines for change management, which can be a pain in the rear. I’m supposed to say, “what’s in scope is what’s in scope and if you want to change it, a change request is required to update the scope, budget and timeline.”
While this can be tedious and cumbersome, it’s a part of the role, so a CR is created and submitted. That said, if I have to execute 250 change requests over the course of a 6-month project because my Project Sponsor wants to be agile, I have a much bigger problem. As your team adopts Agile, change is something you need to dig deep on to identify how your organization will handle changes. This is also where we have to step back and look at some practical ways to setup an agile project for success.
Practical Analysis
The Agile Manifesto is a strategic document. It’s up to each team, department, or business to build the tactics around an Agile strategy. Here are a few things you should consider:
- The project needs to be setup and financed as a resource-based cost plan, not a plan based on deliverables. When you have a business case driving a project that contains time constraints, a cost (budget) and scope, it’s very easy for a team to fall into an objective focused (waterfall) mindset. In this mindset, change is stressful because it’s not part of the plan. Further, there will be a constant need to keep reminding the team that they need to be agile-minded and open to change, even if it means they are pivoting from original objectives. If your funding model is resource-based, your project leadership steers what needs to be delivered so the team can focus on delivering!
- The project needs a leader assigned that not only has the knowledge to steer the ship but can be accountable for change. A good Product Owner has their finger on the pulse of the business and the market and can help guide change. Ideally, this same person is someone that has budgetary influence or oversight and can justify the cost of a change.
- Don’t forget change management! Yes, even in agile there needs to be a focus on the changes your change makes. For example, documentation such as process or product documentation all need to be accounted for when making changes. The Product Owner should be making sure this included in the backlog planning.
- This doesn’t play nicely with service-based organizations that are delivering a fixed set of features or functionality. Service companies that are developing a fixed set of features can definitely be agile, but cannot fully adopt this principle. If you are in an organization like this, and you have a customer that wants to implement changes, you will find yourself in CR City, population 2: you and a frustrated customer that gets tired of hearing, “that’ll be a CR”.
There has been a major focus on getting teams trained as Certified Scrum Masters (CSM); however, businesses need to focus on training (or at least coaching) people on how to act as Product Owners. The Product Owner and Scrum Team need to come together as one team, but understand they have completely different responsibilities. Therefore, if you find yourself in a situation where you are being trained to “be agile” by going to a CSM class, you need to make sure there is equal attention being paid to training business leaders as Product Owners.
“All In” Rating: 4.75/5.0
My only hangup with this principle is that change can be tough on an organization and you can’t just “be agile” and make changes whenever you want. It may be easy for you and your department to change, but when you’re dealing with an application that people use every day, change is not as welcome and your approach needs to be more strategic. Further, if you are delivering a product or providing a service to build something, change takes on a different theme.
In a recent poll on LinkedIn, I asked the question, “How does your organization handle change?” The options were 1) We stick to the plan, 2) We adjust as needed, and 3) We don’t care, let’s do it! As expected the majority of votes were “We adjust as needed”. In second place was “We stick to the plan”. After a little digging, this vote came from someone in the eCommerce service industry where a team MUST stick to the plan. There is no change without a CR. They can’t “adjust as needed” without change management. This is where the “(Maybe)” part comes from.
For internal teams that manage an application, change management needs to always be a consideration. Think of customer service representatives that use a call center application or end users of a cloud-based application – you can’t change the structure of a menu or the layout of a page in the application without major communication around change management. This is where the concept of releases comes into play. This is another post for another time, but just remember, outside of your team, the changes you make might not be as welcome as you may thing and might end up being detrimental to others.
Do you like what you’re reading? Find it valuable? Think it’s rubbish? Don’t forget to leave a comment (on the blog on wherever you found the link to this post)!