I was asked a very powerful question yesterday by “How does the Sprint Goal fit into the Nigel Scale.” I haven’t commented on this before, as I am not sure I would have been able to articulate it – Till now.
Short Answer for those who want to avoid thinking: “Sprint Goals are a core part of Scrum”.
Now, the full answer:
(Warning: LONG RAMBLE APPROACHING and I cannot promise I will coherently articulate this by the end of the article!)
What is a Sprint Goal?
A Sprint Goal, under its most current definition, in the 2020 Scrum Guide, is:
“Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.”
As of 2020, this is regarded as a “commitment” to a particular Scrum “artifact”: The Sprint Backlog.
If we look back over the history of Scrum, this idea has taken slightly different shape:
The earliest version of any Scrum Guide I have is from 2008. I’m not sure if this was ever a publicly available version or beta, but it says:
Having selected the Product Backlog, a Sprint Goal is crafted. The Sprint Goal is an objective that will be met through the implementation of the Product Backlog.This is a statement that provides guidance to the Team on why it is building the increment. The Sprint Goal is a subset of the release goal.
The reason for having a Sprint Goal is to give the Team some wiggle room regarding the functionality. For example, the goal for the above Sprint could be: “Automate the client account modification functionality through a secure, recoverable transaction middleware capability.” As the Team works, it keeps this goal in mind. In order to satisfy the goal, it implements the functionality and technology. If the work turns out to be harder than the Team had expected, the Team collaborates with the Product Owner and only partially implements the functionality. “
With this older example, we can see an err… example of a Sprint Goal. Which sounds to me like a rather large PBI.
If we look at a guide somewhere inbetween (2016), then we can see this:
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.”
This sounds a little like a contradiction of its own opening paragraph – Though I assume it is there to communicate there is no one way of doing a Sprint Goal. I.e. It is NOT a big PBI as mentioned in the earlier example.
In earlier versions of Scrum (drawing from Jeff Sutherlands self-produced PDF from 2011 combining all the early free writings on Scrum, “The Scrum Papers.pdf”), there is very little mention of Sprint Goals at all by Ken and Jeff. The only mentions there are by other authors of those papers – Mainly the original implementers of Scrum in Yahoo in 2006 (Tobias Mayer, Gabrielle Benefield, Pete Deemer etc)
What does get mentioned, is “The objectives” of the Sprint, and how the Sprint Backlog is there to achieve those Objectives.
At this point, you are probably wondering why we are taking a very semantic journey through A Brief History Of Sprint Goals.
Well, this is because of Sprint Backlogs. As Sprint Backlogs have evolved over time, so have Sprint Goals. This will have a knock-on effect about their usability, misuse and need for them.
Reading these papers, (and having lived it!), Sprint Backlogs used to be HOW the work is done. The SBIs (Sprint Backlog Items!) or Tasks or even “packets” are a breakdown of HOW the Development Team will achieve it’s objectives.
In the earliest papers, this is very much driven by this high-level concept of “Objective/s”. And to my understanding, this would today be regarded as Epics. AKA Bloody big stories.
So a large item is brought in, the team break it down into it’s constituent parts, and then build those parts. The team can adapt HOW they do the work to achieve all of that single WHAT in a sprint. There is much talk of failing to meet that commitment, how important it is to achieve it, and how these are an example of “punctuated equilibrium” – AKA you don’t see anything for a while but things are changing under the surface then PING! A feature appears.
Then Product Backlog items in the User Story style became integrated into our understanding of Sprint Backlogs. The WHAT being closely aligned with the HOW – at a lower granular scale. Each WHAT decomposes into it’s own HOW to do it. We no longer need this pressure of “all or nothing” in a Sprint. The infamous Waterfall Sprints become officially the anti-patterns, they always were.
The Goal in the 2008 example, is as a friend said to me “technical gibberish”. It’s a WHAT that is swimming very close to the sea of HOW. It is also how we see a lot of Sprint Goals in real teams. Their goal is merely a superset of their pulled backlog items. The way you would see it in 2020 is:
“Automate the client account modification functionality
AND secure the automated client account modification functionality
AND add recoverability to the automated client account modification functionality
AND add the automated client account modification functionality to the middleware.”
(For added authenticity, add AS a Developer… at the start and a JIRA ticket Number)
This is not a goal. Or at least, it is not a goal that has any form of use in helping us build better products. It’s a commitment to specific functionality that will squish the team.
Back to the 2020 guide: “The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.”
A goal is to encourage interwork, creating a real team over a working group. But it needs to be more than that. A good goal is less focussed on WHAT then on WHY. A good Sprint Goal is outcome or impact driven more then function. A good goal is gestalt.
You see, this is a good sprint. It has many items of value. Each Transformer turns into a robot AND a car. Hence, the name. BUT this Combiner is more than just five robots that turn into cars. They also combine together (Hence the name) to make a big robot with a big sword. They have individual value and together have a value more than the sum of their individual robots.
This is what a good Sprint Goal looks like. Some sort of gestalt coherence.
I have seen the term Gestalt used by Jim to describe the Increment, and thus by implication the Sprint Goal.
This can align with modern tools like OKR’s to create a Sprint Goal that has measurable impact. There is a slight “Chicken and egg” issue with Sprint Goals in that they are defined by the Scrum Team (This includes PO) and also can be fed into Sprint planning by a PO under stealth, as the idea of a large PBI at the top of a Product Backlog. So we can see avenues of misuse become available.
I have also read Cope talking about “hansei” – A Lean term with which I am not familiar, but seems to be some form of “form of collective shame or regret from having let down one’s self, colleagues, stakeholders, and is fundamental to improvement.” And is a key aspect of Kaizen. Sprint Goal in his mind is about that. A challenge to strive to achieve. A commitment that if missed creates an emotional suffering by the team. Hmmm.
It turns out Sprint Goals have been recorded officially in Scrum since Mike Beedle and Ken Schwaber’s 2001 book “Agile Software Development and Scrum” – and the philosophy has been around since the early days of Scrum.
So, we can see there has been evolution of Sprint Goals over time. From an almost Big Hairy Audacious Goal on a development cycle of a month, with the team self-organising, twisting and turning and being clever to achieve the result – To a more Extreme Programming flavoured Product Backlog Items being INVEST and thus stronger atomic units of value being sliced and delivered in small chunks. One cannot “fail” such a Sprint, simply rolling out the one or two stories that were not completed into the Product Backlog for next time.
That would seem to leave Sprint Goals into the annals of history.
(An aside: It does strike me, reading between the lines, that the more “BHAG and Go!” menatlity being more Sutherland, the INVEST/Stories mentality coming from the XP world of Beck et al and Schwaber falling somewhere between the two.)
So, let’s look at an example team. They take a range of high priority but disconnected items from the top of the backlog. A,B,C,D,E,F,G and H. This large product has a range of stakeholders and interested customers, (and unhappy ones!). By pure convenience, each stakeholder has an individual story, that falls into their “stake”. SA has A, SB has B and so on.
What happens when we get to Sprint Review? We have an increment of the highest value possible. But the increment is NOT gestalt. Why would that matter?
As Stakeholder SD. I am VP of marketing. You are asking me to attend a 2-hour session on Friday to show me this feature. This meeting will consist of 85% of nothing I care about (A,B,C,E,F,G,H). I will not be attending your workshop, as I have just the one life and I am not spending it there.
Thus, you end up with a Sprint Review that only the PO attends and cares about. Your session becomes narrow minded and a waste of time. Missing out the rich and valuable input from those key figures.
These “bric-a-brac”* Sprints are common place and whilst being “better” that what we used to do twenty years ago, are not the way forward today.
If we theme the sprint around one area of focus, this can encourage engagement with stakeholders, excite and align the team around a concrete direction, and create a genuine gestalt increment at the end which offers real value.
Nigel Scale Time.
So, if I was to theoretically visualise Sprint Goals over time, the answer would be this:
Sprint Goals are a core part of Scrum.
However, due to the difficulty and the troubled nature of Sprint Goals with how they have been used historically, I know famous Scrum Trainers and coaches who have never used Sprint Goals. The fact they have had success does tell us something… was there something else going on? Was the classic concept of the Sprint Goal not utilised, but the deeper underlying pattern behind it was?
The pattern of Sense of Purpose applied at a Sprint level, not just the macro-Product level as a Vision?
From my conversations with these coaches, I feel that was there – But I do not have hard evidence for that.
So perhaps Sprint Goals look more like this:
This takes us to a rather deeper philosophical position. Dammit, it takes us into TWO deeper philosophical positions!
Position One: Why does Scrum evolve? I do not know of any public position taken by the two “inventors” of Scrum, of why they update Scrum periodically, beyond making it “better”.
If we look at another technique that been updated periodically, SAFe – We can see why. Because some of its recommendations have been fundamentally wrong and damaging, and thus they update to remove these anti-patterns. (This has been too slow and insufficient – But I digress) or to incorporate new ideas (without experimentation or empirical evidence – but I digress again) – This is the danger of an approach trying to capture the entire concept of all NS2- Good practice within itself. Where do you stop? SAFe Teethbrushing?
But Scrum is different. Scrum has consistently thinned over its 25+ year life. More and more removed from NS1 core practice and moved into the “good practice” domain. And since Scrum deliberately does not define any NS2 practice, it falls “out” of Scrum.
I have always assumed that Scrum thinned as a (perhaps subconscious) effort by them to get the fundamental heart of product development frames. (This is why for me, there is a tight alignment between what I regard as “essential” and Scrum. Not because I am some acolyte, but it is a great MVP of practices for me.)
Or is this thinning it to make Scrum more applicable in wider settings? To broaden the net that Scrum reaches? For noble, or less then noble ($$$$$$) reasons?
Because if it is to widen – We have to consider that Scrum has journeyed outside the world of software, into the broader world of product development, and further again.
In that space, some of these core ideas, start to become unhelpful.
E.g. I have worked with a medical device company using Scrum to manage their installation of medical products in hospitals. Their work is by its nature atomic:
Whereas, if we look at product development, as we mentioned before, is = by it’s nature is GESTALT. A whole that is grown over time
So, by changing the type of domain we are working within, practices have to be adapted outside the current recommended models in Scrum. (Definition of Done being identical across PBIs – changing to the idea of DoD individual created per PBI item – or type of item)
Or may become invalid – Or at least so different to become unrecognisable or plain wrong. (What is the Sprint Goal of that Medical team: “Do all your work in your sprint?”)
Applying the third dimension to the Nigel Scale of something like Kent Becks Explore/Expand/Extract model: (
We would a slightly incomprehensible graph like this:
So what I have done is split it into another dimension:
This is work that in the world of Cynefin, is starting to head towards the complicated/clear workspace. We can see the critical nature of Sprint Goal falls away into Good practice. This doesn’t make it an anti-pattern – Just not universally applicable.
And it’s not just this space – Lets come back to something in-between – A team doing some form of Continuous Delivery in a stable, incrementally improving product may not have interesting or big goals to aim for…. So Sprint Goal is an irrelevance. But does that lead us back into Bric-a-brac quicker then ever before? And does that lead us to genuine great products? Or just inching tech forward? It looks like Sprint Goals are a Product Management practice wrapped into a Product Development approach. A motivator perhaps? A challenge? Maybe. But a product and value focus that maybe missing in a world of Kanban and Continuous Delivery.
And this leads onto the second big topic here. Scrum changing by who? I have been slightly sneaky and used Scrum as a Synonym for “The Scrum Guide”. The creators of Scrum are actually the curators of that Scrum Guide document. (Which BTW lacks all aspects of being a guide – instead it is more a neutral specification)
Scrum is more than that specification – As I speak about in the above video. What form that is, I do not know. I do know that the guide trails what “good Scrum” is and updates to track it. People were doing 2 weeks Sprints long before it was “official”. I also think that concept of a specification lacks context and nuance that future Scrum will need to be helpful.
My Nigel Scale work (categorising/visualising/mapping) is just one small* individual’s work to try and add that context – There needs to be others.
This maybe where the Nigel Scale starts forking from the Scrum Guide – But not Scrum. Or at least, as you may have seen how I position this: I used to think Scrum = Core. Now I think Core = Scrum. Or at least Core SHOULD = Scrum. Does it, in this current incarnation? Not yet.
The Scrum Guide says the Sprint Goals are core. Fundamental. I agree with this in most contexts.
But “most” is doing a lot of heavy lifting in this sentence. Because of the difficulty in getting Sprint Goals to work without misuse in newer teams and organisations and because of the use of Scrum in situations stretching the definition of “Product Development”, and just looking at how Scrum works in the world of work – Is it core?
This piece of modernist absurdist art is what I have been working on over the weekend.
Sprint Goals may not be proper for a new Scrum team, may continue being inappropriate if we stretch the definition of Product Development too much, and may taper off in advanced teams, but perhaps for the wrong reasons! Tapering into possible good contextual practice is OK, as long as we understand that is for Product Value related reasons (more Extract etc) then technical ones (“We continuously deliver! Technology is solved so the business model is solved!” No. Small slices can equal low impact. This is not always the right choice.
I am still looking for something in that third dimension, that I haven’t quite captured yet. It isn’t Cynefin (Generally, the work that fits Scrum best is the Complicated/Complex environment – but I am not sure some of the Good-Scrum-without-Sprint-Goals falls clearly into Clear work) or Kent’s EEE (More about Business models then type of work)
A goal is there to create a sense of an arc, a quest, a journey as a group to become something more, to create something more.To make a dent in their universe. If this is missing, or overly high level and obscure, we lose an critical essence in the world of high performance. Because this is what Scrum used to be about. Great teams and great products. Just because something is hard, doesn’t mean it is wrong.
It would be easy to draw a line between Product Development and Not Product Development… but I do not know where to draw that line.
Perhaps the first example I gave was definable as Not Product Development… but what about the second? And what are the implications of for a team of that? I can say for sure, that cross-over, ambigious space is interesting!
So, in conclusion for the brave souls who reached this far – Sprint Goals are for the most part absolutely critical to go from good to great Product Development. Within certain definitions of “good”, “great” and even “Product Development”. They are offically core in Scrum, but perhaps not core in practice.
But be careful using that “but” – I bet you would benefit from short term, impactful team goals.
EDIT: A few things I haven’t mentioned here which I wanted to… About the evolution of Scrum. When longer Sprints were popular, – Bigger, more business impactful increments were created. There is an argument that “smaller” increments (2 week Sprints) then meant that less impact was felt – Causing them to need to be piled up into a “release” with perhaps a “release goal”. So shrinking development episodes may lead to the slightly contradictory solution of delaying value or reducing it’s effect. In that case, A Sprint Goal isn’t the solution, but a lack of it could be an interesting symptom, revealing some problems with our approach to delivering value.
Story Points – Two divisive words in the world of Agile 2022. A technique I remember being regarded as outlandish and extreme 16 years ago, is now regarded as passé and perhaps even actively damaging. It’s been on quite the journey.
I was asked, whilst on-stage at Agile Lean Brighton, what my thoughts were on these supposed insidious items, whilst surrounded by many a Lean person chuckling and throwing shade on the mere idea.
What did I think of Story Points?
I have complex and multi-faceted feelings towards Points, and I wanted to write this article to try and explain that a little bit. It’s easy to throw shade (A few of us did so in Copenhagen at SAFe and we ended up having a nice fun row about it at the speakers dinner later!), and often the shadow is well deserved.. But the attitude that got us INTO points, is accidentally getting us OUT of them, missing the value both times round.
FIRST A history. Or more/less(?) precisely My story of the history of Story Points.
WARNING: This is going to be wrong, filled with untruths, misunderstandings and gross misrepresentations – But as Maxwell Scott said in “Who killed Liberty Vallance”:
“Ransom Stoddard: You’re not going to use the story, Mr. Scott?
Maxwell Scott: No, sir. This is the West, sir. When the legend becomes fact, print the legend.”
(But in my defence, my version will have better narrative flow and jokes)
Before the birth of Story Points, we must track the birth and life of its father – Ideal Days. In work of the past, people took educated guesses, or as we call them, estimates, in how long this work would take. These estimates would be in Time. Real Actual Time.
The problem with estimating in Real Time, is that it is not only prone to a range of unexpected and unwanted psychological manipulations, (Anchoring, Confirmation Bias, etc) but it is also FRAGILE. An estimate given today for a piece of work, is contextual in doing it – Today. Next week the work may take longer, or span a weekend or, or, or…
So many a year ago, Humanity invented the idea of the Ideal Day. If I could be at all bothered, I’d now cut and paste something on Ideal Day History from wikipedia to here, but as we all know – An Ideal Day is not Real Day but instead an imaginary abstraction of what we could do with zero interrupts. This day is currently full of interrupts and life is generally too short, half this article mysteriously disappeared as I was writing it, so the history of Ideal Days will stop there.
But a useful tool! Now if I estimate, today, tomorrow or next week, the number should stay the same. Abstracting the estimate helped make it a bit more stable and usable.
Alas, the trouble with Ideal Days is the Day word. People, for as long as my 25 years doing this, have confused Ideal Days with Real Days.
Enter Stage Right – Chrysler, Kent Beck, Ron Jeffries, Chet Hendrickson, Joseph Pelrine and the idea of Extreme Programming.
This is not an extreme programming blog. So I will take as given that you know the mythology of the Payroll project in Chrysler where (allegedly when zero fucks had ceased to be given) the development team, following the advice of Kent Beck, “turned all their practices up to 11” and invented “Extreme” Programming.
One of their inventions could have gone something like this:
(A film says this to try sound legitimate whilst making the best bits up)
Team does Ideal Days. Team gets bitten by Ideal Days.
Team DROPS THE TERM IDEAL DAYS, Now instead of 3 Ideal days, it’s just “3”.
The imaginary Chrysler manager (In my head they look like J Jonah Jameson from Spider-man) get confused by work that is a “3”… “Three what?”
JJJ: “Three WHAT?”
XP: “OK, how about 3… Gummi Bears?”
JJJ: “You can’t estimate in Gummi Bears! This is ridiculous!”
XP: “OK then…. Three…. Story Points.”
JJJ: ”Ah excellent. Well done.”
A unit for something so abstract it lacks a unit, is a beautiful artistic construction that alas gets into trouble the minute it hits the reality of the average team.
Teams misuse this idea of an Abstract Estimation. Common factors include: People not appreciating that this unit works only when combined with other techniques such as Relative estimating and some sort of Velocity/Yesterdays Weather.
When people do not get that, they often connect it directly back to time. 1 Point = half a day, as SAFe does. This is just using Ideal Days, with a mere fig leaf of cover-up by misnaming.
Recently, members of the Kanban movement have taken up arms against Points, to push their own approach of probabilistic forecasting Cycle Time. They have run studies showing almost no link between Cycle Time and Story Point size of the work, and they have used this to dismiss the idea entirely. I do not doubt their integrity or their work, but I do feel they have missed something critical in their judgement.
Story Points measure Effort. Some have claimed Points measure Complexity (Whatever that is) and sometimes that further abstraction is useful, but in the end it is Effort.
One Major form of Muda is Waits. This and other types will appear in Cycle Time and hugely effect the duration of the work. This isn’t a reflection on the effort estimation process, but a confusion between effort estimation and time estimation. Velocity (or whatever form of empirical measurement we are using) is what handles these factors. For me, indidivual measurement of work items and then using that to predict, will lead us back into the unpleasant situations of estimates-as-commitments that we have tried to escape over the last twenty years.
This misuse of Story Points vs Cycle Time has left some to unfairly demonise Points. Though we can learn a lot form the world of Lean, not necessarily from Probabilistic forecasting itself, but from what strategies can be adopted to make our forecasts better, whatever techniques we use.
However, I came to this article not to praise Story Points, nor to bury them, but put them in context:
The Nigel Scale and Story Points.
As you can see in previous articles*, we can see how estimation techniques can mature and decay over time. Story Points are no exception. They are clearly NOT NS1: a core practice, but whether they are NS2:“good” or NS3:“bad” is what I’d like to explore now.
In all my work on graphing practices, whether the research I’ve done via survey, or in team study, I have always wondered if there was a good practice that’s life cycle fit that of a normal distribution – That in the life of a Product Development team, it could be inappropriate, become viable then helpful, then fade into unhelpfulness on the other side.
I noted something like this with the rather dated idea of “Task Points”, which was generally regarded as an Anti-pattern, which had a small window of viability when teams were transitioning away from estimating tasks – but I have to admit I didn’t see what was staring me in the face.
Story Points have a normal distribution lifecycle.
Think to the start of this article, about that new team misusing Story Points and using them as Stealth Ideal Days. Perhaps they would have been better just starting with Ideal Days like a Scrum (or Traditional!) team from twenty years ago.
Then, as they start feeling the limits of Idea Days, (perhaps after super charging them with a technique like Planning Poker) then the team reaches a Nexus (not the .org method but a real nexus – an intersection, meeting point or union) and the team would be open to the Point method.
Then this method helps them estimate quicker and with less stress.
However, this is not the end. As our collective knowledge both deepens and widens, both social (people and their skills), process (Scrum et al), technology (codebase etc) and business (behaviours, customers etc) and becomes more cross-pollinated, then the need to have a discussion heavy, forced consensus model like Planning Poker fades – And in fact that heavy process construct holding the game together, becomes a hindrance over a help., At that point, then a lower fidelity but speedier techniques like Affinity Estimation becomes viable – Using Points as the scale.
Then as our Story Refinement improves, our stories start coalescing around a tighter, smaller range of estimates. At this point we can perhaps do away with the Story Points all together and just count the stories. The smallish variance between Story sizes not being a major factor in our planning. This #nosestimates style approach seems to be the apex of what we would like to achieve in Agile in 2022. (Though it is indeed estimating – but in a different way to classic PBI sizing) – In this approach we can stay away from faux manufacturing techniques like Probabilistic forecasting/Monte Carlo Simulations and all the baggage those Manager-led, Best practice focused Clear (in the Cynefin terminology) world of work brings.
With this in mind, for good to great teams, Story Points could be a fantastic tool to facilitate the movement from Real/Ideal Day estimating to a better future. A transition mechanism over an end state. An AgilifyING tool over an Agile one. Where points are not the destination, but actually the journey!
With a large caveat. Some/A lot/most of us are still trying to get to being good. Something like Story Points could be a somewhere where we stay for a long time. The journey is long and hard and that normal distribution is then over a sizable period of time. I am not upset by that, but I would suggest even for those of us in that situation, we would be advised to keep considering the possible better futures and coach/lead/facilitate/advice accordingly. Experience isn’t enough, we do need to keep learning and thus reflecting and adjusting accordingly.
So to conclude, Story Points are not a best practice. With that philosophy, they are a bad practice. As a contextual tool they have value, but are best thought of as a (long-term) transitional tool to a better world. A world that some of us may not reach for a while.
They are also a tool prone to misuse in elementary or beginner environments, and there we may want to begin with worse but more truthful approaches, before we evolve towards a point approach. Otherwise points become so disordered that they become…. Pointless.
So is story counting better? Well, there is an argument that all points are, is some form of “micro-counting” stories… but that is an argument for another day.
I wish I had taken some time to capture some of the intermediate states of the work before here – But I did come under time pressure due to procrastination, day job and some eye problems I have developed over the last few months.
The executive summary of the process was, I took the malformed word doc from the last article, and cut that into slides, one idea per page. I then practiced that a while until I was happy ish with the flow, then I added graphics, fonts etc. During this process, I discovered some interesting one liners, connections between topics and some stories to tell behind the ideas. I also came up with a little gimmick….
I had the idea that I could start the presentation by playing a game on a Gameboy. Tetris perhaps with it’s classic music blaring out of the conference speakers. That sounded like a fun icebreaker to start the piece and show that it falls under the overall conference theme of “humour”. I decided that I would be playing it and thus delay the start slightly… I am “playing a game after all”.
Then I used this image a couple of times during the slides – One with a digitised 8 bit version of me on the gameboy screen.. and once with an image of a heart being the target for a Bat and ball style tennis pong video game – Again playing games with my heart!
Then I realised I could turn the entire piece of theatre into the culmination of the three ideas that make up the session. I am playing an actual game, whilst also “playing games” (Not taking seriously) and “playing games” (slightly manipulating emotionally the audience with irritation) – That would make a nice cheeky epilogue to the piece!
The Gameboy idea only came to fruition less then a week before the conference – I had to source, buy and then pray that it would arrive in time… and work!
The “codex” was within the last 24 hours.
So you can see how I work on these things over the period of time like an artist. I pick it up, I have a flurry of imagination, and then put it down for a while and think about other things.
I did a rough, and off the top of my head, run through with my partner the day before, and whilst she has a healthy contempt for everything I say and do work wise – She enjoyed it.
BUT – This revealed to me a concern. I got slightly bored with the content the second I had delivered that rehersal. I have realised that I do not like being too prepared. it feels unnatural and uninteresting. I like to be more improv, more free and still interested in the words and ideas. I don’t want nicely written platitudes, stored in memory to be recalled at the right moment “spontaneously”.
So at that point I refused to rehearse except before the last hour before hand – When I went over the slides to remember the order (the conference didn’t have an easy way to have Presenter View available) and to just make some last minute notes to connect what I am saying back to Henrik’s Keynote. (A “call back” they call it in the comedy world)
I was very very happy with how it went – I ran slightly over so the last point was quicker then I would have liked, but my reading of the room was that it was enjoyable, funny, and useful.
Alas, that wasn’t totally what the feedback results said when they came back! I did have a good 50 “green” out of 60+ with some good comments:
Great energy. Metaphor was spot on!
Very, very good!
Very entertaining, could use more concrete advice
Loved it! Great analogy with games. Great analogy with Dungeon master. Great point with “spirit of the game”. Great entertainment – way to go – please continued
fun speech with some great points
Fun! But really, presenting more core ideas would be extremely interesting.
I feel less weird and lonely challenging my colleagues to think about what is core in Agile, what is useful and what is detrimental to us becoming a happy and productive team. Awesome sessions! Got lots of ideas on how to reinforce my message.
Very good to inform and tell
But there was a substantial (around 16 “yellows” but no “reds” thankfully) with feedback themed around “Interesting and funny, however a bit lightweight. Not so much content.”.
Now like most people, I paid little attention to the “green comments” but am now focussing on the yellow ones. There are a couple of factors I need to consider with these issues. One is thematic – The theme of the Agile conference stream was “humour” – And so that may have accenuated some ideas for some, but occluded some for others – “key points are covered underneath too much entertainment” – And a couple could not understand why we talked about board games and missed the lateral thinking aspect of crossing them over into what we do in real life in Scrum. So I will need to accenuate those points and bring them to the fore, rather than leave them to the end with the Nigel Scale.
Secondly, a version of this presentation is being run for Lean Agile Brighton – http://leanagilebrighton.co.uk – This audience I feel will be a far more experienced in Agile then at GOTO. So something that feels “lightweight” here will be even lighter for them. Also, the LAB session will only be 35 minutes.
So to refactor that, I think I would introduce the Nigel Scale FIRST and then make the board game examples explicit that they are Agile method anti-patterns. So sacrifice some of the storytelling narrative (show) drive for the evidence.
The problem with this, was I was trying to use Board Games as a knowable model to expose them to the patterns and the ideas of “rules vs tactics” in a different context, before bringing that back into our Agile one – so that when the Nigel Scale is revealed, they can see a model to solve some of those issues.
If I show the model first, I may then be reiterating what has already been understood. I know this is a model that is recommended for presentations – Barbara Minto with her “Start with the Answer” – so perhaps I just need to rethink the learning journey a little more. After all, whilst my ego would LOVE that the Nigel Scale is the answer… it is just a technique to get to the real answer – Better Product Development.
Finally, I will trim some of the patterns – Nerf nerfing!
I am worried that I will need to trim some of the audience “call and respond” participation – Which does give it some energy. If we go too deep into method, then the thing can become dry and disengaging. Less of a risk for a shorter session, but still a risk.
A shorter session is going to need a sharper through line. More mental experiments methinks before the end of the month!
Anyway, I hope this series of three articles has helped to understand how I approach this type of request and the thinking that goes (or doesn’t!) into it.
If you remember, I spoke in the last post about my own approach to ideas and promised to walk you through it. Well, here is the original TRIGGER and IDEA and even the start of the ROUGH SKELETON.
(For context, I just spent the last two weeks working with one of the big computer game companies, doing some Scrum workshops for one of their oldest and most famous studios.)
First, the trigger. The GOTO developer conference in Copenhagen in October. This conference has an Agile stream being led by Klaus Bucka-Lassen. He would like this stream (running over one day of about five speakers) to be sort of integrated piece, where the sessions mesh nicely and don’t all repeat content. The audience will have agile people in it, but this is a developer conference – So I instinctively felt that should be the focus of a session.
We had a shared zoom call on this, where others discussed what they would do. Some have good ideas, some of pretty much pre-structured workshops that rely on audience engagement. Henrik Kniberg will be headlining with a session on Agile Design in Game development, based on his work on Minecraft.
So, what do I do? Do I do Nigel Scale again? Yesterday, during the writing of the previous article, it was revealed to me that I already had come up with an idea for the session in the last zoom! It was:
“Safety for developers”/”Rewelding(?) Agile”
Great! Except I don’t remember anything about this. And I don’t know anything about Welding. “Safety for developers?” That is definitely not about SAFe (Scaled Agile Framework) of which is one of the worse crimes committed by methodologists to developers. I dimly remember that Kent Beck said that Extreme Programming was created to “make the world safe for developers”, and perhaps I was playing on that. But the trouble with ideas is that are like bubbles – They rise so high then fade and die. (EDIT: Thinking back after I wrote this article and did this work – I may have flippantly said that Scrum was about making the world safe FROM developers!)
I think the Welding was something to do with Dave Snowden’s “Rewilding Agile”, but that is a topic I know very little about so wouldn’t want to go there.
I start to think about how to pitch doing Scrum “properly” (A lot of developers HATE Scrum because it is misused and then used to abuse them, and I would like to fix that) – In my experience, the abuse of Scrum these days comes from not misusing the process, but by not doing jobs properly. This leads to unempowered teams, unsupported by phantom ScrumMasters, being force-fed requirements like caged geese, by business analysts. People talk constantly in these post-agile times about context and contextualism, and about the death of pre-structured frameworks – but that is often the excuse for changing the hard things that add value and change organisations for the better. This is why I have an issue with completely home-grown agile methods, they miss the hard stuff and impose the easy. Context is King. Yes, but context is also a con. Imagine coming up with your own home-grown board game? The fundamental flaws in the game itself is because you are an amateur playing games rather than a professional game designer. (https://quirkworthy.com)
How hang on – Playing games. That could be actual games. Like chess or monopoly. What happens when you play the game? What are the aim the rules? What happens when you tweak the rules? You can break the game, or have lots of unintended consequences. (e.g. Free Parking in Monopoly) Home designed games with big flaws? (Cockney Werewolf in Washington, Bake a Cake) Games which need patching cause of unexpected rule combinations (Magic The Gathering, Pokemon cards etc being deprecated or being “nerfed”) Games where strategy and tactics inside the game is good! (Catan, Ticket to Ride) yet bending the actuals rules frowned upon or worse (Games Workshop products were always like Cricket, they played best when you played with the spirit of the game. Khorne Beserkers – the blood god worshippers – shouldn’t hand back from a fight) or even breaking the rules of games (Poker and it’s scams – in real life people get shot)
Then lead it back into the value of frameworks and Scrum and this is the doorway to introduce both Nigel Scale and contextualism.
Playing games with scrum – We have a title! That has at least two meanings. “Playing Games with” i.e. “deal with someone or something in a way that lacks due seriousness or respect.”
And Playing Games with Scrum = The entire metaphor of the Board Game and it’s design.
People play games with Scrum, and that leads us into problems. Problems the players of the game (Developer et al) will suffer from!
So we can see, context, (working with game company, Henrik’s presentation on Agile Game Design, Developer conference) An idea leads to another – leads to a theme – also on a subject I enjoy!
That theme acts as an innovation catalyst to come up with this brainstorm of ideas.
I think this may have legs!
P.S. Here is the rough skeleton of this post! As it pretty much happened:
I’m speaking at a range of events over the next few months, particularly In Copenhagen and Brighton in October. Recently, I have deliberately taken a break from public speaking after spending the past 15 years constantly producing new material for nearly every global Scrum Gathering in Europe and the US. I found myself over time becoming more and more focussed on these performances (as they became) over other things – Such as children, or a life. This became even more prominent in Lockdown/COVID as the lack of travel meant I had more time with my previously absent personal life, and far more difficult speaking experiences online.
So, I paused the presentations. But I never stopped. Because the truth is…
I liked the performance part. And I miss it.
Thus, I wanted to make a hard decision to rebalance my life – I wouldn’t go through all the effort and pain of applying for the big conferences, with the loooong application processes. I’d just speak when invited. That way I do not have to spend valuable hours convincing strangers of my abilities. They know me, and they know what they are going to get.
And invited I was, to Lean Agile Brighton, and to the GOTO conference in Copenhagen.
Now. what shall I present in Brighton? In Copenhagen?
I have a fear. A fear of being repetitive. A fear of being unoriginal. I once had dinner before a conference with some fellow speakers. One was chatty and friendly and shared a range of anecdotes and ideas. It was very enjoyable. And when I watched his presentation the next day, it was filled with the same anecdotes and ideas. I realised that like a touring stand-up comedian, he had his “set” of material and that was it, He delivered that. Again and again and again. He had become that set. Even in private.
I don’t want to be that guy.
Correspondingly, I have some (I feel) moderately strong work under my belt, developed over the years. Not everyone has heard of or seen that work. (SPOILER: It’s the Nigel Scale idea that has eaten up about 25k words on this blog!) I would like to share that if I can.
But I do not want to hear “Oh, I saw this last time you did it.”
So, I am in a quandary. Do I share old but strong work? Or do I go and try and develop a new idea for these sessions?
Cause here is the problem, with new ideas. You need new ideas. That is easier said than done.
At some point in the past few years of eternal Wednesdays we have called the new world of hybrid working, I did a session for Geoff Watts’ small private cohort of trainees in one of his new ScrumMastery programmes. It was about “Giving Impactful Presentations” and in the best example of irony since Alanis Morrisette wrote a song about irony containing zero examples of irony, the actual presentation was not impactful. And was more about the subtitle: “and Being Creative in General”.
This blog post was going to be about playing with a new idea I’ve had for a presentation. But it’s evolved.
It’s going to be about my creative process. I am going to TRY and explain it (ish) and then I am going to TRY and show how it’s used to develop up a new presentation for October. If it goes super quiet, you will know I have failed – Be prepared to watch me give an old presentation in October!
So. Let’s pull out from this presentation the key points in my own creative process and then I will apply it. PLEEEEASE wish me luck. This is like practicing tightrope walking in front of an audience – with no ability to rope walk, tight or otherwise.
My creative process starts with a trigger. Something (or someone) sets me off. I see or have a need for something:
It could be as naff as a deadline for a conference submission, or a discussion on Linkedin. Or some piece of media unconnected with Agile entirely…. Until it hits my brain.
I am a huge fan of Edward De Bono’s Lateral Thinking approach, one of which is taking two perhaps unconnected items and finding unexpected patterns of connectivity between them. Or Provocation idea generation, where one uses something wrong or impossible to create new ideas.
I have used this approach on many presentations – Both deliberately and unconsciously. Why? (Another DeBono approach called “Challenge” BTW)
Because I am a knowledge magpie. I pick things up. I pick up phrases, little bits of language, ideas, media. My brain records these and I often fuse ideas/phrases in new terms. I have historically been a bit of a information dustbin and thus very, very good at Pub Quizzes. It’s just who I am. It’s why I often make lots of bad puns. Because my brain sees some weird pattern between two odd things and connects it together, and it comes out my mouth before I can control myself. (EDITOR: Nigel, you may want to rephrase that)
So, to give some real life examples: I was once asked to do a presentation at the Agile Cymru conference, but didn’t have an idea on what to do. The conference organizer James Scrimshire, said he would put me down as “TBC” – To Be Confirmed. And that got my brain firing! I instantly picked that as my topic. TBC! TBA! Uncertainty! And I used that as the driving idea behind the entire presentation.
Or one of my earlier conference workshops (2012) was based around the idea of fusing the (still very commonly mis-used) word of Transformation… with Transformers, the 1984-current toy line from Hasbro and Takara. This method helped me discover (quite quickly) patterns and lots of anti-patterns in organizational change. If you browse my previous blog posts, you may even see some traces of this work today.
This helps catalyze or even create an idea in my head. This fusion excites and motivates me. I have no idea where it will take me, but it seems to be a world full of new and interesting and I like that!
Then I need to take the idea and build a rough skeleton. This is mostly one word per slide in some slide deck. And for me, I need to Scrum the idea. I iterate, iterate and iterate. I add in ideas into this rough flow, I amend some, I delete some. They are still just a couple of words per slide. Then gradually, I add more and more verbiage on the slide. This is all for me as a crutch. As the workshop evolves, words will disappear again as I remember and understand what it is I am trying to say. It will sometimes evolve purely into an image. Capturing the essence of the point. I will only make it presentable at the end. The amount of time I have defines how pretty and simple the slides are. If I have had a long time, they may be almost Presentation Zen in style:
BUT Iteration without Delivery is Inventory. – I prefer to run it at least once, before hand with a smaller audience like an Agile User Group. I find twice is best. After that I start getting stale/bored. The joy I get from the new idea is still a joy and hasn’t become “known”, so I bring that joy to the workshop.
Now, I do put a lot of hours in normally. Not necessarily Keyboard Hours, but Thinking Hours. I think about it all the time. Specifically, I rehearse in my head and if something comes to me, I add it in. Not just the content, but the movement between content.
And I try and find the story within the subject. What is the journey this presentation (and indeed me!) is on? What is the Beginning – Middle – End? Or to be all theatre for a minute, – What is Act 1 – Act 2 – Act 3? They say people remember the start and the end, (Primacy and Recency Effect- https://www.simplypsychology.org/primacy-recency.html) so what impact do I need to make there? What is the key Narrative thread I am taking them on? Is there a TWIST? (I love a twist but have only made it work once or twice. Most the time I feel it just looks a little over clever.) Don’t forget Chekhov’s Gun. You mention something in act one, you better make use of it in Act 3! The author of Game Of Thrones: GRR Martin, has said there is two types of writers – Gardeners vs Architects. Architects plan everything up front and that drives the characters forward – This can end up with characters doing incongruous or just plain odd things to make the plot progress. Gardeners evolve and emerge the story over time. They discover it as they write. I think I am more of a gardener. The plot emerges. The characters are authentic, but perhaps the writing can go off into a dead-end if one is not careful. (For more information on this, please study GRRM’s own issue with the Meereenese Knot: https://awoiaf.westeros.org/index.php/Meereenese_knot – and the fact we have been waiting over a decade for the next book in his ASOIAF series)
In my own life, I started preparing a presentation for a Scrum Gathering conference crossing over the idea of Change Agent with Secret Agent – 007 meets Agile Organisational Change! It seemed fun and interesting, but then COVID killed it before it could be developed to any depth. When I thought of reusing it in my COVID era Video Podcast (Purely created to fill my time with something creative during the lockdown when I had zero work) as a presentation to a User Group. I found the work didn’t really lead anywhere interesting. Perhaps with further development it may? But I will never know.
So to conclude, there was more than this in the original presentation… err presentation. But I don’t want to digress into things such as stagecraft, humour, props, improv etc. As that is getting in the depths of the craft of delivery more than the creation process. I may visit this later if needs must.
The next part is going to be the actual idea and its inception through to the initial rough skeleton. And I will let you in on a secret, straight away. The idea has changed during the writing of this very article! This piece pivoted from content to creativity, and the new second part has pivoted on content! There maybe even be a third part… but we will have to wait and see.
TIme flies! I cannot believe it has been nearly a year since I updated this blog. It’s been an interesting time, as whilst AgileBear was quiet in the first six months of the year – I was not. I had two big goals over that time – One that was a natural successor of the other.
Firstly, The ScrumAlliance had it’s periodical ritual sacrifice of it’s leader, (This is a joke but only partially so), and was looking for a new CEO. With the current situation the ScrumAlliance is in, and with a clear idea of the direction it needs to head to stay relevant – I put my name forward for the position.
As will soon become clear, I do like to overthink things, and so as part of that application, I put together a deck containing my ideas of the problems, possible solutions, and probable approaches to those solutions.
I felt I was in a strong position for a few reasons. One, very few people have the depth of experience I have had with the Alliance since it’s early days. I understand deeply the prior and current context of why the Alliance is how it is. I have a strong relationship with many of the staff – especially the leadership figures, and I had a strong vision of where the non-profit needs to go next. Thought Leadership being the achilles heel of the SA up until this point. Why? Because as a community-led organisation, it doesn’t have a singular heroic figurehead (A good thing, if you ask me) but relies on a consensual group approach to creating products. Great for the creation process but not neccessaily for the intitial ideas. I was sure my strong relationships across the entire guide-level and beyond community would stand me in good stead.
I was wrong. I was paper-sifted fairly promptly, because I have not run a large non-profit before. The fact that the board and headhunters feel that is a key skill for the new CEO tells us a lot about the future potential direction of the community. At the moment of writing, the ScrumAlliance has still not found a CEO. Whether from a non-profit or not.
The ScrumAlliance did hold out a fig-leaf of another possible role – A sort of inbetween liaision between guides and the alliance. I am not a PR person, so I didn’t think that position as being right for me, or indeed for anyone. As we know, a bad system defeats a good person every time. That looks to me like a bad system design choice. I am unaware if they are still progressing that idea.
So I am left with a big bag of great ideas, a great reluctance to hand them over to the Alliance for free to be misused or ignored, and a worry about the future direction of the Agile movement.
The AGILE MOVEMENT in 2022.
Lets broaden our view for the moment, and take a high level look at the Agile Movement. TM symbol.
We have a range of fiefdoms. We have the RUP inspired SAFe business, generating millions of dollars in profit for their faceless venture capital owners. Absorbing and misusing any ideas, old or new, from the Agile world of work. Like the Borg from Star Trek, leaving devastation and ruin in all companies within it’s grasp. (Editor: Nigel, don’t you feel this is a little judgemental and overly florid? Nigel: No.)
This is now the big dog in the world of Agile. Your work will be dillited and defiled by this big blue machine.
Then we have the Non-Profits. AgileAlliance and ScrumAlliance. Both built with the right intentions, yet floundering without direction. The certification model has given the ScrumAlliance a huge treasure chest that it does not use, the AgileAlliance is in perilous state, surviving purely due to it’s one revenue stream – It’s large in person conference. Agile202X.
Then we have the the smaller for-profit businesses led by the creators of Scrum. Scrum.org and Scrum Inc. Both keeping true to the word of Scrum, possibly. But very insular and very foccused on transforming the world of Jeff and Ken. Wealthy me, ready to retire. And when they do, what is left? Indeed what new innovations are coming out of either person?
IcAgile: I’m afraid to comment, beyond the rumours around issues of how IP is managed and owned causes me great concern.
Then we have a dozens to hundreds of nascent Agile communities. Small businesses, small co-ops, individual inventors, with their huge pool of ideas that never get the exposure or traction to really take-off. And if they do, the inventor gets quickly forgotten as their work is “adapted” by others.
Apart, those dozens of individuals will never do the great things they could do.
So lets bring them together.
The Agile Licensing Library
We are creating a new creator-led licensing body in Agile to: Allow agile trainers and coaches to quickly access high quality industry-leading material. Allow the next generation of world-leading training and coaching creators to share their ideas and learning in a fair and rewarded fashion. Allow these world leaders and licensees to work together and lift each other with a shared collective brand. To do this under recognised licensing and certification models, mutually beneficial for everyone involved – Including creators.
Join a community of creators where we can build a better agile world. • We want creators to bring valuable content to the wider world of work. • Using this shared repository to massively accelerate the time-to-market on ideas and methods, and catalyse its growth throughout the agile network. • This sharing of your agile resources allows you to earn money and add value each time they are licensed and used. • Allows creators to create without losing control of their creation. Each creator has full ownership of their content whilst being able to share appropriately. The content is always yours!
Coaches, Trainers and Leaders!
Gain access to a whole new world of industry- leading licensed content authored by the greatest agile minds. • Agile Licensing Library is a cornucopia of learning and ideas. From the concepts of intellectual property through material such as graphics and canvasses through actual slideware and even courseware such as handouts, exercises, simulations up to examination, certification and even train-the-trainer mentoring programmes. ALL available for you! • Whether to add something new to your repertoire or to sharpen your classic material, the library covers ALL subjects in the agile eco- system for you to train and coach.
But, never take your eyes from the prize of changing the world of work for the better. • The consumers of these products will be the true test of success. The practitioners in the organisations themselves. The End User? We like to call them the End Learner! • Whether expanding one’s knowledge for its own sake • Or gaining practical advice to advance your own world of work. • Or even verification, licensing and certification of ability. • We are giving learners more options and opportunities to build ability and capability.
The idea behind the Agile Licensing Library is being about ALL of us. It is not an organisation to replace or supercede what came before, but to compliment the current agile bodies and help catalyse new innovations and facilitate it getting into real peoples hands quicker and with higher quality then ever before.
So if you are a possible creator, give us a shout at https://agilelicensinglibrary.com – We can even assist you in taking your nascent idea to the next step with our special “Build-a-program” offering.
If you like the idea of licensing Geoff’s work, or Gunther Verheyen’s (also available) or any of the others who are soon coming (Esther Derby, Andrea Tominsini, etc) then also drop us a mail and we can talk you through.
So, this is what I and Paul Goddard have been spending a LOT of time on this year… and we are looking forward to spending even more! Because, time flies… and the Agile movement keeps moving. And if we do not all stay on top of that, it could move further in a direction we do not like!
I received a little request at the weekend. Someone was watching my old Youtube video on Splitting User Stories:
In that video, I was commenting on the risk of one type of story spitting being overused. That of “Spikes”. They requested a little more detail on that risk.
“Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away.”
The aim of the Spike is learning. Why would I be concerned with learning?
Well, my worry with spiking is not the technique, but the overuse of it. Overspiking is something I see relatively often.
Why do some teams overspike?
Let’s visit that quote at extremeprogramming.org again and look at the follow-on sentence.
“The goal is reducing the risk of a technical problem or increase the reliability of a user story’s estimate.“
That second part is the first problem. I see these teams being almost frightened to misjudge an estimate. So they Spike to effectively pseudo-code the solution during spiking, removing the uncertainty in the work.
What’s going wrong, isn’t the spiking – That’s just a symptom of the underlying cause, which is the treating of estimates as somehow a guarantee or commitment to a delivery date or size. We should all know that in the inherent complexity of software development, that there is a natural variation in work we do and too many outside forces influencing it be truly sure. This is why things like Scrum use the term “forecast”, because like the weather – It can change in a second. If a team is also using User Stories (also from Extreme Programming) then we need to be aware that this method has a natural uncertainty built in as well. That investigation is an integral part of the User Story concept wrapped into the internals of the approach. (See https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/)
I can understand though, that most “Agile Organisations” are not. And this pressure on one of the few metrics Agile teams may produce, is likely to occur, and likely to be abused.
We want to avoid this, because it will probably cost more in the long run. Spike X + Story Y = Z. There is a good chance that by simply integrating that investigation into the story, then by removing that throwaway code the actual work maybe Y or even smaller.
There are other reasons why overspiking can be occuring though. If you watch the video (Don’t worry – I’ll wait!) then you can see I adopted a rather naff straw hat to pretend to be….
Archaeologyor Tomb Raiding
Some of us have large and old products. Legacy they are euphemistically called. Often these behemoths are riddled with poorly written and documented code and features. Sometimes, it’s as simple as the knowledge about the system and it’s workings has passed out of the organisations mind. People are retired. Or left. Or been left and retired. Now the Product, which was probably constructed with lots of sensible decisions and ideas over time, but the collective gestalt of those sensible decisions and ideas is something far far more… more then they ever could have imagined. And now a load of new people have to try and imagine that entire context.
Painful. In that context, no one has a good idea what is going on, so everyone is spiking to try and experiment and discover how things work around here.
Have you ever seen a horror film, where the young and innocent (well one of them) teenagers venture into the ruins of the cold, dark abandoned house/hotel/castle/woods and one volunteers the idea “Hey, let’s split up!”
This is never a good idea. Unless you are the monster/killer/killer monster inside the aforementioned property.
But as an innocent developerImeanteenager, this is a quick way to die.
So, don’t do it. Don’t enter that cube of chaos on your own. Stick together.
Pairing and Mobbing are two powerful ways for a team to survive that Deathtrap Dungeon.
The final reason for overspiking I see, is some teams are not aware of alternatives.
Spike your Spikes?
Spikes are just one way to gain learning. Via experimenting with code. There are many other approaches we could run to gather that learning.
It maybe there is a need for some customer interviews. Or surveys to gather data to reduce uncertainty on the WHAT and WHY of the solution. It could be looking at the analytics or even the discussion forums. There are a range of methods to help us understand more and learn. Spikes tend to work well for the HOW. But we have lots of others for WHAT. In real life those two often blur together more then we would like to admit!
Short and sharp. Like a good Spike, this blog post is over. What do you think? When do you see overspiking and what root causes do think led to it? Or do you believe there is no such thing as overspiking? I’d love to hear from you.
I regret anyone who would hold me in high esteem, a man who cannot limit himself when it comes to opinions or food. My oldest friends may admit that I am withering soul on occasion. And that occasion comes frequently.
But if one is to be the type that withers. One that continuously delivers snark, then I feel one has to have some base rules to what they snark on. The snark must be clever. An angle unspotted by others, The snark must be logical. It must be derivable by more than just the snarker when heard, And the snark should contain a dash of truth. If one is a politician, you want a lot of truth, if one is a comedian, then perhaps a bit less.
Sometimes people snark in a way that is just cruel, rude and false. I don’t like this. I would like to say it’s because my White Knight nature – dashing to the rescue, or perhaps because of my English deeply embedded sense of manners.
But likely it is because I am a developer at heart and I HATE errors in logic.
I have come across a big piece of Snarkware, and it does not compile.
A simple website of a few pages, badmouthing the ScrumAlliance (https://www.scrumalliance.org) the largest and most successful Agile non-profit certification organisation till now.
Now badmouthing bad agile is not new. I am a huge fan of some work done by an old colleague of mine Kerry Buckley, based off of some snarky content produced by one of the authors of the Agile Manifesto, Ron Jeffries.
The Half Arsed Agile Manifesto (or HAAM for short) is a good piece of parody, mocking those large companies that abuse the principles and practices of Agility. It rings true for many of us, who have seen similar patterns in our own old businesses.
So what differs the scrumsalliance.org from this? The HAAM is mocking misuse of agile ideas. The Scrumsalliance is attacking a particular group of people.
The scrumsalliance is attacking the very morals and integrity of thousands of people. Claiming that the SA is a commerical entity without morals:
“Your business has been ignoring the challenges of making significant improvements for years. Maybe even decades. Now your bosses have learned about the word Agile and you need to act…NOW. We can help. The fastest way to seem Agile without the risk of improvement is the Scrums Alliance certification ladder. Legitimize your people.”
Claiming that it is all about money generation:
“You want to keep the same training budget next year right? We can help you spend, and then spend some more. Our certificates have certificates!”
BTW the ScrumAlliance is a non-profit.
Claiming that what is offered by this alliance is mere theatre with no real change:
“Your board members expect a lot. A now you can claim amazing achievement by changing job titles and renaming meetings. Shit that’s impressive!”
And for me, two ideas that show a bigger problem. A lack of understanding of Scrum and Agile.
Increase Group Think: My logic alarm goes off with this statement. Does the author think education is bad or wrong? Do they wish their colleagues to not learn? Are they worried about learning shared amongst all? Or are they claiming that the ScrumAlliance offers some form of unchanging and inflexible content that leads to unchanging or inflexible mindsets in their education packages?
The ScrumAlliance actually does something that very few other Agile certification bodies do. It does not prescribe* content. Slides, images, verbage. No. The SA actually sets Learning Objectives:
“Upon successful validation of the CSM Learning Objectives, the learner will be able to demonstrate at least three techniques for facilitating group decision making.”
Thus the trainer or coach can adopt whatever approach or technique they feel is proper to achieve that result. The ScrumAlliance acts as the quality check to ensure that the trainer has material and the skill to do that.
So already we have a challenge to this “group think” idea – Methods and approaches will vary.
But perhaps the discovery at the end will be the same, Cloned certificates!
No, because the LO model does not even say what the attendee should learn. It lists what they should be capable of. And that varies trainer to trainer. Coach to coach. The exact opposite of this point.
These Learning Objectives are built by teams of expert volunteers from across the Agile community to ensure we can educate people into NOT building Agile theatre but in fact real change.
There are Agile certification models that enforce content, slideware, verbage. But that is not the ScrumAlliance. Has the creator of this website confused their Agile organisations? There are businesses that like to maximise profit (like mine, http://www.agilebear.com) but if no one gets value from the learning, the budget disappears – and so does the profit. Anyone with any business sense knows that satisfying the customer and the consumer is essential to have return business. Customers are people and people are not stupid, unlike how they are portrayed by this parody. And secondly, AgileBear is not the ScrumAlliance. Has the creator of this website confused the ScrumAlliance with other private training businesses? Would the ScrumAlliance have reached such a large membership by making their consumers unhappy?
That’s not Scrum! What do you think the point of this image is? I am assuming it is meant in a projarative way. That somehow the victim is being oppressed by someone over a framework.
This does exist as a problem in the industry. But perhaps not in the way this author thinks. Forcing Scrum onto teams is an anti-pattern. Forcing anything onto anyone is an anti-pattern. My kids will not eat certain vegetables, no matter how much we push. This is why Scrum contains very specifically a job to help the team do Scrum well. The ScrumMaster. A role who serves the team. A person who coaches and facilitates. Not a policeman, as people will just hide their crimes. But a priestly figure to support and hear the problems. “Love the sinner, hate the sin.” This is what the ScrumAlliance advocates because this is what Scrum advocates.
So what’s going wrong? Is some business not doing that? Then they are breaking the rules of Scrum when doing so. Has the creator of this website confused the game with the players? If you cheat at monopoly, there is not much Hasbro can do about that, beyond publish warnings:
“Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.”
Scrum Guide 2020. Authors Ken Schwaber and Jeff Sutherland.
Or is this complaining about Scrum being inflexible? Being too controlling and limited?
“The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”
There is a logical flaw here. If Scrum is being imposed then they are breaking the rules of Scrum. The immutable part has much weight as the rest that is being ignored. If the immutable part is being followed, then Scrum won’t be imposed or enforced. Because we are doing Scrum-as-a-whole-thing. Scrum is not just the Framework. It is the framework, values AND Accountabilities/roles/jobs.
So either the author has gotten themselves in a logical traffic jam – Or they don’t understand what Scrum is. Has the creator of this website confused their Scrum? Or confused the abuser with the abused?
Or do they mean something as trite as HOW things are done? Scrum as implemented in a team has great contextual variety. Scrum itself has a very light rulebook. Most of what people fill their product development is with things that are not Scrum…
As many will know, I have some philisophical differences with Jeff Sutherland. Both from a Scrum and a private business point of view. I disagree with some of his outside of Scrum personal beliefs. But that does not mean one can mock any person by sticking their head onto some clipart to abuse them personally. It is disgusting, and anyone who thought it was “good fun” or “that’s fine work” should be ashamed of themselves.
“The best part about defining an intentionally incomplete framework with an official guide is that it’s OFFICIAL! So we can say you aren’t doing Scrums if it not part of the guide. But…and this is where it gets totally AWESOME…it’s intentionally incomplete! So you HAVE to do stuff that’s NOT in it to even have a chance of making it work!”
Methinks someone doesn’t get Agile at all. The entire point of the entire Agile movement was that there is no one ideal way of producing software. That one must be empowered to empirically inspect and adapt, evolving both the product and the processes and practices associated with it. They also do not understand Scrum: Scrum, like Kanban, regards itself as an improvement process a method to inspect and adapt your methods. Not the method itself.
This incompleteness, is giving people space to fill it with content that is appropriate for their needs. The reason why Scrum is regarded as needing to be rigious is that it is a MVP of product development. You may need more, but you will struggle to get away with less. You need the trellis to support the plant. The flexibility each team has is how much detail and discipline they need around the handful of patterns that make up Scrum. How wide and strong you make the trellis is a team decision.
Again, the author seems to be running into a contradiction. If they are saying Scrum does not provide the answers needed, unlike an alternative – Well the alternative can only be Extreme Programming. The only true Agile software devleopment methodology.
However, the first line is complaining about being made to do things in Scrum they do not want. The problem here is XP would have exactly the same issue. It contains all the Scrum patterns and more. So are they arguing for Kanban? That would fail the first “we want answers” test. What is left? Devops? It’s not a comparable thing to Scrum. It’s more a philosophy that you achieve with methods like Scrum or Kanban or XP.
So the author is again caught in a bit of a trap here of their own devising.
Basically, some practioners confuse core fundamental practice with contextual good practices maybe used. Scrum is only made up of those core patterns.
“Years of Scrums Alliance research has shown that attempting to measure success based on actual business value or customer outcomes is…well…really hard. Therefore it has been deemed best practice to make up an indirect measure of myopic productivity using a fictitious unit. This way you can control what success is and how much you get!”
The ScrumAlliance has not done that research. That’s a lie. The ScrumAlliance has not made up an “indirect measure of myopic productivity using a fictitious unit.” or even deemed it best practice. That is Story Points and was invented by the first Extreme Programming team in Chrysler. That is a lie.
Scrum does not contain the concept of Story Points, It is not part of Scrum.
Whether it is a good practice (NS2) or bad practice (NS3) is still up for debate. It has shifted from being super popular over the years, and I am not here to discuss it (though we can because like earlier – The problem with it, is people abusing the name and not using it as meant) The fact is this line is just untrue. A lie upon a lie upon a lie upon a subject of debate. Abusing points is a problem in enterprises. Has the creator of this website confused their XP with their Scrum? Confused the non-profit, community-led ScrumAlliance with private businesses like Scrum Inc that do use points in controversial ways? Or confused the law breakers with the laws?
“When no one can align on value, it’s better to just be really really really busy. Like, no less than 387% utilized. Seriously, do you want to get laid off or something? Plus, if you’re triple booked almost every hour of the day people will start thinking you’re super important. Promotion baby! Extra points for expecting everyone else to do the same, working after dinner, and responding to emails while on vacation.”
Being busy over output or outcomes.
This has nothing to do with the ScrumAlliance. Nothing. The Alliance has never done anything remotely like this, or recommended anything like this. The alliance has published articles on Sustainable Pace, and it is a part of the core LO’s of Scrum. So no trainer can be either.
The SA supports Scrum which has deliberate “BusyBreakers” in built to stop people pushing work into teams (Sprint, ScrumMaster) or pushing work into Sprints (Sprint Planning) and emsuring teams only pull what they can accomodate as a team (Sprint planning).
Scrums Is Like Training Wheels
“Are you seriously trying to kill a CHILD?!? You MONSTER!!! Don’t you know that code craft, devops, and kanban are WAYYYY too complicated for the ickle wickle bebies on your team? Their tiny team-member brains will literally EXPLODE! Don’t go confusing them. Be safe, start with Scrums.”
Scrum is not stabilisers. Scrum does not stop you failing. It is not training wheels. Scrum makes failing cheap and safe. Scrum is actually a balance bike. Codecraft, kanban, devops all great ideas – but kanban is a bit more like putting stabilizers on your bike you are already riding – “start where you are now” – and then changing the frame in transit. Codecraft and devops are like road laws and cycling proficiency. Same world but different things. Comparing these things like-to-like is strange. The baby language was an interesting choice. Exaggeration for comic effect normally works. Normally.
And then we finish with a page of made up Agile certificates that are thin carbon copy parodies of the ScrumAlliance’s three entry-level certifications. The humour here seems to be “pay money” and “sit through two days” – Though he does mention the examination needed. This is where the author hits home. The three certificates seem to be entry level. Barely enough content to align with a term at University (16+hrs each). How can you claim they’ve reached the top of the education ladder????!?
Of course reader, you can sniff my sarcasm. (Please don’t tell the wife). These are three of at least sixteen levels of assessment and resultant qualification one can achieve with the ScrumAlliance. But the author did not want you to know that. (Or perhaps they didn’t know themselves.)
To achieve the higher levels requires a little money, but far more importantly, a lot of effort and time documenting your learning, your journey, and alll the associated skills, people and organisations you have helped.
I passed my GCSE’s at 16. I was not a professional. But my learning wasn’t over.
I passed my A Level’s at 18. I was not a professional. But my learning wasn’t over.
I read for my Computer Science degree at 21. I was not a professional. But my learning wasn’t over.
I have done dozens of courses, taught hundreds, worked in companies all over the world on the coolest (and most boring) things you could imagine. I’ve coached everyone everywhere. I’ve seen things you people wouldn’t believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate. All those moments will be lost in time, like tears in rain. I am a professional. But my learning isn’t over.
There maybe organiations that only deal with entry level learning. But the ScrumAlliance is not them. There maybe businesses only focussed on the quick buck, but the ScrumAlliance is not them. There maybe authoritarian organisations forcing it’s members down one route, in only one way. But the ScrumAlliance is not one of them.
The ScrumAlliance is a bit shit sometimes. They are slow to react to members needs. They still don’t have a strongly endorsed scaling approach. The website has been a bit rubbish for years. As a member-led organisation, it can sometimes feel like committees and committees. Not enough members volunteer.
But none of that was mentioned. The author shot their mouth off, revealing their own incompetence and ignorance and missing the possible targets it could be aiming at. Such as Scrum Inc mixing certification programmes and a private business whilst also pushing Story Points as a measure of success. Or Scrum.org and Scaled Agile requiring slidware and content and allegedly even anecdotes.
If you want successful certification snark – Then look to this video:
The abusers will keep abusing and we must expose and ridicule them. The ScrumAlliance is not one of them. And neither is Scrum.
This parody seems to constantly confuse itself with self-contradicting complaints. Scrum is too strict. Scrum is too soft. Scrum is too detailed. Scrum is not detailed enough. Scrum is the ScrumAlliance which is also Scrum Inc and every private training company out there. Oh and throw the Scrum Guide in there as well. A positively pot-pourri of bitchiness.
So back to my rules on snark. Clever + logical + true (from a certain point of view)
The parody site fails all three tests. And has a look and feel that maybe putting itself a little close to the legal world… For the ScrumAlliance does have budget for lawyers, and it does use them.
EDIT: September 13th! Well, this post upset some people. Their counter argument was made and the response was I am a virgin and I cannot spell. Strong argument. 🙂
*In terms of spelling, I have popped back and corrected a few. (This was thrown together in about ten minutes.) I notice a particular snide dig at me accidentally using proscribe when I meant prescribe. Thinking about this, I may have been (accidentally) correct first time. I don’t think the ScrumAlliance proscribes material either. It assesses the Trainer and their Agile and Scrum Knowledge, and their experience – And lets them make the choice of material and method (within the LO guidelines) – So I’d like to thank the impolite author, through whose attempt to avoid refuting anything and instead making ad hominem attacks, has opened my eyes to another advantage of the ScrumAlliance.
This subject has arisen many times over the last twenty years. It has recently popped up again when Jeff Sutherland, proclaimed “inventor” of Scrum said this:
Frankly, there is a lot to decompress in that statement – Red flags all over the place – But I want to dig into just the first part of the statement. “The Scrum Master job was designed to be a half time job.”
If it was “designed” as such, someone should tell the other “inventor” of Scrum. Ken Schwaber. In his original and seminal book on Scrum “Agile Software Development with Scrum” he says that “The ScrumMaster is a new management role” often assumed by “The Project Leader, Project Manager or Team Lead”. If there are many impediments “this position may need to be filled by a senior manager.”
Sutherland also claims that “The original model for the Scrum Master was Takeuchi and Nonaka’s organizational catalyst that manages up and down in HBR New New Product Development Game. Also on Taiichi Ohno’s facilitative leader who develops the cross functional team, can do all tasks that anyone on the team can do, and can help the team be successful in every way.”
If you would like to read the “New New Product Development Game” it says no such things about the leaders of the approach being able to do all tasks. The entire point of the “rugby” metaphor is overlapping skills in a cross-functional, autonomous team. A heroic leader that can do it all runs counter to that philosophy. Taiichi Ohno’s facilitative leader work is not commonly regarded as a source of ScrumMaster, and like OODA is not mentioned in any early Scrum writings.
So I believe there has been some post rationalising by Sutherland on ScrumMaster as a part-time role. And if you read the rest of the original post – You can see even he has stepped back from that in his own business. But not in a way that I would… But I digress.
So how I would I answer the question “Is ScrumMaster a full-time role”?
My answer is “Yes, in most settings we encounter” (I’ll handle exceptions at the end.)
Since this is an age-old argument, I will revist some classic points:
Do the people arguing against Full-Time ScrumMastery understand what an ScrumMaster does?
E.g. There was an example of someone doing Business Analysis as well as being a ScrumMaster to demonstrate the role was part-time.
However, those of us with a deeper understanding of Scrum, know that ScrumMaster’s work the backlog. It is part of their job. Assisting the Product Owner and assisting the team. I regard that as just part of the ScrumMaster job, if needed.
I said many years ago that “Between theory and reality is ambiguity – And that is where the ScrumMaster lives.” So this example strikes me as classic misunderstanding around the three services of ScrumMastery. Serve the Team, Serve the Product Owner and “Serve the Organisation.” (BTW like a therapist serves a problem drinker – not how a bartender does.) Most PT/SM ScrumMastery suggestions or examples are when people think the ScrumMaster only “facilitates” the events in Scrum. A simple error.
I also believe Jeff Sutherland may not fully understand what a ScrumMaster does. Or, to be polite, I believe that he has imagined other mechanisms and methods to mean the SM does not need to do much on the “serve the org” theme.
Because the organisations he envisions are capital A “Agile”. Or because the surrounding management is fully Agile in mindset… and probably following his other marketed approaches. I believe this comes from his experience as a C-level person (ish) talking with higher level executives and coaches. Things look great as a honoured guest from 50,000 feet. Stripping away the nuance, this is an example of another simple error. The idea that once a business is in some imagined “agile” state, that everything is a wonderful, blissful, (probably static) state. In reality, humans human. Two’s company, Three’s an organisational structure. This is another example of “ed” thinking rather than “ing”
All organisations are in flux, especially “Agile” ones. That state of change means that the “service to the organisation” aspect of the the ScrumMaster role will perpetuate over time rather than dissipate.
Finally his statement of ScrumMasters taking on managerial responsibility in an organisation without managers is… odd. I do not want to break that apart further, but if we are kind it sounds like his ScrumMasters are doing.. proper Scrummastery! If we look at it unkindly, it sounds like his managerless company now has managers. Nothing wrong with managers, but he shouldn’t be using the ScrumMaster term so loosely. And if we were super-unkind, it could sound like he is breaking the very principles he asks others to exhibit. Pretending a Product Development Framework is a universal pancea or solution does no one credit.
However, this is an aside! Let us get back to part-time.
What does “full-time/part-time” actually mean?
Was Sean Connery a full-time actor? Did he need to act 8 hours a day for 300 days a year to add value to the films he was in?
Should Firefighters be full-time? – In the UK firefighters are mostly full-time jobs. Why? They aren’t putting out fires for 24 hours a day! Most the day they sit round flirting with women walking past their station and playing football. (I used to work next door to a firestation and they did these two things ALL DAY) But when the bell rings, they are focussed and quick. Because fires are all about cycle time. The quicker to the site, the smaller the fire. The less death and destruction. Imagine ringing 911/999 and being stuck in a queue. “Thank you for calling the fire department, your call will be answered shortly. You are number 73 in the queue. I am sorry we are delayed answerting your call. Here is some music… “ Their key metric is “Trouble to resolve”. How quick can I react? How quick can we fix this issue.
Should Surgeons be full time? There is an aspect of professionalism. “Hi, today I’ll be playing the role of your surgeon. Normally, I’m a waiter, but today I will be removing your spleen..” We can all play at anything. But in serious settings with serious results, you want craft. Skill. Ability. You want this professionalism to be professional.
Time and Space are critical factors in a CHANGE AGENTS role. If you are busy, you cannot take time to think. If you are busy, you don’t have time to try. You cannot experiment. You have no space for a second round. ScrumMasters must be TIMELORDS. One way, or another.
There is a legacy of the factories left in this conversation. The working on a task as the only type of justifiable work.
Back to actors. Actors, Writers, creatives are often asked “Where do you get your ideas from?” They come from the synergy of imagination and the world. The imagined and the reality. Thus, creatives experience the world as part of the “creative process”. This should be true of creative teams, (You probably now call them “developers” which shows the utter limitation in Schwaber and Sutherlands thinking) and the people leading them. I would say the aim is dedicated or not-dedicated. That is the real distinction. Sean Connery was a dedicated actor. He read widely about his craft. Firefighters are dedicated. They will die for you. Surgeons are dedicated. Cause you will die for them! To have that dedication requires respect to the craft. To respect the craft requires time and space.
Now, why does everyone WANT it to be part-time?
No extra cost. Developer now does this as part of their dev work as well. 2 resources for the price of one!
No change needed to management. Status Quo plays on. “Don’t you rock MY boat.”
Thus, no change anywhere. The team empowerment is highly limited or non-existent. Zero change is the easiest change. Agile Theatre? More like Agile Mime.
Allows Agile Coaches to float between these two stable and static worlds and justify their roles (The coaches lead “the change”) in a tacit agreement with management or just be periodically cycled out on short term contracts.
But I feel again I may have gone too far. Suffice to say, the issue with SM as a JOB rather than a hat is a condition that is hugely affected by the context and surrounding forces being applied to it.
Caveats! Where would I not have it full-time? If the work itself is minor or “part-time”. In a hobby setting, people can play at ScrumMastery. I can also imagine situations where the business-side is so wonderful and elegant (or small) that the change agency and business aspect is minor. I think this can apply in some Start-Up settings, but not any I have actually seen in reality. I think this is where Sutherland is trying to stretch Scrum into. And most of these idealised Unicorns seem to me just to be painted horses with a plastic horn pasted to their heads, defecating everywhere with the tech glitterati proclaiming it all paradigm shifting.
Again, I go too far. But not far enough perhaps.
So to wrap up as my kids need feeding.
WRONG + NO SPACE + NO TIME = Part-Time ScrumMasters which leads to BAD SCRUM and WORSE PRODUCTS and FAILING COMPANIES
The answer is:
KNOWLEDGE + SPACE + TIME + RESPECT = Dedicated professional ScrumMasters which leads to BETTER SCRUM which leads to BETTER PRODUCTS and thus LESS BAD COMPANIES.
I was recently asked “How do you change organisations?”.
*LONG PUFF OF CHEEKS*
How. Do. You. Change. Organisations. ?
Intuivitively, I know what I do when I work to help change organisations… but can I:
Write that down?
Write that down in a clear and useful manner?
Write that down in a clear and useful manner that is intellectually coherent and can stand critique with evidence and referenced examples?
I had planned* to do 3. I then descoped towards 2, and I am now rapidly heading past 1 to 0.
0. Sketch out ideas and concepts in a haphazard style.
So, I am afraid to say this post is going to float around the world of 0.
“The right tool for the right job”
As you will know, I have spoken at conferences about Agile Organisational Change since 2007. There has been some ups, lots of downs, and an evolution in both what I believe, what I see in industry and what the community generally accepts as good and bad ideas.
I do not proclaim to have some wonderful method or process one can follow to achieve success… but there are certain things I look to and try within large enterprises to try and change how we do things round here.
So here is our first anti-pattern – And it makes me sad.
I loooove the word transformation, as it gives me the oppotunity to bring in one of my favourite subjects “obscure eighties childhood references” into play:
I adored Transformers as a child (and as an adult). I once based an open space workshop around that analogy!
It was called “Optimus Prime is Cool: Organisational Transformation and Transformer!”
Of the Transformee – The Truck
This was all about knowing thyself – Measure what you are before you start. If you are a truck – Know your dimensions, speed, MPH etc. Otherwise any organisational changes will be impossible to know if any improvements (or worsening!) has been made.
Understand the process of change. How to improve that change, and mistakes we can make… (hold this thought)
And what does the end state look like? The robot is more capable then the truck…
and the Transformer.
Me! Or more precisely, you! Or even more precisely.. US! What do we look like? How do we need to work?
Now the sting in that workshops tail, was that transformation is the wrong word for what we do. Whilst transformation does give us the image of fundamental change – The caterpillar to the butterfly – The malformed crawler to the flying angel, it does bring with it a range of dangerous comparisons. The Butterfly is a one way sequential process with a beginning and an end… and an inbetween state – chrysalis – that is zero value and vulnerable.
So to revisit the above metaphor and destroy it…
The Transformed: The end state is in flux until we reach it. IF we ever reach it. Agile change is continuous and progressive. It will not be what you predicted up front.
The Transforming: Agile change is done in parallel, experiment-led, with an evolving and emergent model of change, as well as an evolving and emergent agile “operating model” within. It is not a sequential process where one follows instructions.
The Transfomer: This is not performed top-down like the eight year old GodNigel with his pile of plastic robots doing as he wills, when he wills it. This is a whole organisational activity. It take a village to raise a child? It takes a village to change a village.
Transformee: Why change? Being a truck could be right for us. We just need a slightly faster truck.
Being agile is like being fit. Being fit doesn mean buying gym membership. It means going to the gym.. twice a week. Forever! And eat healthy. You can’t out train a bad diet. We will discuss eating healthily later.
So transformation is (alas!) the wrong word and the wrong mental model for this work.
Here are our next couple of anti-patterns to avoid. There are a few classic “quick wins” that will turn out to be “long losses” – so we want to dodge these big mistakes from day one.
DO NOT: Copy or clone.
It has been very tempting in the last few years to curse out Henrik’s Kniberg’s work at Spotify. Back in 2012, Henrik did some great work as a coach with Spotify and he and Anders Ivarsson captured that in the below paper.
A lot of people liked this work, such as myself, and it became heavily referenced.
Then came the DARK SIDE. Certain consultancies and coaches started using this work, not as the experience report of what Spotify was thinking of doing, but as a TEMPLATE to copy in other organisations.
And that is when the wheels came off. First, because you are not a swedish music streaming unicorn. Secondly, if you were, well Spotify were not doing these things. They were ideas and experiments that have never been done, or done and cast aside, or evolved, or or or…
And thus “Spotify Model” became a shorthand in the Agile community for danger.
BUT it wasn’t Henrik’s fault. Nor Spotify. Nor that PDF. It was the fault of others who took some experiences and some ideas and wrapped them up as if they are a pragmatic, proven and idiot-proof methodology.
This CLONING model exists in many other Agile contexts. SAFe itself allegedly started as a clone of work done by Leffingwell with Nokia. Copy and Pasting others answers into your organisation is a doomed endevour. What were the questions you were trying to answer? What was the problem you are trying to solve?
The better Agile Scaling approaches (LeSS and Nexus but especially LeSS) seem to understand this difference, and only offer up really tried and tested Agile patterns – The rest falling into the world of experiments.
DO NOT: Attempt big bang change. Overnight.
I think this is self-evident. But every big bang change leads to a.. big bang! Obviously, we would use our Agile principles to introduce these principles and processes – Otherwise we would be hypocrites! And if the change worked, we would be instantly wrong! Luckily, it won’t work – But it doesn’t stop organisations trying again and again to do that.
We will have to be Agile with our Change. Agile Change is about Agile Change and not just a change to Agile. We will start with a challenging goal or vision, we will build a backlog of change, we will do small slices, each one delivering value on it’s own, we will frequently inspect progress and the work, and make adaptions to the work. Thus the change will emerge and evolve into the highest value continuously.
DO NOT: Focus on the technology process tool part of the chat.
Since, you will need to evolve these processes frequently, so mapping them into a tool is silly and wasteful until stable. Also, the organisational structure needs to be considered. This seems like a quick win, get the same tool shared over 100 teams.. but the long-term damage caused by locking your approach down too early (allowing limited iteration), by having the tool imposed top down (limiting autonomy and self-organisation) and indeed, you would be performing the copy/clone anti-pattern at a technology process level rather than the business process one (Spotify et al) and getting all the problems associated with that as well.
And just like SAFe it wraps good practice with core practice and bad practice into a easily consumable (and impossible to digest) lump.
(Feel free to explore the Nigel Scale material for more on this conversation:)
The final part of the tool anti-pattern is..
JIRA and it’s ilk, are like Ticks. Easy to get, very difficult to remove.
Any method/tool/process that is easy to introduce and hard to remove, is very difficult to experiment with and pivot appropriately. If you see my collaboration tools blog post here, you will see some alternatives:
Right, the problem space is lightly laid out. (There are lots more mines in that minefield, but this is a 0 article, remember!)
So here are our first two tools.
TRY and THINK
THINK: All of the antipatterns listed above, are attempts to avoid critical thinking. To actually reflect and understand where we are and what is going on, and then tentatively and carefully inspecting and adapting our way through this difficult journey of change. And that is not unexpected. Human beings struggle with uncertainty. At a base level we crave that solid foundation, and when you are a manager or worse, a leader in an organisation, your knowledge of that field of play (The processes, the people, the products, the markets, etc) gives you confidence to make decisions.
This is the point, I’d like you to watch this video on leadership and VUCA:
So we can see, a range of thinking tools, and an appetite or at least acceptance of VUCA is needed to be able to approach this problem. I am sure I will add more to the blog on this idea in the future. But in the future, if you are a coach you need to turn your ego off and your brain on. THINK.
Experiment. Or as I heard Linda Rising say once ( Author of “More Fearless Change”), they are not really experiments as you are not running it multiple times, and you often do not have a control group – So really they are trials.
Try, try and try again. If it works, amplify the experiment, if it doesn’t, then dampen. Do this with different ideas, in parallel. Do this in differentr areas. But try. Discovery through delivery rather than deliberation through discussions in meeting rooms and zoom calls.
Try small. Try humbly. But TRY.
With these two basic (but under-utilised) approaches, now we can start approaching the problem itself.
My work on this is going to consist of three general areas
Scrumming the Iceberg
I wrote a book nearly ten years ago. I never published it because it wasn’t very good, it was full of hypothesis and opinion but no facts and I got busy having kids.
The kids are older now, those random ideas now have facts behind them (or I’ll conveniently forget them) and it turns out we are in a post-fact society anyway, so since everyone else is running their mouths with books… perhaps so should I. At least in blog form.
Anyway, I now have a chapter of that book on John Kotters famous (and cutting edge AT THE TIME) work on organisational change. I am going to cut and paste it… but if you see any editorial comments like this <Hello! This is Nigel2021 speaking. I may overrule or disagree with Nigel2011, but I will keep in the original content so you can contrast where we are now, with where we were then.>
John Kotter is a professor at the Harvard Business School and author, and is the leading authority on change and change leadership. His international bestseller “Leading Change”, covered a famous 8-step process for implementing successful transformations – Conversely, this process can be looked at, in reverse, to see the 8 classic errors a Change programme will make. I want to discuss those here and bring forth how using Scrum can help mitigate these huge issues.
For a organizational change to start we need to create a sense of urgency – Or at least make visible and harness the current underlining sense of concern. Most of the early uptakers of these techniques on an enterprise scale, did so because there was large and hairy problems with the business that needed changing.
Error #1: Allowing Too Much Complacency
Even in those organizations – just because the leadership saw an issue, did not mean that the workforce did – Or more precisely, the top did, the bottom did but the insulated middle layer, they did not. This is often where change programmes hang – not because of the workers but because of the middle managers with limited visibility – not at the coalface, and not at the business front end, it is easy for this community to “sandbag” a transformation. We need to ensure the pace of transformation and motivation to move forward is high on all levels. Bringing in external professional coaches and trainers (CLANGG! That’s the sound of an advertisement) can really help get the initial sense of urgency going along with strong and coherent vision (which I promise is coming soon…) If we do not have a sense of urgency, if we have apathy, we are not going to be able to get any traction with the change. However, don’t mistake sense of urgency for fear. Fear is something relatively easy to generate in an organization but it will severely constrain us. People will perform the equivalent of pulling up all their drawbridges and hiding in their metaphorical castles. Penetrating those mental castles would be very difficult indeed. We need to prime people with the appropriate sense of urgency whilst keeping them open to new options. <Nigel2021 here! You can also motivate change and create urgency with a Sense of Purpose. Something positive and engaging, and not just ooh-err we are in a bit of trouble. Harder but I feel more satisfying.>
Convince people that change is necessary. This requires support from key people within your organization. We spoke earlier about Change MANAGEMENT – Well, really it’s about Change LEADERSHIP. It is said that you “can find effective change leaders throughout your organization – they don’t necessarily follow the traditional company hierarchy.” Luckily, with Scrum we have a system that embraces this concept totally – We can bring together a cross functional team of empowered individuals to lead the change, This is where the concept of ScrumMasters is crucial – we have embedded Change Agents thoughout the organization to help this coalition and in the largest organizations to generate a task force to do this work! We need then to build these individuals into a cohesive team.
Error #2: Failing to Create a Sufficiently Powerful Guiding Coalition – How committed are your coalition? I have a rule of thumb – The Empty Chair Twice Rule. Anyone can miss a meeting, a call, even on something as important as this. If you miss it twice? It is likely that person is missing this for some underlying reason. Not bought in? Not enough time? Not enough commitment? Belief?
<Nigel2021 here – I have some material on this powerful coalition idea. Even Kotter has moved on from that commitee being solely enough. He now talks about a volunteer change army. That is what we will need to create? How? See the next area – But the answer is ScrumMasters>
Why are we doing this? Why? Why? Why? Once we understand why (and this need to be real and tangible – “more money” is not tangible enough) then we can start articulating what this vision actually is – Though Scrum does not provide any visioning techniques, a lot of us in the Scrum movement draw upon Jim Highsmith’s ideas around Product conception and visioning (Elevator Pitches, Future Press Release, Peer Consensus) and Luke Horsemann’s Innovation games (Product Boxing, See the Future) to help us generate and genuine, tangible, inspiring direction.
Error #3: Underestimating the Power of Vision – Vision is CRITICAL. It inspires, it sets direction, it motivates, it helps us self organize as a coalition team and it helps the change itself (which will steer in a variety of directions as we discover more about our organization then we ever wanted to know) stay the course.
We must constantly bash the organization over the head with WHY. People are not stupid, they will not jump just because we say so – they need to be persuaded, they need to understand WHY we must make these changes. The vision is the carrot to wave under the organizations nose. And this must continually happen. Every day. Big businesses are quite collectively dim – they don’t mean to, it’s just often a symptom of their structure – this means that we have to constantly articulate WHY and WHERE we are heading so that people can align their practices within that big picture. <Nigel2021 – Back to Sense of Purpose again – The vision can be an articulation of that sense of urgency but I guess in a positive way and not just the classic negative one.>
Error #4: Under-communicating the Vision by a Factor of 10 – Kotter has calculated that Visions are often under communicated by a factor of ten possibly a hundred or even a thousand? The error of thinking a one off communication or “summit” will somehow carry people through months of work. Change and possible pain – is far too optimistic. We must constantly communicate the need to be Agile and why we must be Agile to the organization as a whole. Frequently.
What is blocking the change occurring? Are some people resisting? Are their processes or practices getting in the way? As we know, Scrum is a issue generating machine – It’s like your Mother-In-Law. It will constantly nag you to improve. It is like an MRI Scanner – It will show up all your problems so you can fix your problems. It does this in terms of “The Change” as well as in terms of the teams running Scrum. Removing Obstacles will enable to the change to move forward and ease the effort required to be Agile within the Organization. We must recognize and reward the change leaders, the coaches, The ScrumMasters, the internal early adopters and we must identify those people that are being anti-bodies to this change – being resistance – and we must work with them, coach them to understand why this approach is valid and the right one for us.
Error #5: Permitting Obstacles to Block the New Vision –People go to hospital. They have the scan. They find out bad news. For some it is very bad news. What do they do? Treatment? Sometimes the treatment is painful. Some people just turn off the Scanner and don’t go back to hospital. These obstacles are not going to go away. They will not fade with time. We can hope we as an organization will “get better” in time.
<Nigel2021 here, This is why we need to do Scrum as a change approach – To really put some energy around the removal of these obstacles. Many “Agile organisations” I know have not removed fundamental root cause obstacles. Instead they work around them. It is not working very well>
Success feels good. People only really believe when they see it with their own eyes. When I started doing Scrum, I was very skeptical (It’s my nature – sorry) but when it was shown to work, with my environment, with my team, my friends, I was won over. We need to demonstrate as early as possible success to people. We cannot expect fancy slides and clever talk to cover the “gap”. Success reduces fear, reduces resistance. Often large organizational changes have been created and pushed in a very traditionally planned manner. Like the metaphorical waterfall with all the value coming at the end. You may have seen the traditional change curve, where people say “Don’t worry – it’ll get worse before it gets better.” Who waits for it to get better in practice? Not many people, considering in badly planned changes this curve is LONG and DEEP. Luckily, Scrum requires that each Sprint (normally monthly in a change context) we must have something demonstrable. Something valuable to the business. Within Scrum we are forced to create short term wins as part of an iterative approach as well as work the long term vision. Pick good opportunities then reward those that succeed. Or you could take the Ken Schwaber approach and pick the scariest most risk laden project – at least that way people can’t play games with it and strangle it in it’s proverbial cot.
Error #6:Failing to Create Short-term Wins –An Agile Transformation is expensive and time intensive. If you do not show quick ROI like all big projects you are under a lot of pressure straight away. And in change projects they are all too likely to be killed unless a VERY strong ROI can be continuously demonstrated. “What have you done for me lately” is a very good motto for the Change.
Declaring victory too early. Real change runs deep. A pilot is fantastic but that is all it is. A Pilot. You should rotate Change agents to keep them fresh (I once spent far too long in Sheffield on my own) and keep a constant eye on your Transformation Backlog.
Error #7:Declaring Victory Too Soon
Nuff Said. <Nigel2021 – Oooh topical! For 2010. Bush declared victory too soon. There was lots of pain after this event. Real change is long term, and long lasting. Most changes fail because the funding and organising is in months not years. Especially around Agile Coaches.>
To make this work you need to embed this as part of your culture. People will leave, retire and new people will take their place. Does the Culture become part of them or do they start diluting the culture? When we hire new people (especially at higher management grades) we need to endure they align with our vision and engulf them with our ways of working and principles for a significant period of time
Include the change ideals and values when hiring and training new staff. Have strong succession planning in place for the majority of your key roles, both change coalition and in general across the organization.
Error #8: Neglecting to Anchor Changes Firmly in the Corporate Culture
It doesn’t matter how great the leader is – If they leave we need to continue on without them. Otherwise, all this is for nothing. <Nigel2021 – Succession planning is critical ESPECIALLY in your change agent roles. They have high turnover so we need to ensure we don’t keep randomly pivoting with each new coaches personal proclivities>
NoNo is a part of Kotters book, “The Iceberg is Melting”, where he uses an interesting approach of a cod-children’s story around Penguins and Icebergs to make some important points about change.
NoNos (both the penguin and the archetype he has generated) are “highly skilled urgency killers” to quote Kotters “Sense of Urgency”. A NoNo is not a sceptic – Sceptics can become very useful champions once you have won them round. (Sound familiar? Hint – someone writing this article was once a sceptic) NoNo’s look to discredit those trying to create the sense of urgency and will do anything to derail the process. The line between Sceptic and NoNo is well documented in Kotters work. Intent is the big driver – A Sceptic is open-minded but… Sceptic. A NoNo has made up their mind already and is fighting (openly or covertly).
Kotter (and I) recommend you never try and co-opt NoNos. The famous metaphor of tent sleeping arrangements and toiler facilities does not apply here. NoNo’s are not house trained. (or at least tent)
You ignore NoNo’s at your peril. You can hope they won’t go around destroying and politicking against the change… but Hope is not a strategy.
Kotter recommends distracting the NoNo’s (literally sending them away to some foreign office) or immobilizing them with social pressures, this can work with those on the lighter end of the NoNo spectrum, but will not help with the major NoNo’s or you can get rid of them. This is my preferred strategy. The amount of times I have personally heard “I wish I dealt with XXX sooner.” And XXX is always a person. You will have a clear idea early who are the NoNo’s. You need to do something about them, because trust me on this, they are working every day to do something about you. <Nigel2021 agrees with this even more. Love your sceptics. They are THINKING and TRYING but maybe struggling and need help, and can help us! NoNo’s are destructive and we need to exorcise those demons.>
Goodbye and fairwell,
2. Scrumming the Iceberg
My work on Kotter has hinted at this, but lets dive a bit deeper.
Our coaching teams should also be operated on a Scrum model. Whilst coaching, training and consulting are time dependant. (You have to perform certain work on certain days) we should still use a velocity concept to <forecast> work. More than anyone, it is too easy for coaches to work at an unsustainable pace. Four week sprints make the ideal planning horizon.
We utilize Scrum to roll out Scrum into the development teams themselves -“Eating our own dogfood” – and we’ll gain all the benefits from the framework. Reduced risk, Short term wins, Visibility and the ability to embrace a changing world. This will also us to gather feedback on how Scrum works in your organisation.
Large scale changes cause increased risk, fear and resentment whilst gradual systematic change programmes allow us to keep people, process and projects content and allows us to bring these products along with us. By using Scrum, this also allows us to make small gradual “baby step” changes to teams and organisation without risking any current deliveries. This is the “boiling of the frog”.
“The boiling frog story is a widespread anecdote describing a frog slowly being boiled alive. The premise is that if a frog is placed in boiling water, it will jump out, but if it is placed in cold water that is slowly heated, it will not perceive the danger and will be cooked to death. The story is often used as a metaphor for the inability of people to react to significant changes that occur gradually.”
Scrum works best in Knowledge based environments building a cohesive and ever changing whole. The most common manifestation of this is Software – but Change projects fit perfectly into this metaphor. A need for a cohesive end product (the organisation), the need for vision (often lacking – which we’ll come back to in a moment), the need for planning but at appropriate levels (detail now – epic in the future) a need for constant short term wins as well as steps towards a larger whole, a wider wisdom-of-crowds from diverse, cross-functional teams and frequent inspection and adaption to empricial judge our position and pivot to the next best position. (Retrospectives, Reviews)
So we have our Product Goal, probably an aspect of the overall vision of change, we have a backlog of all the work we want to do to achieve it. We prioritise it, we select a subset that creates a viable increment of value – We plan it, and then we do it. Every 4 weeks we come together to review our work and retrospect to learn and pivot on new information.
However, you maybe asking, “why do I need to plan my work? I’m an Agile Coach? I sit with my team who hired me and work with them until my contract runs out. I don’t want *another* coach sticking their head into my business”
Oh dear. I am sorry. But there is an iceberg approaching and we need to Scrum it as a organisation to get out the way!
Most so-called Agile enterprise transformations have not taken full advantage of the principles, tools and techniques that we apply. Too often, they have implemented Agile at the “bottom,” in their development teams, but have not embraced the principles at the “top,” the strategy levels of the business, or even at the “middle,” within the layers of middle management and process.
<I said that in 2010 and things are better… but not as much as I would hope>
I now want to explore an areas that crucial importance to any large organisations transformation. The management of the Transformation itself.
There is an common saying in the Change management world – “Seventy percent of Change projects fail.”
This is an astonishing, apocryphal, but also very believable figure. Look at the large organisations doing Scrum currently – I would easily say there is a high failure rate – or more precisely, since even doing Scrum awfully and only at the lowest levels of a business in a haphazard manner is still far more successful then what came before, there is a high failure rate “to achieve great results.”
The first mistake is to “forget our principles when we scale”. (Geoff Watts 2007) Most coaches recommend a gradual rolling out of Scrum into a team to prevent large drops in performance and to reduce the risk of non delivery – Why then, do large organisations often try and either plan their change in the traditional flawed predictive model, or try not to plan their transformation at all and be swept along with the flurries and changes of direction that comes with a rapidly moving business world?
“[ETC]…is a single Scrum team responsible for managing the adoption. This team is called the Enterprise Transition Team or ETC. “ [Enterprise Transition Council/Committee]
Schwaber: Scrum and the Enterprise 2007 page 9
<Things have changed since> Ken recorded his Enterprise Transition work, in “Scrum and the Enterprise”
I prefer term Coalition over council or committee. (I hate committees – people always seem to put committees together to stifle rather than to expand. To strangle an idea rather than catalyse it )
The Enterprise Change Coalition is going to be a genuine coalition. A coming together for a single purpose. Not to manage like with a “council” not to be subservient to any other part of the organisation, as a “committee”.
A coalition is “an alliance among individuals or groups, during which they cooperate in joint action each in their own self interest joining forces together for a common cause.” – Wikipedia 2010
I’d recommend you have a “friendly” HR person available in the coalition. There will be a variety of change in positions, roles and responsibilities and you will be inducing turnover and possible disorder. There will be unhappy people. We want to make sure this is done with the right principles and within the legal employment framework. Especially in Europe, it’s very important to do the right thing in the right way. Or get sued!
We can start building my idea of an Agile change organisation structure as follows. (as mapped on to the original organisation pyramid we showed you earlier)
We have the Enterprise Change Coalition (ETC) existing at this highest point in the organisation possible, with a strong visionary sponsor chairing this committee. This coalition is mostly made of up senior important organisational figures who are bought into the change but not solely made up of them. There will also be cross functional members from the entire strata of the organisation “bottom” to “top” from all the main communities. Product Owners, Team Members, ScrumMasters, Stakeholders and other colleagues. Each will have a contributing influence and visibility of things that the others cannot see. Without the real workers this would become an ivory tower talking shop. Without the leaders, this becomes a sharing of greviences in a bar, without power or position.
This will be structured as a Scrum Team. Schwaber recommends “The most senior executive in the enterprise is the Product Owner.” As I said before, it is better to think of this as a coalition more than a mere self-organising Scrum team. It is more self-directed.
<Nigel2021 here! Scrum finally caught up with me on this front in the latest (2020) version of Scrum. Self Directing teams have power over WHY, WHAT and HOW, compared to the traditional Scrum Development Team owning the mere HOW.>
The PO in this situation will, at a minimum, have to be “presidential.” I prefer the leading executive to be building this group as a guiding coalition (see Kotter) and so prefer the Executive to be acting more as a ScrumMaster than Product Owner. In that case, the more senior but less involved organisational leader (Chairman over Managing Director) may be the Product Owner.
If you have the main executive as Product Owner, this can then lead to a very top-down rollout of Scrum. (Some leading Agile figures would shudder at one of those words “top-down”, “roll-out”.) I will decouple this slightly from Scrum and this discussion and will use the term “Sponsor” for this senior leading figure.
<Nigel2021 – Looking at this with ten years experience. I do fear top-down transformations far more now. Because they are often so badly done. Building more of an Agile Leadership Team involving all levels can really give some bite and some raw pragmatic intelligence to this change.>
<Nigel2021 – OK here comes something a little more controversial!>
You will need to have a coaching team dedicated to the roll out of Scrum <lets change that to Agile Change> across the organisation. This team will also need to be cross-functional, as they will work across the diverse areas of the organisation. They will be made of Agile Coaches from a variety of backgrounds to encourage diversity, avoid groupthink and to have a little healthy conflict. A Dash of change management experience is also useful but get the balance right – It is very easy to take the coaching team down a too pragmatic route. You do need some fire in there!
<Nigel2021 – I have more material in video and presentation form on my opinions on this teams construction since 2011 – But that is probably another blog post!>
The coaching teams needs to be out of direct line management of all but Enterprise Change Coalition. The alternative is a coaching team that is well aware of it’s position in the organisation. Too low down and it will not feel it has the authority to deliver genuine change, it can easily be squashed or mitigated by it’s own line management, and it may feel a need to align with the policies of it’s own place in the organisation.
TRUTH: I was on a Agile Coaching team that was part of An Architecture Design community that directly reported to the Chief Architect. Hmm. Talk about putting a fox in the henhouse. Or maybe the Agile Hen was amongst the National Union of Foxes yearly conference. Either way, it was a very awkward “odd couple” and severely hampered and finally destroyed their transformation.
The coaching team needs a roaming remit – to be able to align with the goals and vision of the Enterprise Change Coalition. These two communities need to be tightly coupled.
There is one more piece in this puzzle. The piece that is missed. The secret ingredient…. No. Not embedded coaches, but instead….
ScrumMasters as the Change Army
ScrumMasters. We will be building a layer of change agents waiting to be called upon! We’ve all talked for a long time about the Change Agent aspect being crucial in the ScrumMaster role. We have all discussed the essential nature of the ScrumMaster as a long term, full time role. This is why. <Nigel 2021 – This is why most Agile Transformations struggle. Due to the neutering of the ScrumMaster community. And the replacement of them with a thin layer of externally hired short-term contractors as “Agile Coaches”.>
Build ScrumMasters. Now.
We have a superb organisational change workforce, ready to embrace the need to continuously improve. Linked in with the coaching team/s providing expert support and the ETC dealing with vision and the biggest disfunctionalities. All connected. All interwoven. All focussed on people, purpose, principles and practices in the right way.
The ignoring of the ScrumMaster community in this way is criminal. Embrace the power and effect of this community. They are the assault troops (to use another horrible war metaphor) for the change. (P.S. I originally wrote “We are the assault troops.” – You can take the boy out of the ScrumMaster job, but not the ScrumMaster out of the boy.)
If we don’t do this, then the decoupling of the SM’s from the ETC and Coaching Team will cause us all to head in different directions. Thousands. And this can easily lead to sub-optimisation, where teams individual optimisations for themselves, effects the organisation as a whole. Or worse, the teams don’t optimise anything, the scrummasters fade into process enforcers, and the status quo management, can slow, suppress and finally stop any progressive change.
With that in place, (or under serious construction with HR), then we can in parallel approach the third aspect.
Nigel2010 and Nigel2021
<Nigel2021 here. Agile Coaches and ScrumMasters is a hot topic at the moment in the Agile space – With some businesses deleting all their SM’s and having a couple of roaming Agile Coaches covering the gaps… oh and traditional management doing the same old thing. What a car crash. I am less pro-centralised coaching team then I used to be, but the de-centralised model has crashed and burned everywhere – So we do need to find a balance, and the SM’s are the key here that NO ONE IS USING. This needs to be another blog post I think.>
3. Mikado Mash-Up.
Hello! This is back to Nigel2021 again – Before I start this, I notice the same idea has emerged in quite a few places, as well as the underlying pattern being incredibly common in successful agile organisations.
“Mikado is a pick-up sticks game originating in Europe, played with a set of same-length sticks which can measure between 17 centimetres (6.7 in) and 20 centimetres (7.9 in).
In 1936, it was brought from Hungary (where it was called Marokko) to the United States and named pick-up sticks. This term is not very specific in respect to existing stick game variations. The “Mikado” name may have been avoided because it was a brand name of a game producer. The game is named for the highest scoring (blue) stick “Mikado” (Emperor of Japan).”
Wikipedia – 2021
Each player’s goal is to pick up as many sticks as they can, one at a time, without making the other sticks move.
“A feature team is “a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.” Feature teams are an essential element to scaling up agile development. Without a feature team structure (but instead, a component team organization—based on code ownership, combined with a single-function organization—analyst group, programmer group, testing group, …) your organization is likely to create numerous wastes and sub-optimizations that lead to a sequential (waterfall, …) development cycle. Feature teams structure resolves many of these wastes but also introduces change and challenges.”
We want to avoid a couple more anti-patterns in any organisational change:
DO NOT: Map Agile or Scrum onto your current structure.
I used to do this – Adopting the Kanban approach – “Start where you are now”, to reduce political strife, power games and to get the ball rolling swiftly for another quick win. But without significant energy, it can be impossible to move on from this state. You end up with at best slightly better then you used to be… for leaders. But fr the workers a worse experience. Or even worse, mere Agile theatre of post-it notes, standing up and JIRA JIRA JIRA as far as the eye can see.
I relate this back to the popular change tool, the Satir change curve.
Again, a whole article lurks with this one idea – But inherently it is the idea of a new foreign element inducing chaos and disorder and then as Steven says on his blog:
“The members discover a transforming idea that shows how the foreign element can benefit them. The group becomes excited.”
And as we all have seen with many change programmes, the introduction of foreign elements and chaos can lead leaders to stop the change before the integration and success of the new status quo can happen.
Well, in my experience an Agile approach both dodges this problem, and steps straight into another one.
Bad agility. Half arsed Agile, as my ex-colleague Kerry Buckley called it – https://www.halfarsedagilemanifesto.org – We all hate it, it’s everywhere. Why? Because shoddy agile is better than before. Ron Jefferies (Agile manifesto author, friend of mine and professional curmudgeon) calls it “Dark Scrum” – A better name would be “Dark Agile.” A corruption of Agile values and principles AND practices.
So, to quote
So, if we map agility onto what we do now, we are setting our selves up for big failure.
Agility is about big change… in small packages.
And at a lower level of detail:
DO NOT: Use Component teams and try and connect.
You will end up with a sea of dependancies, a mountain of blockers, an army of schedulers, a JIRA full of… well JIRA and more process then you started with at the beginning. And like in the film “A Bridge too Far” a fantasy version of the very real Operation: Market Garden in WW2: Where the allies attempted to capture 9 bridges to allow an army to race across them and deep into Axis territory. If they couldn’t take and hold every single bridge in the plan, the plan was doomed.
Component teams are the death of agility and the death of your business. We must move into value driven feature teams cross functionally spanning the components.
Re-enter the Mikado Mash-Up
I combine that Mikado Method idea of
Set a Goal
To gradually and iteratively slice up component teams into feature ones. Doing one small change at a time, so not as to disrupt the delivery or value of the remaining stack.
Imagine we have ten systems with multiple teams working on each system. There is an assumption that all ten systems need to currently plug together to deliver value.
So what first?
My first goal would probably be to create a team that can trace value through the systems
Then run experiments to do that. Possibly a “Barium Meal” ticket that passes through the current structure and illuminate the route these stories take, the time taken and the waits that the story is forced to experience.
Visualise that journey, so all can identify what we are seeing.
Undo: If the story runs into a cul-de-sac – Either politically or just due to the type of requirement it is, I would rewind, stop the trace and select a few more examples to trace.
Now at this point, simulation is hard becauise there are a thousand possible outcomes.. but lets keep playing the game.
Let us assume we find there are actually not TEN systems on the value path – But actually 7. The three others are independent or valueless…
Goal – One team delivers value,
Experiments: location study, technological tools, team building, Agile coaching etc,
Visualise: The flow again and the various activities within
Undo: It is only one team being built – the others are still working in the legacy way, so this teams work can be unwoven if needed, and can be managed on independant management tools.
So they act as a tracer bullet for the future teams to gradually roll online. Not as an example to be copied – That would be falling into all the anti-pattern traps of this entire article (spotify, cloning)! But as a scout or minesweeper to find all the pain points and problems – And then we can clear them for the following teams, so they do not impact 24 teams at once.
I can easily see the first half dozen teams all being “scouts” for problems.
As we evolved and emerge the teams, the need for large amounts of dependancy tracking dies, the need for heavy supervision tools fades. The tool set can actually stay fairly simple and flexible. Keeping our organisational muscles and tendons still supple… for future change. We don’t need JIRA or it’s like, because WE’VE NEVER NEEDED IT.
So this gives us a ScalING and ChangING models. Models that allow us to understand and surf that ever changing organisational landscape and allow us to bring more teams delivering value sooner. Whilst keeping light. Each feature/”rainbow” team delivers end-user value. With the exceptions managing their own lives. Delivering value independently of those core value streams.
I imagine in a real life situation there will be many many more smaller mikado mash-up steps. Many many more undos! But as a simplified example I think this works.
I have found someone else using Mikado with an organisational theme: You may want to look at their approach here:
Gosh I am so deep in now, I think I need to stop this article. I will drop another article next week – One of my older Agilifying Agile Coaches ones – Talking about community. Those internal and external coaching networks are going to be important to make this all work.
BTW if you have read this far – Tell Nigel the code “Destro” for 50% off his PunMastery book!