Lets get back to lightweight methods, let me propose a 7 step process with the working name Objective Driven Agile – although I also want to call it Really Simple Agile or maybe Xanpan 2022 – and I’d rather forget the A-word altogether and get back to lightweight.
1) Start where you are, with the people on the team, with the code you have, with any existing documents, there is no pre-work, you start here with what you have. Any pre-work you think you should do, any blocks or impediments you are facing, any reason not to start now becomes a work item to be done.
2) Default to a 3 month “super-cycle” and 2 week iteration cycle (OK, we’ll call them sprints), you may change this later but put the dates in your calendar now and set them to reoccur.
3) Set a maximum of 4 objective(s) for this period.
I will assume you are using OKRs for this and limit them to a maximum of 4 key results for each objective. Key results are not small pieces of objective but bounding criteria which describe the objective, acceptance criteria.
If you team must “keep the lights on”, operate as a DevOps team, support a live system or other “business as usual” then this is objective zero and must be acknowledged as work to be done.
Objectives are outcomes, they make the world a better place. Objectives should support business purpose and strategy. The team should be able to explain how the objectives meet these criteria, better still it should be obvious.
One of the objectives should be nominated by the team themselves with the aim of making future work better, easier and more productive even if the outside world can’t see a difference.
4) Run sprints (iterations) inside your super-cycle: the first sprint starts as soon as the objectives are confirmed.
If any preparation work (e.g. interviewing customers) is needed this is part of the work to do. In the sprint planning meeting review your objectives, then decide which will be the focus of the sprint and ask “What do we need to do to advance our mission?” and write stories for this work.
For each story ask: “can this be completed within one week?” If it cannot then find a way to rewrite it as several stories each of which can be completed within one week.
When you have written the stories ask: “is this enough work for the sprint?” If the team thing they have capacity to do more work, or might do all of this work, then write some more stories – about the same objective or another. If the team feel this is too much work for this sprint prioritise the work then hold some back for the next sprint.
5) During the sprint aim to release each story as it is done, continuous delivery style. Review progress against OKRs regularly (but not every day). If the team can’t do release individual stories at the start then it is something to work towards, something for that team nominated objective.
Work items which arise under OKR #0 should be recorded as “yellow stories”, the team may refuse such work but once accepted it has priority over all other objectives unless otherwise decided.
6) At the end of the sprint release any finished work, demo to stakeholders, review, retrospect and replan. Count the stories – including yellow work – completed each sprint and maintain a graph during the super-cycle. The graph should show planned and yellow work.
7) At the end of the super cycle close out the sprint, review progress against OKRs, hold a retrospective for the whole period. Destroy any stories which still remain undone.
Return to step 3.
Two assumptions: you are setting objectives using OKRs, you are running Scrum like sprints. Both assumptions can be relaxed (i.e. you don’t need to use OKRs and could run Kanban style) but I would need more space to explain how that might work and I’ve deliberately kept this short.
I expect regular readers won’t be surprised by this, my recent work has been going in this direction – I’ve already explained the logic in here in Honey, I Shrunk the Backlog, Backlogs, #NoBacklog(s) and comfort blankets and last year’s Xanpan 2021 (Xanpan 2021 slides or Xanpan 2021 on YouTube).
Let me know if you would like me to expand on these ideas.
Subscribe to updates from Allan and download Continuous Digital for free
This article actually misses the mark considerably. Said another way, it carries forward the same systemic problem that Agile itself suffers from. It doesn’t touch strategy, provides woefully inadequate guidance for executives, and suggests that goals set by teams can somehow deliver enterprise level business outcomes.
The condition of most companies is that they are lacking a well formed strategy to adequately inform downstream decisions. Evidence for that is that organizations tend to work on far more projects than they have the capacity to support, priorities are constantly shifting, work has little meaning, and people have conflicting and misaligned priorities.
If follow step 1, start where you are, the problems associated with strategic misalignment will persist and all of the other steps won’t even matter. “Start where you are” is a Kanban principle. Kanban is a system to manage the flow of work – not the strategy of an organization or its ability to actually organize around outcomes. Step 1 should be get your strategy in order and shut down work that isn’t aligned to strategy! Give the organization some breathing room to start to truly organize around outcomes.
Actually Larry, I agree with most of what you say.
Although some may cliam differently I don’t think agile does touch sytretegy, nor do I think it should. Agile might be a stragegy but to me strategy is something you do on top of agile, and some strategies will work better with agile than others. Strategy is just such a big area if agile tried to answer the strategy question we’d be here all day.
Similarly, my article doesn’t aim to address strategy. I certaionly hope an organization has a strategy, and I certainly hope it is shared across the org, then, if your OKRs don’t line up you can have a conversation about why not, what has been missed and what needs to change.
Finally, I’m happy to admit I stole “start where you are” from Kanban – remember, I wrote my own XP/Kanban hybrid so I agree with a lot of Kannban. In fact, I think “start where you are ” is the only way you can start. If you decide you need X, Y and Z to be done first then they are simply the first things you need to do to get started, or perhaps: get to the point you wish to “start” from.
Very nice, the core of Agile!
Hey Allan,
Thank you for the post! I find the suggested approach very interesting and reasonable.
The approach itself seems very similar to what Scrum suggests to do with a several differences/
OKR #0 that is supported by “yellow stories” is very similar to a Product Goal from Scrum v2020. The difference that I see here is that Product Goal could be revalidated on Sprint Review to adapt faster in case of market changes, while OKRs seems less agile.
Also, I found that the current explanation of the sprint finalisation in the article creates a feeling for me, that the event is focused on the calculation instead of inspection and adaptation. Is it so important in your opinion to count the stories – including yellow work – completed each sprint and maintain a graph during the super-cycle?
Well spotted Nikolay! – I don’t think the process I suggest is that difference, you might say it is “Scrum writ large” – thats part of the reason I’m confident in it.
I might also say that it is about returning to our roots: getting useful products into customer hands, its just looking at bigger goals (big objectives not small stories!). That said, I would hate this to be seen as a license to return to 3-month sprints and quarterly software releases.
The graph: yes, I think it is important to track how many work units are doing each cycle, and if a team has BAU/Yellow work then to understand how capacity is used. This data can be used long term both for team improvement and forcasting.