December 2007, I am in an Aikido Dojo, somewhere in south of Paris. This is my first lesson. When I think about it I feel humility.
Remi, a tall man is a black Belt with few Dan. Anyway he is far more experienced than any of my peer, including me, in the Dojo that winter day. We all seat in a circle. He stands at the center. He is currently doing gesture demonstration. It looks so harmonious that I think this is like a dance.
As I told Remi about it, he invites me to join him and to attack frankly. I am taller than him by few centimeters so I gently punch him in his stomach. He avoid it in silence and ask me to make a far stronger attack. I ask for confirmation. That time I gain momentum.
My arm stil hurt me. I do not have time to understand. I lay on the ground, my arm tightly locked. I cry to stop.
Aikido mean « Way of Adapting the spirit ». That is a exactly what Agile is. At start Agile also looks like dancing to non practitioners. And this is also how it appears to really advance partitioners: As easy as having fun doing great things together. Nice Foosball, Fancy rooms with sofa and beer pomps everywhere. People looks happy. It is exactly like if they were on a nice party. Actually they are just at work.
But, you know the reputation of their company. They always deliver the best to their customer. Stakeholder and sponsors are happy. Indeed at the end it is very profitable. This is why they can afford To hire best people to play foosball and also produce high valued product .
This gives impression that Agile is an easy thing to do. So it is very tempting to buy some foosball, design great office, change the language to startup fashion having few people coming to nice training and waiting to have the same effect.
Here is a scoop: That will never work like this !
Let’s Go through example of company that has started to fail ( ans some fail the very hard way) before they succeed or not.
First example is just Google :
Testing in Google ( bases on Raj Mudahr post ; https://rmudhar.wordpress.com/2010/04/17/icst-paris-2010-innovation-in-test/)
« In 2008, the average developer spent 37 hours a month waiting for tools to spit out results. The focus was on making this shorter. Google globally executes 65k builds per day or 20 million per year. Object file output is 698 TB of data, cached for 7 days. Incremental linkers are used for builds. And on these builds, Google runs 7.5 million tests every day. Most builds take about 5 minutes, but somewhat longer at the tail end when different build targets are done. 66% of the builds require no user intervention at all – fully automated. Google invested heavily in infrastructure to make this possible. With the new infrastructure, Google saved 604 engineer years – the average developer got back 2.7 months of productivity, which could be invested in innovation. Productivity jumped from 50% to 191%. Developers get feedback in minutes, not hours, if something is broken. »
Let’s be honest here, for a large majority of legacy companies, 37 hours a month waiting for tools would be an excellent performance. Here, we speak about all to do to go from development to full deployment on the customer including the services that goes with it. It is not really fake? Well, in fact, all depends of your Driver for Agility ? Google was knowing very well where they come from and knew that scaling up almost always drive huge technical debt. They fixed it by investing a huge amount of money early enough and before growing too fast. Nothing to see with ROI of even profitability, Anyway Google was at that time loosing money. They just has a the belief and very few management layers that make such decision very simple.
My second example is another major WEB player.
Lets go back in 2007: If it would be would be a county, It would be the 5th largest country in the world just between Indonesia and Brazil. its name is Myspace : https://www.theguardian.com/technology/2015/mar/06/myspace-what-went-wrong-sean-percival-spotify?CMP=share_btn_tw
As Google, Myspace has been a startup. in Year 2006 to 2010, Myspace was on the top of Agile practice . As an Agile beginner I was a fan of Scott Downey. Scott was the main Myspace coach. I was also a very active Myspace customer. I was publishing my own music on it. They were offering facilities to share music far before Spotify or Deezer. This was an excellent user experience for me. I was clearly a promoter to my friends in those early days of social network.
Here is the thing: Myspace has ben acquired by New Corporation, a R.Murdock Company. This happen in 2006 just before another player Facebook propose Myspace to acquire them. Myspace refused.
The company had financial objective now. Each quarter exécutives need to increase revenue from advertising and this becomes a priority over Consumer expérience.
So disruptive advertising happen all the time. I was myself not so happy, but I remain on the site as Facebook was not offering the same offer on music sharing. Many other left and the number of view to my own site decrease suddenly. This become a place that ‘Sucks’.
The worse Is that many employees were perfectly understanding what happened but no one sounds to have enough power to stop the breaking machine at the top of the company .They also make some other hubris mistake like doing their own content delivery network competing with another player that did it really great. Name here are Amazon or Netflix.
In 2013, all page member has been destroyed. In 2016 they face one of the biggest data hacking. In 2019 myspace announce having lost all content prior to 2016 including all my songs and comments.
Today Myspace still exist but is a shadow of himself. I left and use streaming platform and had to use Facebook since this is where people ask me to have my music event visible. ( Hopefully the new generation sounds to be more critic regarding fecebook)
« It seems that MySpace is an example of a company that suffered from the seemingly sensible desire by News Corp to set a strategy, focus on execution, and achieve rapid growth ».
Sadly this is a very classical default of pure « Top down approach » in a supposed Agile company . This is probably the top real Agile-anti-pattern. Myspace downward spiral example has the advantage of being close to a caricature. It is also well documented. Let say this is an easy « after the fact » talk. The reality is not about the mistake they did but the fact that Myspace has significantly failed to take action based on the very first learning.
As ScottD Anthony said « it often takes a few twists and turns before a disruptor figures out the right business model. »
The funny things Myspace was disrupting the former Friendster (who turn to have lots of technology problem). Then logically failure from Myspace provides a great learning to many other: This is why no Agile could be conceived today without Hypothesis backlog and early test in the market (Search for Canary testing to get an example). I would say that the room for excuse has just narrowed. However, the best chance of survival come from the fact to be able to realise we are wrong soon enough.
In the next example, let see a very courageous organisation to admit their fakeness of agility:
Recognise Fake agility is the cornerstone of recovery.
This third example comes from the last organisation I would have granted for transparency. However, they exposed publicly their weakness. And this time, this is not just another social network or any volatile workplace but the legacy of the legacy.
Its name is America Department of Defense and we are in now march 2019.
This is not a surprise to me to know they are embracing Agile even at large scale. Agile has been successfully used by US Army since long and lead many success. ( I recommend the books « Team of Team » written by Stanley MacChrystal that gives good example of that) So It is work on the war Theatre, why not using that in the DOD office.
But having them admitting their failure is more astonishing :
Here here an extract of Steve Denning article on DOD
« In March 2019, the Defense Innovation Board concluded that DoD’s “current approach to software development is broken.” “it takes too long, is too expensive, and exposes warfighter to unacceptable risk by delaying their access to tools they need to ensure mission success. Instead, software should enable a more effective joint force, strengthen our ability to work with allies, and improve the business processes of the DoD enterprise.”
SO here what they are doing. The did a a guide called “Detecting Agile BS”
That is quite interesting to see such awareness and call for action and its publicly announcement outside the company.
The learning is that any company able to recognise that they are wrong and take action to improve is actually an Agile company even if Agility is actually failing at first.
That means the worse is being a Fake Agile company without naming it. The good thing here is to take action. It is why you will find so many health check: I has many opportunity to go through many health-checks. All ( almost) are valuable to asses Agile practices. I personally generally come back to the Nokia Test for its simplicity. But its does not target the Entreprise Agility:
Enterprise Agility main principle: it is about Decentralised decision
Do not look for a new manifesto. Agile entreprise just follow the same Manifesto.
They just add one principle: Pull ,do not push !
As we see on Myspace example, the anti-pattern is to adopt the classical path of change management: The top level set a strategy, charge change agent to focus on change execution, and put target to fastest change and make sure the change is under control. This approach really make sense to fix issues in a repeatable work unfortunately this fail to address fast moving target such as competitors, changing regulation, political or financial uncertainty or Scarcity of skills on the market.
Embracing Agility at the enterprise level mean first to deeply embrace the approach of decentralised decision. Top down will not work (Steve Denning « Radical management » book describes that very well). That does not mean the absence of pattern for success. Nor the importance of a strong wiliness from the top for it to happen. People will pull it from the top:
Here is why: People follow leaders who consistently walk the talk in a very transparent and humble way. If you want teams to perform at their best, you need to put on yourself the highest possible expectation and have enough humility to accept failure when data show you you are wrong.
There another advantage of Pull versus Push is Speed . Unfortunately the intuitive way to go faster is to put more pressure and stress into the system. This is based on assumption that people are lazy and that they work better under pressure. In cognitive jobs, it is now proven to just create overload. You ll just get slowness. Pull is used in all good lean factory to produce the right amount of material and keep inventory ans waste at the minimum possible level the current context allow to do. Change follows that rule the same way. We all have a limit of change at the same time, but no one indeed has the same. Each part of the organisation will go on its speed dictate by its own contraint ( that should be identified and leveraged). Then and only then they will genuinely go.
The issue is that it sounds so obvious that many organisations fail to follow those and they end up blaming their framework. To me Scrum or SAFe or Less are very valuable framework ( My Area of knowledge is about legacy large entreprise that really want to embrace Agility as a culture). They works because they are all founded on Agile principle and this principles of decentralised decision. In addition, they offer many safety nets that, when well applied, will reduce the cost of failure that will flow from it.
So why fake agile. After all no one want to kill his organisation? Why it is so difficult? Traditional management tends to put at the top of entreprise people that are strong and hard worker. The thing is that generally those people do not like to admit failure at least publicly. To fix that they need to allocate into their agenda time for personal development. Then and only then they will learn to be like Aikido masters. They need to be the champion of « the art of adapting their spirit »
They also need to operate at the highest possible level of motivation and this is impossible to dictate motivation :
To paraphrase Simon Sinek : start with why :
I suggest anyone who is interested into agile to first reflect on « what made you choose to do your Job. ? »
A good way to do it is just to close your eyes. Imagine you are back to your childhood. « What are your child dreams ? »
No back to where you are today, « would this child be proud of what you are doing today at work? » »
I have done the exercice myself and my driver was to create something very useful so that I would feel the humanity to be a little better. With Humility I do not claim a full success but probably my biggest win in professional life were done thanks to Agile.
Then you can check if there is a link between the gap you have and typical issue company fixes when embracing Agility :
- To long Time to Market,
- To expensive,
- Lack of Flexibility,
- Not enough Customer Collaboration,
- Poor visibility to Customer,
- Quality issues,
- Not the value we want on Market,
- We are not sustainable,
- Lack of Predictability,
As This is just my own list of typical Why. You will find many other issues organisation has fixed by being more Agile. Maybe your goal will be better addressed by something else. That is perfectly ok ( Why ‘NOT‘ ). I would recommend to read more on what is really Agile and makes some pilots even where it is not so obvious. I am surprised everyday about people coming back to me with some Agile experience in area such as distribution, shipment and even factory floor. As Agile is young you might also be a pioneer in your area. ( Why not ?)
Why « Why » « Why NOT » or « Why not? » are so important question: Two reasons :
- As in any pull system, we pull the highest priority first so if Agility transformation is not a priority probably wait for it to be the top priority. If not you, be ready for Fake Agile.
- This create motivation. And Motivation is a key driver for speed. All coaches face one day an announcement like « We are Agile here, thanks to ring next door! »
Then and only then you can define what it is:
Agile is just a set of Values. Actually the manifesto was just trying to see what is in common to many pioneer practice around development software. And few were using also those for more than Software ( Scrum name came from Hardware project first) .
The manifesto is simple : https://agilemanifesto.org/
8 things that matters. 4 matters more.
Personally I like the Alistair Cockburn heart of Agile simplification:
Progress by Step, anyway your will fail. Better to fail early on micro step than failing hard :
Then let’s remember about Aikido. The very first stage was to know I was not knowing. And I describe that already. Then my next step was to spend 2 years as a beginner. I copied the master gesture .This stage is called in Aikido, SHU. This mean « learning fundamentals ». It is about Obeying to program procedural memory. At that stage you brain start to feel that your body is the real master. The master show and the correct you.
Next stage HA is about breaking the tradition . This is where I start to discover new technics or approaches. Exactly what Teenagers do about life. In early days of Aikido , one Japanese teacher invite some on his french students to go in bars to provoke (verbally) drunk men. Then they learn by responding to their attacks (There is not such a things as non violence if your intention is to be violent ). This is about HA level. The goal is mainly about getting self-confidence in art mastery.
The third stage is called RI. This is about Transcendence. At that stage technics does not matter anymore. It is natural like if it was in your DNA. This means you do without any need to think of it anymore.
Back to Agile manifesto, it is made of values. Valuer describe this RI stage. This is also a perfect description of the ‘non Fake Agile’. So per definition, SHU and HA are just Fake, they are stage for learning. The goal is always to reach and stay at the RI level ( or not )
Now you have 2 type of company ( at least ). Startup has no really other choice than making very tight circle. Reflect Deliver Learn Improve, and they need to do this as close as possible to their customers. The reason is simple; Survival .
Large majority of legacy company has been startups. Maybe it was a very long time ago. from then the system has lost its early days agility. This is mainly because the need of survival has disappear for something like being the first one, i.e beating the competitors.
In other words , almost all company has started by an Agile RI state. Their race for rapid growth and need to over specialised teams make them go away. And this ran for decades.
Those companies will have to take the costly SHUHARI way. They will need to do before being disrupted out the market. Myspace, but also Nortel Enron and many other failing company has shown that this is more about internal issues than outside pressure. The external context might just speed up failure.
Agile is not just Scrum or Kanban. At large scale Agile is not « Agile at scale » « Less(r) » or « Safe(r) » . But they have all implemented a very well documented SHU and HA level.
This is why Spotify has make some radical choice to stay on the RI level :« The problems that a company like Spotify faces on a day-to-day basis trying to serve twenty million daily active users ….So our approach is what futurist Warren Benes calls an ad-hocracy, an organization intentionally designed for flexibility and adaptation, … is maybe less concerned about extracting every last dollar of every activity that you engage in, …what this means that we have a relatively high tolerance for failure. And we have a relatively high tolerance for inefficiency in the name of making sure that we are doing the right thing».- Simon Marcus Head of People Operations (2014)
For all others company knowing , all teams could make a fair assumption of the stage they are and have a right progression step .
Typical question to ask according to where you are in SHU-HA-RI:
With assuming where you are, It is quite easy to test against your assumption. My colleague coaches and I spent some time putting a very reduce set of question ( 39 actually) for the 4 pillars of agility and the 3 levels.
Here are some example per category:
- Constantly refine “Minimum Viable Constraints” for the Value Stream ( Definition Of Done) & dependencies , Minimum Common Tools & Measurement ). Team self-organized for everything else.
- Team Stop developing as soon as a bug appears.
- Wip limit set for stories feature and other backlog item.
- Continuous Integration is in place.
- Stable cross functional team ( Feature team )
- Tester/Reviewer skills in each team.
- No one is taking a new task story or feature before checking we are ok on highest priority.
- Pair working used
- All Customers for the value stream defined.
- at scale , A full system demo is organized every iteration ( typically 2 weeks ) with all concerned customer attending.
- Team members sacrifice their own interests for the good of the team.
- Data driven retrospective at team level at each iteration and Inspect and Adapt with all stakeholder at release end. (Collective Intelligence)
- •Happiness Index is used to keep/improve motivation.
- Innovation Accounting used Upfront ( part of Definition Of Ready) to make sure to do the right things.
- People in the value stream feel their team is a place where they can speak up, offer ideas, and ask questions without fear of being punished or embarrassed.
- Team have time to expand their knowledge for both Agile and non Agile new skills and practices.
- Pivot: Abort iteration and Release when wrong with deep root cause analysis for learning.
Being Fake Agile is always a matter of comparing where you are to your expectation and expectation might be very different from one person to the others.
This always start by what is our desire. What are we trying to do better ?
Then we think why agile would do toward this goal and what It will not do. Sometime we ends up with no obvious solution, this is a place for experimentation following the lean startup logics.
Regarding company current state, There are many different tools. Kanban, Scrum , Safe, Less etc.. could be best approach but Agile is not a framework. Like Aikido is a way of adapting the spirit Agile is a way of adapting to the business spirit.
ICST Paris 2010 – Innovation in Test ; Raj Mudhar https://rmudhar.wordpress.com/2010/04/17/icst-paris-2010-innovation-in-test/
How Fake Agile At DoD Risks National Security: Steve Denning, https://www.forbes.com/sites/stevedenning/2019/09/22/how-fake-agile-at-dod-risks-national-security/#321e72278fa8