Agile Scoping — How to Keep the Focus
Agile scoping is the scaffolding I use to keep the client focused on the desired outcomes they are looking for.
Join the DZone community and get the full member experience.Join For Free
Some of the people I admire in the agile community avoid working with organizations that are not fully committed to the agile changes they are asking for.
This can create drama and a possible loss of connection between the ‘thought leaders’ and the rest of us. But what if some agile approaches would help us understand how best to support our clients if we do not have the full support of the organization?
That is my aspiration over the next few blog posts.
Agile scoping is the scaffolding I use to keep the client focused on the desired outcomes they are looking for. It has three stages all helping the client focus more on the outcomes they want to achieve, and less on the processes they are using to get there as doing agile is not an outcome.
In this article, I will give a high-level view of the diagram and all three stages of scoping this will be followed up by detailed articles on each level over the coming weeks.
Initial (Clean) Scoping
Initial scoping is heavily influenced by Caitlin Walkers Clean Scoping. However, as is the agile way I have adapted it to align with your context of how you work at your best and so it can be leveraged to transform the world of work. However, if you can do the full clean scoping as defined in the link then I would recommend you do that instead.
It is often used in the first session you have with the main sponsor of the initiative the client is asking you for help with. For some people, it could be a job interview. However, we would use initial scoping if the desired outcomes change or I am asked to explore a new area of an organization or the sponsor changes.
During an initial scoping session I am looking at three elements.
1. Can I Work With the Client?
For me, this would be as below however you need to set your own rules on what’s important for you to work at your best:
- Are they open to reflection, feedback, and changing of their ideas at the moment?
- Are they looking for an off the shelf solution? Or a collaborative incremental journey towards their desired outcomes?
- Are the desired outcomes congruent with the agile and my mindset? e.g. Are they involved in gambling for example as that is something I would not want them to get better at, Is the outcome to go ‘twice the speed in half the time’? a common agile misunderstanding.
2. Does the Client Know What Outcomes They Are Looking For?
The most common thing I get asked during initial scoping is "Can you help us do agile"? My job during the initial scoping phase is to be curious about the request and dig a little deeper. I shall explore how I do this in a future article so do subscribe if you’d like to know-how. However, what I will say is you need to work out how during the initial scoping so you can find out what the need for change is.
3. Does the Client Have the Influence Required to Meet Their Desired Outcomes?
An example of things people might need to influence will depend on the desired outcome, but a couple of examples are organizational structure and control of the budget. As in most cases, these need to change quite a few times, and having to wait for these to get approved can cause massive delays and a loss of momentum towards the desired outcomes.
If the answer to any of these questions is no, then in my experience, it will be damaging to move on from the initial scoping phase, as the chances of success are low and with failure, we do get some learnings but we also get scars. I have found these scars to make the next change effort even harder.
You will need to decide if the answer to the above questions is likely to change in the near future? For example, I might decide to run a workshop to help them define clearer outcomes, or I might see if I can get access to someone with the influence required.
If I do decide to work with the client, how long will I invest in exploring? What will the return of investment be to the client? Is it ethical to keep taking money?
Organizational scoping is similar in many ways to initial scoping however instead of working with 1 or 2 key stakeholders over a short period normally for free, this phase will be with a large number of the people who are involved in meeting the desired outcomes described in initial scoping.
This could be a small group if the outcomes are targeted. For example, launching a new product that meets customers needs within 3 months, or a large group, for example, increase the employee experience score by 30%, which might need a large part of the company.
Organizational scoping usually has 4 parts. However, it is important to note that the organization does not stop working whilst you continue the process. There is often a pay off between understanding enough to create a coaching plan, and the organization making decisions which might be tricky to resolve later on. Such as setting up component teams instead of feature teams.
Initial Training — This is to create a common language for the change.
- Leadership training
- Agile Training
Launch Day — This is to create alignment and communicate the change to all members.
During the launch day, it is often useful to cover the below items in a mixture of large and small groups with at least 3 levels of leadership involved in all meetings.
- Desired outcomes from the wider group
- Feedback on the current outcomes under discussion
- A view of what culture people would like to have in the future
- Current strengths and challenges
- Any volunteers who would like to be a part of the pilot
- Knowledge gaps
Initial Support — This I have found helps you get off to the best possible start.
This will cover two areas:
- Agile coaching support this might include things like launching or relaunching pilot teams, coaching of leadership
- Further Information gathering to inform the more formal coaching plan based on the concerns outlined during the launch day
Coaching Plan — This reviews the success of the organizational scoping and decides on any long term support you might need based on outcomes
This is the final stage of organizational scoping as a group you will review if the organizational scoping has met the desired outcomes for scoping. Confirm the original desired outcomes are still valid and agree on the next steps in your agile journey.
If at any stage during the organizational scoping it is clear the desired outcomes are not going to be met, then in my experience, it is crucial to revisit initial scoping and rebaseline.
Some reasons for this misalignment could be a lack of congruence between what a client says and does, the outcomes are no longer important or perhaps the desired outcomes don’t have enough support outside of the small group you initially scoped.
If the coaching plan is agreed and things seem to be going on track then we can move on to ongoing scoping.
Ongoing scoping has less structure but I have found the below list of items useful at this stage.
- A list of desired outcomes e.g. OKRs
- A list of shorter-term outcomes (What will we see or hear in 1 week, 1 month) e.g. PLN
- A list of probes and any associated tasks
- If you are external a transition plan (What will happen when you leave)
- Case Study
I have found that it is important to keep aligning your shorter-term plans to the desired outcomes for small adjustments, we can do this as and when needed however we might want to revisit initial scoping if the outcomes.
- Change dramatically or are no longer a priority
- Can be met without you being needed
- Have been met
During the initial scoping we will either start work on some new outcomes, or you will move on to another area of the organization, or perhaps even another organization altogether.
With Special Thanks
Rickard Jones for helping define this way of working with me at Agile Affinity, and contributing to the article. If you would like to talk in more detail on the topic email us or comment below!
Helen Meek for always proofreading my blogs and for listening to all my crazy ideas.
Caitlin Walker for supporting my systemic modeling journey and inspiring me in so many ways including clean scoping the bases for this article.
Olaf Lewtiz for being an awesome friend, making me aware of clean language and creating the PLN model I refer to in this article.
Published at DZone with permission of John Barratt. See the original article here.
Opinions expressed by DZone contributors are their own.
How to Handle Secrets in Kubernetes
Integration Testing Tutorial: A Comprehensive Guide With Examples And Best Practices
MLOps: Definition, Importance, and Implementation
Building and Deploying Microservices With Spring Boot and Docker