From 3 Bins, Zero to Hero Guide to Agile at Scale: A Free Playbook to Unleash Agility Beyond IT.
Rich Harris
Tech Strategy | Digital Acceleration | Value Based Delivery & Flow Management | Business Transformation | Enterprise Agility | Business Growth, Performance & Innovation Leader
Deep Dives, Golden Nuggets, Honest, Unbiased Thinking, Opinion, Entertaining Long Reads and Mini Guides of Practical, Pragmatic and Shared Know How from me as an Agile Practitioner to help you Accelerate your Journey towards Enterprise Agility.
Agile Scaling | How to Scale | When to Scale | Big Picture Goal and Vision | Mission for Agility | Strategic Roadmap | KRAs | Playbook for Testing, Learning and Mastery | Unlearning Outlearning | Pivoting and Persevering | Enterprise Agility Coaching
We all want to go from zero to hero in rapid time, from crawling to running.
But scaling straight away isn’t always the best starting point for those new new to Agile Ways of Working or immature organisations.
"Implementing Lean Agile Ways of Working at Scale properly is a huge paradigm shift, even from Kanban and Scrum"
So big is that difference, is that it should be led by an Enterprise Agility Coach.
Done properly, it should affect every angle and every part of your business, your architecture, your operating and business models, your governance and processes to how people think, act, lead others and work with others and that takes a lot of behaviour change, people leadership and process transformation know how, not the skills of a Scrum Master.
Jumping head first into scaling may make you feel like you’re on trend by leaping into Full SAFe or the Enterprise Business Agility Model but are you really ready?
Many Orgs aim to increase individual or team productivity, activity, outputs, velocity, or resource utilization.
This usually leads to?lower?overall value delivery, longer cycle times for customer features, and less adaptiveness.
This is why methods don’t provide Business Agility – as they only focus on local/siloed optimizations instead of optimising the Org to?maximise customer value, development, delivery, Org agility or Responsiveness - the ease and speed to which an Enterprise can?change?direction based on learning and its people.
In this article, I will share some practical know how on how to go about Scaling Agile sustainably by making a series of moves and experiments that will build the capability and understanding to go from Zero to Hero in an integrated and episodic and not spasmatic way.
"Scaled Lean and Agile have hidden “pre-requisites” than many don’t see, understand, or fully appreciate"
That doesn’t mean you can’t get onboard and start your Business Agility Journey and Transform your Enterprise by anchoring yourself to one as your NorthStar for awesomeness, as like Prince2, SAFe has 4 configurations and with the right strategy, guidance and support, your can go from Essential to Full SAFe in no time.
As Enterprise Agility Coaches, part of our job is to help organizations develop their Agile Transformation Strategies through what I call a Shu’ability approach – e.g., bitesized, manageable, constrained, outcome driven etc etc allowing for mastery, then moving on to continually improve and link up to the bigger picture of Enterprise Agility, EA Frameworks and Models liek the EBA, Domains of Agility or Business Agility Model.
This takes on what most recognise as 3 waves.
This is based on the over used Shu Ha Rai learning ladder of mastery e.g., it takes 5 -10 000hrs to become competent to practice.
Here is a post I shared a while back that build a bit more detail on this:
It’s a rough yardstick approach to measuring progress.
"A better way is to use the AgilityHealth Business Agility Radar"
Exec, Managers, all like a linear, step ladder approach, this is how they judge progress, in upward ticks.
The reality to prepare them for is its more like a Snakes and Ladders or Monopoly Board than Chessboard, responding, reacting tactically, against a visionary outcome, not a plan.
"That’s the mental model to get in your head for success, that’s everything isn’t going to go as smoothly as you might like, according to a pre-determined plan, positive conflict an eustress is good, it means you're looking at and starting to solve real problems not quick wins"
So, by having a Vision and Purpose/mission of why you need to scale and having that Visualised in a Roadmap showing the OKRs is key PR, Internal and External Communication tool to socialise and democratise the change journey.
Decisions, Decisions, Decisions…Where to Start
"Start with the now, Where you're at now, there is no best or good time"
How to start.
Sadly, 4 is usually the most frequent answer, bottom up, piecemeal, in silos without a strategy.
4 is still a better option than not deciding on a method, framework, or model at all – that’s just hope and it’s a huge anti pattern to your successes.
Avoid failure modes, by understanding the difference between Agile Methods and Scaled Agile
1,2, 5 and 6 is the much, much better place to start.
This is what my plays are about, letting you master skills by experiencing them in action, for real, learning, inspecting, and adapting, persevering to get better or by pivoting to make the play for Agile at Scale when you’re a ready and get the differences, gotcha’s capabilities and capacity needed.
A lot of Agile Transformation is being based on tailored solutions. That’s fine, to contextualise as long as you’re not creating a monster.
Too many customised or bespoke monsters are a real problem and setting you up for failure not success. They are the hype of consultancy sales teams, the hype of the UnAgilists and based on opinion leading to lots of fast paced activity with no discipline, and that’s definitely not what it’s about.
"There is a huge difference in being Agnostic to UnAgile and Rudderless"
To run an experiment, to test and learn, People, Teams, the Organisations, your PMO, your Leaders, Change Agents reference points for what good looks like, without one, your rudderless and not doing or being agile.
Also your Agile Coaching Community need a stance to lead and help improve you around, so if you don’t do Kanban, Scrum, S@S, Nexus, LeSS, SAFe and others, then its an impossible task fraught with risk, danger and tragedy and only the opinion of one of a few vs the books, resources, certification, success stories and case studies and proven patterns – I know what Senior Leadership will go for as I had to explain why things have fallen apart before, I when I do the post mortem, and compare and contrast, it becomes obvious they had the wool pulled over their eyes.
Why Do we Scale?
"Because we mistakenly copy the Spotify Model or Scrum Scaled blindly led by Cowboy Consultants"
Sadly, as well as th above, the cookie cutter factory model approach is the usual answer based on command and controls understanding of Lean Manufacturing, rinse and repeat, one size fits all.
How wrong could they be and this has led to dehumanising the workplace and many unhappy campers who understand Agile, yet the leaders in charge don't and don't have the attitudes, values, principles, mindset and beliefs to succeed at it.
Different parts of the Enterprise’s cogs need to run at different speeds, but be in sync with the external markets, partners, suppliers, and vendors that make up your end-to-end supply and value chain and value, discovery, creation, development and delivery ecosystem.
Different cogs or Flight Levels have different uses cases, needs, and demands like regulatory compliance and standards.
"Making everyone do Scrum and Sprint is not a success pattern of Agility, just a path to piss people off with seemingly irrelevant rituals and rules"
Managing the spinning plates, at different speeds, is were Scaling comes to its own and can support the multi speed, Agile Enterprise.
The real reasons we scale are:
The traditional Delta/Pyramid Management and Organisational Structure is ineffective for achieving business agility, so the Oil tanker is replaced with aligned speedboats, flat structures and middle management trimmed of the fat.
"So, before you Scale – Are you prepared to change your Organisational Design? If no, then don’t do it, simples"
To Scale or not to Scale - The Questions to Ask
Everyone’s doing it, but does it mean I should.
What do I need to consider when scaling? Here’s a few things to start with:
·??????"Do we have programme and initiatives that we want to use an Agile Operating Model for?"
Open an Improvement Backlog First
Before you scale – start a Transformation Backlog to visually track, shape, guide and course correct your experiments.
It will help define the challenges, problems, and pain points as Key Result Areas, allow you to map them to Test and Learn Experiments based off your vision for what you think good will look like.
Then visualise it on Strategic Roadmap or Infographic to socialise and democratise – no Gantt charts, set deadlines, here, just outcomes via Goals and Results.
"PS – the Roadmaps in JIRA and Aha are rubbish, they are Gantts in disguise, poor mans Roadmaps based on Release Planning Stop and Go Bar Charts"
To Scale – many start with an MVP from Lean Thinking or the Lean Start Up concept – its one of the reasons people start with Scrum or Kanban or some form of it as their MVP, PoC, Pilot, Root to Live…
Others use Lighthouse Initiatives – a political form for a project to get around resistance and land
Both result in siloed pockets of people practicing Agile and that’s not enough for Business or Enterprise Agility, but whoa, slow down, Rome wasn’t built in a day…and you do have to start somewhere, so be realistic and pragmatic right!
Either way – be prepared to throw everything completely or partially away and have the budget to do this.
Unlike the above two approaches, Test and Learn Experiments are disposable - allowing you to pivoting away to something else, or persevere with through Agile Coaching support to get it right, which won’t be first time – like I said – they all look easy on paper, until you do it for real.
So, it is like growing a culture on a petri dish, it takes time to incubate, before growth can accelerate, horribly wrong or in the right direction – that’s why you need an Enterprise Agile Coaches oversight and experience to make the judgement call and decision to, stop and pivot, or remedy and persevere.
Create an Agile Guild or Executive Agile Transformation Working Group
Thought I’d forgotten didn’t ya!
All Agile Transformations start in the Boardroom with the very people in the Boardroom being Role Models, your Change Coalition, your Exec Agile Transformation Working Group or Agile Guild.
?"I call these your First Agile Citizens, Pioneers of Better Ways of Working"
You can induct them to make it a bit fun if you like by hosting a dinner, execs like that stuff and it gets access and buy in.
The point is, if you don’t have your First Citizens, then you can’t roll out your Agile Nation and you Agile Nation can’t invade other Nations and make them Agile. Colonial, primitive, maybe, but you need to be a Pirate in your own Navy!
If you look at SAFe’s Implementation Roadmap, the second and third chevrons are Train Change Agents, Train Executive, Managers and Leaders.
If you inspect Scrum at Scale, we have the EAT – Executive Action Group
In both circumstances, they are the Agile Governance and Operating System for Organisational Change.
The have the power, the authority, the reasonability to take and make action.
With the Enterprise Agile Coach, they curate the Improvement Backlog of Test and Learn Experiments to achieve the goal of greater Business Agility.
If you think old school, this the standard MSP/MoP/Prcine2 Steer Co – the difference is its stripped back, super light weight docs and governance by Guardrails not rule, books, polices that don’t work etc.
If you think old school Change management, this is Kotter second step – build the guiding coalition – now you know where SAFe took it from.
"These patterns are proven to work based on theory, experience and practical use and consultancies and agencies will shroud them in mystery for a reason"
Again, Be Prepared to Play the Snakes and Ladders Board
Atlassian describes scaling as:
"As the ability to drive agile at the team level, while applying the same sustainable principles, practices, and outcomes at other layers of the organization"
OK, not quite right, a little black and white because Scrum doesn’t work that well in the Portfolio which is half the speed or pace of change of that of a Product Team and then massive bespoke monster modifications and month-long sprints and hybrid creations just cause chaos.
The other hick up/gotcha to be aware of is the Capability Maturity Model, (CMM), like my Yardstick Measure earlier which is a tool for the right time and right place.
Most unfortunately incorrectly perceive or think they can buy or linearly progress from being a novice towards mastery in neat, sequential steps – climb the ladder – but mastery doesn’t quite work that way, a bit like we read and learn about something, then 4 weeks later have the brain fart, oh my god, I get it! Well, that humans for ya.
Linear Thinking inside boxes is just how most project managers, managers and even developers think binary.
For us – we need to think way outside the box in multiple dimensions to enable Agility at Scale and that’s the skill of an Enterprise Agility Coach or Strategist, we can entre the theatre of war with a plan, the change it immediately by fast feedback, pivoting as an when needed, responding, not follow a pre-set plan.
So, there is a Bigger Picture to this Quest or Journey and you have to do 3 important things:
It’s no easy feat to change the DNA of an organisation and its much more complicated than many would assume, in thinking it’s just some mechanistic updates.
Start with the end in Mind
So, the end game for start-ups, sale ups, small - medium, large business and global multinational enterprises are Business/Enterprise Agility.
Many start with pure, essential or One Team Scrum as we call it, it is very popular, but alone, it won’t drive the results you’re really looking for, although it will uplift that team massively from down and out traditional project management.
With the end in mind, you can now create by reverse engineering, an Agile Transformation Vision, Strategy, and Roadmap based on the mission of working towards Business/Enterprise Agility.
So, the real place to start is here – with an Enterprise Agility Model.
Not this – the Scrum Process method:
And the flip of the DA Model:
The Scrum Process leads to the one size fits all cookie cutter factory model – Scrum is an incomplete method for Agile Management, Operations, Development and Delivery -even scaled.
The DA model follows the typical start small and build up model, starting from the bottom, going to the top, problem is that its starts and stays in the IT silo and barely ever reaches the DAIT, and when it does, because its IT led, stays there as goal achieved, but there is still another layer to the DA onion – the DAE.
"Both DA and Scrum are incomplete process led implementations of Lean Agile lifecycle methods"
The EBA model above, is more like a Strategy, a Blueprint, a Zachman Enterprise Architecture that enables Agile Management, Operations, Development and Delivery.
Its top down, bottom up, from both side and across the board – in a holistic way.
What it’s not, is an Agile Delivery Method or Framework, those sit inside this Bigger Picture.
This is a much better place to start because it’s a bit like getting Lean, Agile or DevOps right.
Before you begin practicing Lean, you should fully inspect, understand, and apply the House of Lean.
Before you begin practicing Agile, you should fully inspect, understand, and apply the Agile Manifesto
Before you begin practicing Scrum, you should fully inspect, understand, and apply Scrum Theory.
Before you begin practicing DevOps, you should fully inspect, understand the 3 Ways, and have mastered Lean, Agile, SRE, ITSM, UXD etc.
Before you practice SAFe, you should fully inspect, understand its core values, principles and 7
"All of this stuff is not just mechanistic process – it all deep rooted in behaviour change – and that’s where most stuff up -because Project Managers only see the process steps from A, B, Z and cut out all the clever behavioural stuff that matters"
So, if your serious about Agile Transformation - this is how you attack the foundations, how you alter the Organisational DNA, through people, process, and technology not by sticky plaster called Scrum over the top.
Some First Principles to Guide you
To avoid a literal Hack job, keep you anchored and make decision making trade-offs in a pragmatic, data driven well informed way, here are some principles to shape and guide your efforts, call them the Guilds or EATs Charter, JTBD or Promises:
Dipping a Toe in, Let’s get Testing and Learning
Avoid the massive 12 - week discovery expenses, sunk costs, time and outputs.
How?
"By Testing Ideas in 4 week Transformation Sprints, 6 week Dojos and Labs you'll make them stick long term - starting with the end in mind"
Testing, Tweaking, Adapting is the Agile Way, start like you mean it! No Sprint Zero – planning, just iterative, incremental, and continuous learning, inspection, adaption, and improvement.
This will get much much better buy in, trust, rapport, openness, accountability, transparency with all your stakeholders and plus, its much more fun way to communicate and do via Labs and act like a crazy Scientist, getting over that feeling of constant grind of change, but that’s the new normal.
Its will also give every one a head up on a key lesson in mastering Agility - to Fail Fast to Fail Forward.
With your Guild, EAT, selected stakeholders and partners – yes get outside people involved and helping!
Run an A3 workshop aka Canvas session.
Shape the Agile ideas to Test, how long hey will run for, what you want to get out of them
Create your Hypothesise or Hypothesises
Create the experiment team or teams
Fund them, train them, tool up
Run the Lab or Experiment
Hold Regular Meetups to review Learning, Progress, Pain Pints, Glad, Mad, Sads etc
Decide to preserve or pivot or scale
Want to get juiced up, read Sprint by Jack Knapp, Testing Business Ideas from Strategyzer or Lean Start Up from Eric Ries.
So here is the Play Book from 3 Bins, Zero to Hero/Agility at Scale:
Here is a set of experiments you can select and run via your A3 Canvas Workshops, add to your Transformation Backlog and Test.
They are in deliberate order – to support progression – to help you adopt, inspect, transition, and transform to Agile Ways of Working at Scale.
You stop at any time/place if its working for you, or you can find your way through and probably end up in Full SAFe territory – a good thing, its adaptable, its flexible, its holistic and its multi-speed and no way as prescriptive as some will make it out to be e.g., SPCs, SPCTs who have to teach verbatim by the book as part of SAFe’s Built in Quality assurance for its Partners and Trainers.
I’ve put the USPs, Key Adoptions and Benefits so to speak of each in, so you can see ow I am shaping and chaining the Scaling by Learning and by Doing?
Kanban and Scaled Lean:
Play 1 - Personal Kanban
Some people need a prompt to start the paradigm shift to Lean and Agile and the 3 Bin or Bucket approach of Personal Kanban is an easy Firestarter.
Do this over a two- or 3-week timebox or 2 - 3 iterations.
Every Manager, Leader has a note book, Post It Notes or a tablet they carry around, so whichever way, they can start to shift their culture, habits, practices and thinking so they start finishing and stop doing is what this is about.
Ask them to write down 10 personal things they need to do this week as Dad, Husband, Wife, Father/Mother to kids, as Uncle as Aunt etc.
Just like the family fridge, at the fish and chippy, the restaurant, set them up with 3 columns, 3 bins or buckets
For the first week, get folks to just start moving things from left to right and see who can do the most tickets, gamify it, hand out some chocolate bribery – this is about finishing, so the debrief is about incomplete work and how much was in the middle column that they couldn’t get to and why it was there not in the first.
Make sure its based on family life, not work – this is a lesson in how to transfer and apply after all.
For the second week, use different colour Post Its for different types of work items.
The lesson is about priority and value. Debrief by asking how they ordered things, why the pulled X before Y – it can get fun here, the wife order me or I was in the dog house, play with it!
For the 3rd week, use the colours and prioritise them using MosCoW, RAG, or other Forced Rank – this is a primer for Scrum based approaches later and to tease out the issues how Kanban doesn’t estimate – just prioritise by card type.
Gamify, debrief, see who done the most done, who could do less or more and why, was any help needed, who helped and why, did they find a tool to use instead of pen and paper and why, hand out big bars of chocolate, or coffee vouchers, ask who felt in more control and had better flow to their work days and week…debriefing them on Kanban’s Visual System of Working.
What you/they will Learn/Key Takeaways/Adoptions:
Basics of Flow, Work Visualisation, Start Finishing Stop Starting,
enabling a “Pivot” to: Essential Kanban and later Scrum.
Play 2 - Essential Kanban
This is when we formalise Personal Kanban and play by the Rules, Principles, Practice.
Trading currency is Work Items aka Cards.
The first thing we do, is run a Value Stream Mapping Workshop.
We knock out the steps from concept to cash and transfer that to our left to right columns on a whiteboard, wall or in a Lean tool like Kanbanize.
Next set your Work in Process Progress Limits – start with rough math based on experience and refine, of how many cards a person can do in a day, week, or iteration, it’s important to just understand the idea at this stage, rather than optimise, to see if the approach works. Debrief on this, discussing the idea of time boxing around product/service releases updates etc.
Now sort your card types, fill the backlog, and try it out.
You’ve probably recognised there is more to it than that, you’d be right, but if I told you everything, then I’d be out of a job or you can read my article on the Secrets of Kanban.
Hopefully the team will now see how it can visualise its work, understand it flow based on demand and people’s capacity and also see they type of work they get – which many managers of teams don’t get or see.
Now there are some option that open up here.
Most teams get coordination issues, need to ask questions, so many adopt the Daily Stand Up – try it, see how it works being aware this is Scrumbanning and it gets messy, and messier, as you keep adding things to plaster the plasters tailoring, bespoking, drifting from the things that change behaviours and practice and make it Lean.
If you can’t sustain the flow, order, and quality indefinitely, by pulling work, then you can try Scrum – where the work is prioritised, ready to go by the Product Owner, under the Product Manager and Scrum Master into 2-week sprint cycles, has a demo for feedback as well as the DSUs that give people targets and thing to work off/too, unlike Kanban which can feel like it goes on for ever! And there no variety as if you can’t finish, it becomes – the anti-pattern of it – stop starty – talk about it/debrief.
If you like Essential Kanban but the team can’t quite run itself i.e., it’s not self-governing or organising – then you could do what’s on trend and use a Kanban Master – like a Scrum Master – but for Kanban, to facilitate DSUs, the help coordinate the team, limit work in process/progress and help with flow by assuring small batches of work appear as Work Items, PBIs.
From here, you can “Scale” from the Team up to Programme, Portfolio and Enterprise Kanban.
What you/they will Learn/Key Takeaways/Adoptions:
Play 3 - Programme Kanban
70% the same as Essential Kanban, same rules, left to right, top to bottom, limit WIP, principles, theory etc just you now have swim lanes on the board for multiple teams and practice downstream Kanban flows.
Your trading currency changes to Features, Components, Enablers, Technical Debt, (legacy, left overs, unfinished work, stuff that needs refactoring) and Maintenance/Run the Shop stuff and it will feel less Lean and more like traditional project/programme management – debrief, discuss why, how, where and impacts to MVB and coordinating team through up and downstream done and backlog work.
As above, the cards into the backlog also now come from the Portfolio – handed downstream in priority to be pulled – as we are scaling, we also scale the system of work and how it flows between teams and departments, just like it did across the Toyota Factory floor.
Queuing and managing queues is a key lesson, the longer the queue, the longer the time to value, to market, the longer it takes to get value into the hands of customers and to see ROI before you can know what to optimise – a discussion to be had and explored around value stream management, SLA, OLAs, KPIs and Flow Metrics.
"This is now where Scrum, Scrum XP, Scrumban are now options for non-technical and technical teams too"
Kanban is slow and consistent compare to Scrum which has shorter, more rapid 2-week cycles, unless you hack it and do month long sprints – bad -move.
You may also want to have some teams in your ART, Scrum of Scrums, Scrum of Scrum of Scrums or Nexus do Service, or Programme streams do Development and while others Operations or ITBP. This feels very Water Fall’ee…because it is, like having tranches in MSP, but it does work and its faster than MSP using heavier weight methods – try it out, here the pragmatic vs puristic arguments.
Many will struggle to coordinate the mixed methods because they have no Enterprise Heartbeat or Cadence to sync to, so release planning is hell on earth and Nexus and S@S can create too many communication channels, creating more overhead and waste than benefits - but it’s an option to test and see if mixed methods and scaled Scrum can work - never say never!
What you/they will Learn/Key Takeaways/Adoptions:
Play 4 - Portfolio Kanban – Big Picture
30% the same as Essential Kanban.
This is the second highest level of downstream Kanban whereby the Solutions aka the products, services, platforms, experiences etc are serviced by operational and development value aligned teams e.g. Programme and Team Kanban teams which is in turn an Enterprise Value Delivery Stream.
领英推荐
The trading currency, is not Work Items or Cards, it’s now:
These come in the form of a lightweight 2 - 4-page Lean Business Cases, Bets and Hedges not 1000-page PIDs to manage the brands category or line of businesses mix of products, services, platforms, experience etc.
You will need to work with your PMO, or steal one from SAFe’s resources and the idea is they are quick and easy to cut and paste into Epic templates in tools which reflect the same fields/entities.
In the left to right columns, we now have a different value stream map including the Innovation Funnel, Lean Start Up and Programme Allocation as well as swim lanes that represent portfolios, categories, brands, service lines etc.
"A pivot from here might be to MoP but I would not see that as a wise pivot"
A better pivot would be to test SAFes Lean Portfolio Management process by lifting it or doing it under the auspices of the Portfolio SAFe configuration – which is a big pivot as that will alter Team and Programme level Kanban as well as introduce Scrum XP and DevOps into the mix, so a big jump in skills, knowledge, understanding and application.
What you/they will Learn/Key Takeaways/Adoptions:
"Enabling Scaling to: Portfolios of Portfolios and Enterprise Kanban"
Play 5 - Enterprise Kanban – Biggest Picture!
Most big Enterprises, Governments or Militaries don’t have one portfolio, they have multiple reflecting their categories/lines of business, brands, brand SKUs, Ministerial Depts, functions, agencies, Army, Navy, Airforce, Spaceforces, Intelligence Services etc. Others use Operating Brands as Portfolios like Big Consultancies or Alphabet.
The trading currency here is strategic themes, imitative and policies – which exceed all the boundaries of the Agile Planning Onion or Horizons and Roadmaps, the 10, 15, 20 and 50yr thinking and budgeting.
This is dealing with the 80.4km, 50 miles, or?264 000?feet view from the edge of space.
What they will Learn/Key Takeaways/Adoptions:
"Enabling Scaling to: Be Visionaries, Futurists, Gods…"
Scrum and Scaled Scrum:
Play 6 - One Team, One Product Scrum aka Scrum.
Scrum is single method process framework unlike its cousins and spin offs who can just about justify the framework tag.
Scrum uses the Visual Workflow Management of Kanban or the Lean Information Radiator concept and adds in the spin cycle, or the sprint ands its associated backlogs, artefacts, events, and ceremonies.
Its great for simple products and services like a brochureware website, managing a social channel.
Its also great for non-technical stuff. Here is how to do it in 20 pages.
User Stories are not Scrum’s – they are Agile’s way of doing customer focused requirements which are traceable, auditable, contain the acceptance criteria and NFRs to support test cases and testing, using the As a …and Get When then formats.
If your serious about customer centricity – then you’ll discuss adding this mod in via Planning Poker.
If your serious about predictability, then Agile Planning above Sprint Planning is a mod to add in.
Key Discussion and Debrief points, aside from the above should focus on Sprint Goals as many teams just do Kanban and don’t build services or products as there is no order – so the PO provides priority PBIs and the team decide how to deliver them and in what order. Most also add a Release and Sprint Backlog in after the Backlog to help flow and WBS – yep – decomposing Epics into Stories to Tasks and Sub Tasks – slicing, decomposing – creating small batches of work.
Pivot Options:
Scrum XP i.e., a Scrum hybrid combined with Extreme Programming, a spiral approach specific to Software Engineering, requires TDD, pair programming and other skills plus the team doesn’t get to choose the order in which they work, it set by the PO and that strict order is bit commanded and controlled!
Scrumban – a hybrid mash up of Scrum and Kanban, Scrum for those who can’t seem to do Scrum is my take on it!
Ignore Scrum with Agile – an attempt to fix Scrums incomplete project management by adding some PM stuff and dubbing it Agile. Cynical critical maybe, but I’ve seen it turn too many times to the Water Scrum Fall anti-pattern.
If what you’re trying to do is too complicated and you make pure Scrum work, then this is were and why the many Scrum based Scaling methods come into their own – some better than others, but there are several choices.
What you/they will Learn/Key Takeaways/Adoptions:
"Enabling Pivots to Scrum Scaling Methods or Scaled Lean Agile Frameworks"
Play 7 - Nexus
Nexus sometimes called Scrum Professional Scrum following Scrum Org Certification naming convention - is similar to Scrum in that is has a single Product Backlog, a single Product Owner, and a Scrum Master but the single Scrum Team is split/scaled to 3 - 9 teams and a NIT or Nexus Integration Team is added – basically the PO, SCM and Team Members from the 3 - 9 who help out, hoping they have the skills to do so by cross sharing.
Most Scrum Teams end up by default doing Scaled Scrum before they even know it whether its Nexus or Scrum at Scale below.
They do this by organically splitting themselves up into Design, Architecture, Component, Test/QA and Feature Teams either using swim lanes on a single board, or by creating their own boards to manage work they take ownership off – creating the 3 -9 teams as a result. They then work as individual contributors to get it done and Scrum Master most often miss QA, this, because they don’t see it as work is getting done overlooking team dynamics and inter team dynamics – the stuff that makes people unhappy or happy!
Discuss how Nexus might be different from this if you’ve ended up experimenting with Scrum, Scrum XP, if not, skip it for LeSS or SAFe, the NIT should be a point of conversation to, as if it adds value or not and the fact that 3 -9 teams 21 – 81 people (applying 2 pizza rule, 7 +/-2) are doing a en’masse Daily Stand Ups, Demos and Retros and how this is coordinated, managed, and adopted in a workplace/space.
What you/they will Learn/Key Takeaways/Adoptions:
"Enabling a Pivot to LeSS, LeSS Huge or Essential, Large Solution SAFe with “Trains”
Play 8 - Scrum at Scale
Scrum at Scale (S@S) is modified Scrum, allowing a network of teams to operate consistently using Scrum Theory and additional Practices.
It’s different to Scrum and Nexus in that it has two dual, but complimentary cycles, the Scrum Master Cycle and the Product Owner Cycle that operate independently but complimentary to each other to sync and coordinate the network of teams working on the complex deliverable.
The other aspect/USPs to Test and Learn is the EAT and EMS.
That’s Executive Action Team and Executive Meta Scrum.
Scrum generally become overly tech focused, but here, more like SAFe, it brings the business in to help develop and deliver what they own and want and makes for a good debrief/discussion point around stakeholder engagement which is limited to Scrum usually practiced in the confines of IT depts.
The ETA is a the SCM on steroids to gets delivery impediments moved out the way with middle management and the EMS is the same, but for the products development via the guises of hierarchy under the Chief PO with all the Senior Leaders/Execs.
The other thing I like and works better in practice that Nexus, Nexus Teams and NITS, is that the Scrums of Scrums and communication overheads is done collectively under the concepts of MVB or minimal viable bureaucracy, the fewest people possible to govern. Control and manage.
?Unfortunately, the opposite seems to happen, and you get 30 SCM, 30 Product Owners, 30 Senior SCMs, 30 Chief Product Owners instead of the MVB.
This is a good debrief, learning and decision point as is the Scaled Daily Stand Up that require the workplace/space for lots of noisy busy people to have a good conflab without annoying the rest of the office trying to speak on the phone.
?It also leads you into Big Room Planning to coordinate across teams but this does require a planned co-located workspace as above which is a drawback, but I find in this day age, we overcome this with remote and virtual working and distributed agile – which is a real thing people.
What you/they will Learn/Key Takeaways/Adoptions:
"Enabling a Pivot to LeSS, LeSS Huge or Essential, Large Solution SAFe with “Trains”"
Play 9 - LeSS
Large Scale Scrum is based on Scrum, but is highly adapted and is “barely sufficient methodology” by design.
Adopting LeSS is a Coaching led approach, and requires LeSS Coaches, Technical Coaches, Team Coaches and Enterprise Coaches.
Its very pragmatic, and was developed by experimenting, test and learn style and its USPs are loved or loathed like vegemite or marmite, smooth or crunchy peanut butter, but its also why it works – it creates an organisational culture change!
LeSS is for up to 8 teams and LeSS Huge is for 8 or more teams. There is no on mass all team DSU, each team holds its own when they want it, ther is an overall product backlog review and retrospective where representative attend on behalf of teams, not everyone, but sprint demo are done Big Room Style with teams, stakeholders and customers.
Its USPs from Scrum are 2 Sprint Planning sessions, I for the PO/SCM, the other for the Team/s.
LeSS has:
?3 Principles:
Rules:
Mantras:
And more Rules for LeSS and LeSS Huge and more Principles than just Adoption Principles making it hard to navigate underneath the
"These are all good things, but they feel quite unnatural, radical, and revolutionary when people discover them and there is there’s No Change Initiative, no Change Group, no Change Managers, Projects Mangers are banished along with Performance Reviews, Appraisals, it requires Structure Changes and Change is the Status Quo"
It also has 7 Organisational Design “descaling principles” to apply, so, if you’re looking for a mechanistic, simple Scrum approach, the below should be early discussion points:
1.??From?Specialist Roles?to?Teams
2.??From?Resource-Thinking?to?People-Thinking
3.??From?Organizing around Technology?to?Organizing around Customer Value
4.??From?Independent Teams?to?Continuous Cross-team Cooperation
5.??From?Coordinate to Integrate?to?Coordination through Integration
6.??From?Projects?to?Products
7.??From?Many Small Products?to?a Few Broad Products
My experience of LeSS is limited, lots have looked at it and many run quickly from it when they see the “Rules” which is anti-agile to Agilists mindsets and those that have done and don't get Scrum, don’t like this as they say its Scrum stacked up – which is true.
What you/they will Learn/Key Takeaways/Adoptions:
"Enabling a Pivot to DA/DAD, SAFe or Up/Down Stream Programme Kanban"
Scaled Lean Agile Frameworks:
Now we are really getting into a different bit of territory – mixed methods, complimentary methods, practices, beyond 10 teams and multiple configurations and lifecycles.
Play 10 - Disciplined Agile
It’s started like this on the left – a process driven, and now it looks like this on the right – with configurations, competencies and spanning palettes.
DA/DAD thinks it’s not a method or framework but an agnostic goal driven toolkit, (that’s has principles, promises and guidelines and lots of processes…)?and its USP is the freedom for each and every team to be agile, by combining the best of Agile for tactical and Strategic Business Agility by not following Scrum or SAFe enabling growth, from being delimited by said methods and scaled frameworks.
Here are the catches – it uses 2 different names – lifecycles – that’s the same as a process method and process blades - 24 top level and multi lower-level ones – inspect and discuss and see what you think, is it different or is it just Kanban, Scrum and DevOps and do the blades help integrate good technical practices e.g., the complimentary stuff to make it more complete?
Here is a simple example of how you’re told to do Continuous Improvement using the CI Process Blade, (but it’s not prescriptive??Its toolkit guidance!! oh yeah…and its streamlined process - whatever)
It supports the CoP concept, which I back as a great way to sustain and self-regulated good practice post the adoption and transition waves and good way to promote continuous learning, inspection, and adaption.
It has a weird take on Centres of Excellence, (which I generally don’t like) i.e., COEs are typically formed to address a skills/knowledge deficit within an organization. Ok... and they are staffed only by Agile Coaches..huh?.
Well, hhmmm, but we know COEs don’t work from years of tracking in the State of Agile, State of DevOps reports and Accelerate – where they proven to be a consultancy tentacle that wont let go and a dependency that doesn’t uplift teams, as the COE does it for them – making them, well not cross functional or multi-disciplinary.
Its was devised by Scott Ambler, ex IBM, ex RAD, RUP and Rationale methodologist, so that explains a lot and is now owned by PMI – that should make you shiver too, maybe it’s a good thing, but their take on Wagile isn’t for most and is only being done to keep them relevant and on trend, oh a strategic business move, sorry.
Explore the Mindset and 7 Agile Principles, the Flow concept, Practices and Roles – it allows people to wear multiple hats and we now multi-tasking just doesn’t work and cognitive overload is an issue for 90% of us.
Personally – its framework and that’s why I have put it here and it looks more an more like SAFe – the thing they hate everyday – don’t figure!
"Personally – if you detect cynicism, sarcasm and more, it’s because I really don’t like it, their attitude and rhetoric preached – there is too much anti everything else sentiment from all their BS, pitching and pitting you against Scrum, SAFe and any other agile thing because only they are the best – it’s boring, tiring and the take up of DA reflects this"
DA is potentially for you if you think giving opened ended choice to people that don’t know what better is and want to go on a long-winded journey of enlightenment vs an accelerated journey, sorry, it has good elements/ points, like being people-first, learning-oriented, risk-value, goal-driven etc but the positioning, attitude and rhetoric are too elitist, privileged and ego centric -we are better than everyone else – but if that’s your thing, then it’s an option on the table.
Its also not a Business Agility Framework either like it tries to claim, but it does allow Scaling from its scope for Agility e.g., DAD, DevOps, e.g., DADO, the IT Dept e.g., DAIT and then the Disciplined Agile Enterprise e.g., DAE i.e., the DA Onion
Its enterprise aware, well as long as its IT solution delivery as its focused 80% on IT via the above diagram and the DA Scaling Onion - its approach to scaling the processes and blade sub processes – so inspect, discuss and debrief on this carefully to see if it creates a recognisable and easily understandable lean Agile System of Work – in my expereince it doesn’t, and auditor and regulators tear it to bits as every team does something different and this isn’t good when regulatory compliance is a key thing for the business and ISO standards are at play.
What you/they will Learn/Key Takeaways/Adoptions:
"Enabling a Pivot to SAFe or Enterprise Business Agility Model"
Play 11 - The Scaled Agile Framework
SAFe is a proper framework that encapsulates 3 configuration levels, 7 Competency Areas and many complimentary methods, practices domain practices and disciplines along side core value, principles, free guidance regulatory updated, books, videos, and certification paths.
Its targeted for being overly prescriptive, like Scrum, but you won’t find anywhere where it says it prescriptive.
Guardrails are loose boundaries – not prescription.
If you can follow a process, Scrum or SAFe then you’re probably not Doing or Being Agile, just saying it.
There is a huge difference in being Agnostic to UnAgile.
In terms of Adoption – they have provided a well-trodden and proven blueprint and of course, lie everyone else, its tagged into Delivery Partners and Training Partner Networks as that’s the monetisation model.
In terms of scaling, there are configuration options, from easing in via Essential SAFe or going the full hog via Full SAFe depending on use case and even versions for Private Enterprise vs Governments – no other method of framework has done that, a USP.
The supplied Roadmap makes complete sense if you are complete newbies, or feel your immature, so I do a few things differently.
Each configuration has several Competencies to Master.
I use these are the pre-requisites and do Bootcamps, Health Assessments and Training as part of the Change Readiness/Disco Sprints as the first PI – in other words, I use the Framework to implement the Transformation – starting like I mean to end – but not always following the snake in order, making criss crosses – to the snakes and ladders board.
In the process map/Big Picture the pre-req’s are the circles on the bottom and left.
If you have used Scrum in particular, then you’re likely to have established the Agile Roles – but you will need to shift mindsets still, so invest in more top up training to reinforce Lean Agile Leadership and well into things like SAFe Architecture, SAFe software engineering, product management and SAFe Scrum Mastering and RTEs, which are a bit different to Scrum, so you can train the gaps i.e., XP, DevOps, Big Room Planning, or send them on the official course ware.
In each PI or programme increment, there is an event called I&A – Inspect and Adapt. This is and I use this as the Optimisation meeting to improve/preserve by Coaching and Supporting the mad and sads, to balance off with glads before discovering and launching more value streams and value aligned teams based on maintaining SAFes House of Lean:
So, you can go slow bottom up or top down.
If you’ve tried the Playbook in order, or have hit the dreaded J Curves or S curves or in failure mode because DA has left you in disaster because no one gets it, cant see how it works, were work flows to and from, then correcting this from the top and bottom then “meating” in the middle of the metaphorical sandwich Is a great recovery strategy.
Each configuration can be followed by the team, a programme, by solution, by a portfolio and by the Enterprise – this is the unique value proposition of SAFe – it’s a complete Lean Agile Flow Framework.
Each config seamlessly joins up to Full SAFe – so you can deconstruct it into 3 plays – coach each one separately but know your actually doing the big picture play. Genius right! No other method or framework allows for this using such an easy to follow, visual map or roles, process, responsibilities, techniques.
Essential SAFe is the Team and Programme level configuration where one or multiple teams form an ART – Agile Release Train, using the ART canvas, and leave the station/sprint at the same time, to all arrive to deliver the increment/demo and then ship it via some teams using Scrum XP and others using Kanban. Its similar to Nexus and S@S NITs, SoSoS in that the Agile Release Train is the centre for the coordinated universe for value delivery and flow, but with less overhead and link to scale beyond both of those options.
Portfolio SAFe is focused on Value Streams, Lean Budgeting, Lean Start Up and down stream work flow management – I usually add in a Growth Portfolio where all the new bets and hedges for innovation go as Operational and Development value streams lack the Innovation Management needed, providing what we call Innovation Theatre - no value creation – because they tend to end up being BAU e.g. Build the Business Run the business Feature Factory due to ITIL and ITIL types – something the SPC and Agile Coaches have to watch out for, so discuss how you will prevent this by embracing ITIL and ITSM, but by putting DevOps front and centre above it – even in its place – that’s what it’s for!
Large Solution introduces the Solution Train, a Meta Scrum of sorts, its were several ARTs form and power an even bigger Train, an ART can contain 50 - 120 people and stakeholders on a synced cadence, while STs can contain thousands to build aircrafts, civil infrastructure, even rocket ships to Mars and involve third party suppliers as an ecosystem – this is another USP of Large Solution or SAFe in general – it brings your outside inside to co-create – a capability higher than collaboration.
Full SAFE gives the Executive Board and C Suite Leadership oversight to grow and measure the business towards Business or Enterprise Agility and provides full up and downstream coordination of value discovery, value creation, value delivery and value management. You can’t really scale any further than this because it made up of all the portfolios of portfolios of portfolios – the entire enterprise and all its businesses, lines of business, brands, products, services, and experiences.
What you/they will Learn/Key Takeaways/Adoptions:
"Enabling a Pivot to “The next big thing, if and when it comes about!”
Enterprise Scrum - Hidden gem for small to Medium Orgs
This is a bit unique, in that it is based on the Lean A3 Canvas Technique and is highly modified Scaled Scrum.
An option or choice, and not one that’s widespread in use so I wanted to note it, but as its not supported like others, it can be difficult as there is limited materials and people trained as trainer or coached in it due to Mike Beadle, co-author of the Agile Manifestos tragic stabbing death in 2018.
Find out more here: https://www.enterprisescrum.com
To RICE with That
If you don’t like my Playbook and how it progressively makes the linkages to grow, by learning from doing, then you can skip it and use a RICE Score Card approach that tools like Roadmunk use for Idea/Portfolio prioritisation, or you can do it in Excel or on paper.
Reach – how many people will this impact in a defined time period e.g., 10, 100, 1000
Impact – How will it impact each person, Huge = 3, High = 2, Medium = 1 and Low = .5 Minimal =0.25
Confidence – How confident are you in the above estimates, High =100, Medium, 80, Low = 50
Effort – How many months will this take – use a rough high level ball park estimate, stay out of the weed aka detailed low-level estimates
Socks and shoes off, add Reach, Impacts and Confidence Scores and divide/ by effort.
Well, a lightweight prioritisation model learnt!
Setting up a Spotify Model Style Community of Practice
The infamous Spotify Model is not an Agile Method or Framework and wasn’t implemented at Spotify – it was a conceptual idea to get teams working closer tougher in alignment to produce value under a matrix design.
What you can pull from it though, is great model to create a CoP i.e.:
Guilds contain the Master Practitioners, SMEs and Coaches that evangelise, coach, mentor, hand down and share knowledge and understanding and application from experiences
Chapters – are your local version of the Guild, making them accessible, especially under a hub and spoke, decentralised org structure as the Guild is virtual in reality.
Tribes are specialist areas e.g., DevOps Tribe, SRE, Tribe, UXD Tribe were specific content, learning and resources can be found on the subject, topics, roles, responsibilities etc.
Squads – are the proxy for the team, and people from Squads access the Tribes content, webinars, and Guilds training etc.
These manifest out in practice as Agile Hubs, Engagement Hubs or Portals as standalone Intranet and SharePoint sites or within Teams, Slack, Confluence etc.
It’s a great thing for HR to won and build, as it will get them Agile in the process of building it and they will absorb by osmosis, the content, so developing some conscious competence.
The role of benchmarking and Health Assessments
"If you want to kill your growth – benchmark your team and tell them how crap they are compared to company X"
I think that says it all, if you don’t get this sarcasm, its because you need to better understand Lean Agile and DevOps culture – LeSS will give you the answers…or the section here will!
Health Assessments from AgilityHealth, Scaled Agile Inc are the way to go. They only compare the team to the team, so are focused on real learning, growth, and improvement of the team and no one else.
As Coach, you need to understand the State of Reports, the benchmarks, and Comparators as this is how you shape and guide them, but unless they ask, and you can put the answer into context and under caveats, then keep it to yourself.
Conclusion – There’s My Scaled Agile Advisory Service, for Free
Well, I've got plenty more from the trenches to share.
There are many options and choices to test and learn on your journey to Agility.
You can jump in head first, go the whole hog or do it incrementally by setting up a Continuous Learning Culture and following my Playbook or not.
Most of them will uplift your process, productivity, happiness of employees if done right. Some like SAFe are proper game changes that haters love to hate.
My goal was to help you accelerate your enterprise adoption of Scaled Lean- Agile practices.
Also, to achieve sustainable business results through testing and learning using experiments in a Growth Portfolio lead by the Agile Guild, Executive Agile Transformation Team as your First Agile Citizens.
Many will provide the skills to transition from one to another, in a continuum of sorts, from Lean, to Agile, from Agile to Scaled and all beneath the umbrella of Enterprise Agility.
They key to success is to start with the end in mind, to avoid the rudderless anti - Agile/UnAgile.
SAFe is currently the most complete of the methods and frameworks however, there is still a bigger picture above it in the Business Agility Models and Domains like the EBA example shown.
However, you get there, it’s a journey and I hope you guided by a reputable, credible, and authentic Agile Coach, Enterprise Agility Coach, Business Agility Adviser or Strategist who can guide you towards that North star, but never quite reaching it.
Be patient but persistence in the pursuit of high performance and Agility.
Have low expectations but celebrate failures and much as success.
Set a Roadmap out with Goals and Key Result Areas and own it lie you mean it.
Expect to meet them – purposefully steering he hip not leaving it to organics, you still be waiting in 2100.
Have courage, use humour, be humble but be assertive.
Use Agile and Enterprise Agile Coaches for your experiments to avoid novice/white belts making unskilful decisions to their detriment, adopting Agile in ways not intended, with obvious problems from when you/they can’t understandably get or see the key basics.
The only stupid decisions are not to anchor/use methods, frameworks, and models.
Shu—follow rules to learn basics.?
Ha—break rules and discover context.?
Ri—mastery and find your way