Planning So We Can Respond To Change
The fourth value of the Agile Manifesto is Responding to change over following a plan.
Let's start with Eisenhower's words - "Plans are worthless, but planning is everything".
It makes no sense to start work on any initiative without planning at all. But it also makes perfect sense to constantly inspect our plans and if they are not realistic anymore or are irrelevant or out of date, we should change them.
Another aspect that is really important here is the depth and width of our plans. If we have a detailed plan for task by task work for every person on our initiative for the next several months, I would submit that we are assuming NOTHING will change for the duration.
I'm not sure about you guys, but I've never been on an initiative where nothing changed for that long!
Between clarifications to requirements, technical and/or technology emerging details, core business stakeholders changing their minds about priorities, regulatory and compliance changes (either at the industry or organization level!), market/competitive changes, etc. - the chances of this context/landscape staying still are practically negligible!
By the way - the same applies to other aspects of planning beyond the traditional project plan. Solution architecture(s) should be treated this way - "our architecture is good for the features and capabilities we considered in rather detail up to this point; when a new feature/capability/user story will come to our attention that cannot be satisfied with the current architecture, we will trigger the work to decide how the architecture evolves, where do we pivot and how we create the next increment or our solution architecture!". The coding and testing practices and procedures might have to evolve. If we determine our failure demand is too high, we might decide to introduce additional coding standards, code reviews, test coverage, additional testing practices, etc.
At this point the corollary I bring forward is that we have to change the way we look at our commitment. If we're assuming changes coming our way, we have to give up committing to a scope and timeline, and we have to draw our plans with this in mind.
Why don't we aim to create initial targets for delivery - shaped as an MVP or a set of MMFs - as we try to find best ways to combine delivering business value (earning revenue as early as possible) and achieving the complimentary goal of validated learning. Again - ingrained in this model is the expectation for changes resulting from feedback we receive on what's been built as often as possible.
Shifting to the next level down from the agile values, the principle that best supports this is "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
In practical terms, one story that would illustrate this is about one of the great agile delivery teams I've worked with recently. These folks were dealing with:
- tight timelines (the scope and timelines were set before we were allowed to proceed with the initiative!);
- a perceived fix scope (in reality and in detail the scope was changing dramatically and at a pretty rapid pace, but nobody was interested to keep track of this once the project started!);
- an outdated technology stack and gaps in their instrumentation and in their infrastructure, etc., etc.
It was long after the start of the initiative, and after they had made some large assumptions with the "sign-off" from the Product Owner and the business stakeholders. These assumptions were made to decouple delivery from critical decisions on changes to the core business processes supported.
One of these turned out to be invalid. When the delivery team was notified, they jumped into action. They stopped most of the work in progress at the time (they basically "stopped the line" in a traditional Kanban style) and setup several long running and intense (re-)design sessions to address the changes in requirements and pivot the solution according to the new direction. The result was a high level design followed by 3-4 major epics prioritized at the top of the backlog, and a shifting of most of the other backlog items down in priority to make room for the brand new top items. And by the way, they clicked their solution architecture up quite a large increment in the process.
The end result was that even if initially the team was apparently "delayed", eventually they caught up with the pace of the larger initiative, and because of other (inevitable!) delays, they ended up delivering the new capabilities on top of the "initial scope" and with top quality. Notice here I've used some of the terms in quotes, since I've described the perspective of some of the stakeholders that were not fully on-board or clear on the methods and approach and were still interested in checking on the delivery of all the scope items by a certain deadline, as per their outdated mindset.
To conclude this story - the team had a detailed enough plan to execute on their requirements. And when the requirements changed they were in an excellent position to respond to change because of the disciplined way in which they were managing their backlog and the close collaboration they had setup with the Product Owner and several of the main business stakeholders.
My day to day approach to align into this value is to constantly inspect the level of planning used by the team, and fine tune it. Focus on the aspects of the plan that prove the most useful, and minimize the amount of effort behind the others if you cannot completely do away with them.
In the context of the organization, it is sometimes impractical to completely shutdown all existing procedures and policies. And as a change agent I'm always checking myself for the initial purpose and objective - "am I trying to prove a point, or am I simply trying to move the group (team, org, tribe, etc.) forward on their journey?"
And as usual, I'm wrapping it up by turning it over to you - what did I miss? What resonates with you? And what makes no sense (yet)?
Let's start with Eisenhower's words - "Plans are worthless, but planning is everything".
It makes no sense to start work on any initiative without planning at all. But it also makes perfect sense to constantly inspect our plans and if they are not realistic anymore or are irrelevant or out of date, we should change them.
Another aspect that is really important here is the depth and width of our plans. If we have a detailed plan for task by task work for every person on our initiative for the next several months, I would submit that we are assuming NOTHING will change for the duration.
I'm not sure about you guys, but I've never been on an initiative where nothing changed for that long!
Between clarifications to requirements, technical and/or technology emerging details, core business stakeholders changing their minds about priorities, regulatory and compliance changes (either at the industry or organization level!), market/competitive changes, etc. - the chances of this context/landscape staying still are practically negligible!
By the way - the same applies to other aspects of planning beyond the traditional project plan. Solution architecture(s) should be treated this way - "our architecture is good for the features and capabilities we considered in rather detail up to this point; when a new feature/capability/user story will come to our attention that cannot be satisfied with the current architecture, we will trigger the work to decide how the architecture evolves, where do we pivot and how we create the next increment or our solution architecture!". The coding and testing practices and procedures might have to evolve. If we determine our failure demand is too high, we might decide to introduce additional coding standards, code reviews, test coverage, additional testing practices, etc.
At this point the corollary I bring forward is that we have to change the way we look at our commitment. If we're assuming changes coming our way, we have to give up committing to a scope and timeline, and we have to draw our plans with this in mind.
Why don't we aim to create initial targets for delivery - shaped as an MVP or a set of MMFs - as we try to find best ways to combine delivering business value (earning revenue as early as possible) and achieving the complimentary goal of validated learning. Again - ingrained in this model is the expectation for changes resulting from feedback we receive on what's been built as often as possible.
Shifting to the next level down from the agile values, the principle that best supports this is "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
In practical terms, one story that would illustrate this is about one of the great agile delivery teams I've worked with recently. These folks were dealing with:
- tight timelines (the scope and timelines were set before we were allowed to proceed with the initiative!);
- a perceived fix scope (in reality and in detail the scope was changing dramatically and at a pretty rapid pace, but nobody was interested to keep track of this once the project started!);
- an outdated technology stack and gaps in their instrumentation and in their infrastructure, etc., etc.
It was long after the start of the initiative, and after they had made some large assumptions with the "sign-off" from the Product Owner and the business stakeholders. These assumptions were made to decouple delivery from critical decisions on changes to the core business processes supported.
One of these turned out to be invalid. When the delivery team was notified, they jumped into action. They stopped most of the work in progress at the time (they basically "stopped the line" in a traditional Kanban style) and setup several long running and intense (re-)design sessions to address the changes in requirements and pivot the solution according to the new direction. The result was a high level design followed by 3-4 major epics prioritized at the top of the backlog, and a shifting of most of the other backlog items down in priority to make room for the brand new top items. And by the way, they clicked their solution architecture up quite a large increment in the process.
The end result was that even if initially the team was apparently "delayed", eventually they caught up with the pace of the larger initiative, and because of other (inevitable!) delays, they ended up delivering the new capabilities on top of the "initial scope" and with top quality. Notice here I've used some of the terms in quotes, since I've described the perspective of some of the stakeholders that were not fully on-board or clear on the methods and approach and were still interested in checking on the delivery of all the scope items by a certain deadline, as per their outdated mindset.
To conclude this story - the team had a detailed enough plan to execute on their requirements. And when the requirements changed they were in an excellent position to respond to change because of the disciplined way in which they were managing their backlog and the close collaboration they had setup with the Product Owner and several of the main business stakeholders.
My day to day approach to align into this value is to constantly inspect the level of planning used by the team, and fine tune it. Focus on the aspects of the plan that prove the most useful, and minimize the amount of effort behind the others if you cannot completely do away with them.
In the context of the organization, it is sometimes impractical to completely shutdown all existing procedures and policies. And as a change agent I'm always checking myself for the initial purpose and objective - "am I trying to prove a point, or am I simply trying to move the group (team, org, tribe, etc.) forward on their journey?"
And as usual, I'm wrapping it up by turning it over to you - what did I miss? What resonates with you? And what makes no sense (yet)?
Comments
Post a Comment