Agile Adoption Category
My presentation at last year’s LAST Conference 2015 titled “Agile Start Me Up – Using the Minimum Viable Discovery (MVD)” is available on Slideshare.
A bad system will beat a good person every time.
– W. Edwards Deming.
I believe that everyone does their best given the context and environment at hand. I subscribe to Deming’s views that it is the organisation as a system, not the people working in the system that determines the organisation’s performance. The other view is that the people, not the process or the organistation, is the source of low performance.
Due to the inherent complexity and variability of product development it is often difficult that the scope, details, or effort commitments estimates are certain. When things fall behind schedule (or finish ahead of schedule for that matter), it assumes that the original plan was correct in the first place, but this is often not the case. Plans often over-simplify the complexity of human interactions and creativity. Many of the challenges faced by teams today isn’t necessarily related to technology but can be described as a social problem – product development teams is a complex adaptive system that requires collaborative actions and shows complex behaviour as it adapts in and evolves with a changing environment.
So when there is a performance gap (actual performance vs desired/planned performance), there are generally 3 options that are considered:
- Add more people (or resources)
- Work harder
- Improve performance
Option One of adding additional people may make things later as described in The Mythical Man-Month Is Not A Myth. This option is also has budgetary and financial constraints and managers are reluctant to go down this path.
So when there is a performance gap, there is pressure for managers to close this gap to meet the original commitments by pressuring people to spend more time and energy doing work by working harder often in the form of overtime (Option Two). This is played for an apparent short-term win. This quick-fix reaction results in shortcuts which have a relatively long-delayed and indirect impact – it may be sometime before the decline in performance or capability is known. This is one way how technical debt occurs and requires more effort to maintain a level of performance. This technical debt often never gets rectified as managers deal with the next performance gap problem, and things get worse reinforcing the downward spiral. This option is a popular strategy as it solves today’s problems and meets the immediate KPIs.
The Third Option is improve performance through investment in training, applying agile and lean-thinking strategy of removing waste to improve the flow of value and experimenting with new ideas. Time spent on improving the capability of a process typically yields the more enduring change 1. An hour spent working produces an extra hour’s worth of output, while an hour spent on improvement may improve the productivity of every subsequent hour dedicated to product development.
In an MIT supported paper by Repenning and Sterman they observed that working harder (eg overtime) wasn’t merely a means to deal with isolated incidents, but is instead standard operating procedure. I have frequently overhead team members say “that is normal, we are used to it” when presented with overtime work. Agile Manifesto Principle #8 states that
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Some overtime work may be justified but don’t rely on constant overtime to salvage a plan.
When the focus is constantly on production work people are often “too busy delivering”, and working overtime and harder quickly becomes routine, we have no time to improve or learn. Capability starts to decay and as a result, the performance gaps increases forcing the need for heroic efforts (that are rewarded) and people to work harder and longer hours which takes them further away from improvement. This is sometimes called being in a constant “fire-fighting” or reactive mode.
Increasing pressure to do work (delivery) leads people to spend less time on non-work activities like breaks and to put in overtime. For knowledge workers such overtime is often unpaid and spills into nights and weekends, stealing time from family and community activities. There are, however, obvious limits to long hours. After a while there is simply no more time. If the performance gap remains, workers have no choice but to reduce the time they spend on improvement as they strive to meet their ever increasing objectives. -Repenning and Sterman
A key principle of Lean and Agile is to continuously inspect and adapt the way we work so we can improve the way we deliver to our customers. Agile Manifesto Principle #12 is about making improvements to the way you work continuously,
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
One way to improve is to do regular retrospectives and operation reviews and then spend some time on the identified improvement activities. Kaizen, the Japanese word for continuous improvement, was popularised by the Toyota Production System. The culture of Kaizen is one of the reasons why Toyota has been more successful than many of the Western firms. Kaizen is about making small improvements continuously, so we can get 1% better every day. Just like compound interest on your savings account, overtime these 1% improvements can provide significant performance gains. As the performance gap falls, workers have even more time to devote to improvement, creating a virtuous cycle of improved capability and increasing attention to improvement.
However, there sometimes can be a delay before the benefits from the improvement efforts will be realised, so you need to have a strategic view and an emphasis of investing in improvements. Treat each improvement activity as an experiment and learn from your mistakes.
As illustrated below, working harder results in an immediate performance impact at the expense of improvement work but has a delayed capability trade-off in the long run. Whilst working smarter requires some investment in improvement that will require a short-term negative performance impact before things improve but has a longer lasting productivity gain. In reality, both of these continuously reinforce each other with each decision loop either having a virtuous cycle of reinforcing the performance curve positively (working smarter) or a vicious cycle lowering performance (working harder). Which one will you choose?
Note about the ‘Too Busy To Improve?’ image:
This image has been adapted from Hakan Forss’ work. His ‘Too Busy To Improve’ image is not free to use so I have adapted his image which can be shared under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license. Whilst this image is not as evident as Hakan Forss’, it hopefully still convey’s the same theme. You may share my image but you cannot create a derivative of it to respect Hakan Forss’ intellectual property. I would like to thank Hakan Forss for allowing me to adapt his work.
1 Nobody Ever Gets Credit for Fixing Problems that Never Happened, Repenning & Sterman, California Management Review, 2001
[Thanks to Daniel Prager (@agilejitsu) for passing on this paper]
It is not the strongest species [organisation] that survives, not the most intelligent, but the one most responsive to change.
Over two jam packed days, there were a lot of new ideas to experiment with but there were also some basics to cater for those just starting out on their agile journey. The vibe at the conference is that Agile is no longer a fad and is transforming across the wider organisation – we have crossed the chasm from IT agility to business agility. However, speaking with people from the trenches there are still many struggling to get the benefits of agile with existing hierarchical management style at odds with the horizontal product delivery focus of agile. James Shore summaries this well when he said
agile is about how you think and that organisation thinking overrides team thinking. Therefore success with agile depends primarily on organisational culture and investments.
Here’s some highlights from the conference:
David Marquet (@ldavidmarquet) – Intent-based leadership
David Marquet is a former nuclear submarine commander and author of the book ‘Turn the ship around‘. His opening Keynote looked at the future of Leadership.
- In the future leaders will get people to think (not do)
- In the future Leaders will help people feel safe (not scared)
- In the future leaders will push authority to information (not information to authority)
- People doing the work can make better decisions because they have the information. You will get better speed of execution because you don’t have a delay.
- In the future leaders will focus on getting better (not being good)
- In the future leaders will fix the environment (not the people)
- In the future, leaders will give control & take leadership
- The only thing hard about this is you, we have been genetically and culturally to take control and attract followers. What you want to do is give control and create leaders.
During his keynote, David did a live poll of the audience on what it would like to work in an environment where the leadership style meant controlling people . I hope the managers and leaders in your organisation are not creating a work environment like this….
Jeremie Benazra (@jemben) – How forgotten knowledge will help you avoid regrettable decisions
Jeremie’s presentation took a interesting look at turning some common questions we may face into reality checks using some common principles that we know today. Whenever we make decisions we need to be grounded (and often reminded) that there are certain principles that may challenge our biases.
|Principle||Question you want to ask||Question you should be asking|
|Moore’s Law: Information systems doubles capacity for the same price every two years||“Which technology is the best to invest in now?”||“How long do we want to maintain the product using this technology?”|
|Allen’s Curve: The communication efficiency decreases exponentially with the physical distance between the persons||“How much could I outsource?”Or what I come across a lot is a statement that “outsourcing is cheaper”.||“How much effort are you ready to dedicate to make outsourcing work?”|
|Parkinson’s Law: Work expands so as to fill the time available for its completion||“How long do you need to get this done?”||“Do you have any time constrain? What is your deadline?”|
|Little’s Law: The lead time is proportional to the number of items in the system and their time in the system.||“Tell me when I could expect to get this done as well?”||“How urgent is it compare to what is currently in progress?”|
|Meskimen’s Law: There is enough time to do it right, but there is always enough time to do it over.||“How complete are you? How far along are you?”||“Could you help me clarify what we consider complete?”|
|Brooke’s Law – The Mythical Man Month: Adding manpower to a late software project makes it later.||“How many people do you need to get this Done? Faster!“||“What are you ready to trade off, scope?”|
|Conway’s Law: Organisations are constrained to produce designs which are copies of their communication structures||“How could you improve our customer experience?”||“How could we remove some organisational silos to work better together?|
Bernd Schiffer (@berndschiffer) – Concrete experimentation in Agile environments
Bernd talked about a problem that many organisations face today, struggling turning change ideas into tangible outcomes so they get better at being Agile. What we need is a way to use experiments to drive change throughout the organisation and Bernd introduced a nice mnemonic to help us remember how to perform an experiment to drive change and improvement – CAT SHOE, SIC! It’s really simple of course:
- Clear goal – what are the outcomes you want to achieve
- Arranged – A plan how you will approach the experiment
- Trackable through metrics – measure the improvement/change. did it have an impact?
- Small – make small incremental experiements, short timeframe, small/one team.
- Has due date – do I need to say more? timebox the experiment
- Out in the open – make the experiment visible eg use ganban boards
- Evaluated through hypothesis – leveraging the lean startup approach, what hypothesis are you trying to prove? what does success look like? what does failure look like?
- Safe-To-Fail – it is an experiment after all so we need to take some risks, but balance risk taking with impact if it fails. You need to be able to recover (and learn) from failure
- Impelled by champions – need people (1 or 2) to sponsor and champion the experiment – they will own the outcome and be impelled to make it happen
- Communicated before start – be transparent and make sure everyone understands and is comfortable with the experiment before starting
Stuart Bargon (@StuartBargon) – Don’t scale Agile. Descale your organisation.
Anders Ivarsson (@anders_ivarsson) – Autonomy and Leadership at Spotify
Linda Rising (@RisingLinda) – Myths and patterns of organisational change
|Myth||Pattern for Change|
|Myth #1: Smart People are rational
||Take on a role of a Evangelist.You need to believe and have a passion for the change. What you have is your belief that your idea is a good one and that it will work.Create short term goals – build on your successes and learn from your failures – do small experiments, just do it, time for reflection, baby steps.|
|Myth #2: Good always triumphs over evil. (Just World Fallacy, one of our many cognitive biases.)
Data clearly shows, that when we are eating we are more open to influence.All languages speak to this connection. When we eat together, there’s a feeling these are the people we trust – its a great influencer even if its a bad idea.
|Myth #3: If I just had enough power I could make people change.
||Personal Touch.You must address a genuine user need. Data does not equal empathy. You need to reach out and try to understand the viewpoint of people who you want to change and give them a reason (sell your idea as a way for them to be better).Different people accept new ideas differently, so you will need to address people differently and answer the “What’s in it for me?” and bring them along the journey.|
|Myth #4: Skeptics, cynics, resistors—THOSE people, well, they must be BAD or STUPID or BOTH!! Ignore them!!
||Fear LessUse resistance to your advantage.
Listen, really listen and learn all you can, even from the cynics. Respect and build on the resistance.Find a Champion Skeptic: Encourage a resistor to play the important role of “Devil’s Advocate.” Treat the person as valued partner in the change effort. Get them to help get better.
|Myth #5:You’re a smart person, so you don’t need help from others. After all, it’s your idea!||Ask For HelpThe idea is yours and you believe in it, but the change must NOT be “all about you”.You need other people’s help. And when others help you, recognise their contribution with Sincere Appreciation – this is a powerful influencer! The thanks must be sincere, timely, contain details of what they did and the impact of their help.|
Recently I was posed the question “how can we shape organisations to be successful in an environment of digital disruption?”
The convergence of technologies, such as cloud, social, mobile and information (the Nexus of Forces) …. are driving the Digital Industrial Revolution (Gartner). The convergence of these technologies has formed what Fred Wilson has described as the Golden Triangle:
“The three current big megatrends in the web/tech sector are mobile, social, and real-time.”
However, technology is just one part of the digital disruption equation. You can forget about digital disruption if you don’t disrupt your existing (traditional) business models.
Over the years oragnisations have updated their technology roadmaps and invested in new technologies to support their business strategies. Yet organisations have retained their legacy processes and policies and have not adapted new ways of working to compete effectively. Most organisations are built to sustain their existing business models which are not geared towards creating digital experiences for customers. Existing governance structures are often too slow, too siloed, stifles innovation, adds bureaucracy and all too inconsistent.
Increasingly organisations are embracing new paradigms and principles in the way they work in the era of digital. Many of these incidentally come from Agile and its related areas such Lean, Kanban, Design Thinking, Systems Thinking, and Lean Startup. Take for example the U.S. Digital Services Playbook:
- Understand what people need
- Address the whole experience, from start to finish
- Make it simple and intuitive
- Build the service using agile and iterative practices
- Structure budgets and contracts to support delivery
- Assign one leader and hold that person accountable
- Bring in experienced teams
- Choose a modern technology stack
- Deploy in a flexible hosting environment
- Automate testing and deployments
- Manage security and privacy through reusable processes
- Use data to drive decisions
- Default to open
and the UK Government Digital Services Design Principles:
- Start with (user) needs
- Do less
- Design with data
- Do the hard work to make it simple
- Iterate. Then iterate again.
- Build for inclusion
- Understand context
- Build digital services, not websites
- Be consistent, not uniform
- Make things open: it makes things better
Adoption of an Agile models, Lean Principles, a lean way to create a business model and a way to continuously innovate is vital if you want to compete effectively. These (modern) delivery models and principles no longer play a supporting role, but are center stage – it is becoming essential to the success of businesses in the age of digital disruption.
None of the principles and policies by the U.S. Digital Services and UK Government Digital Services is about technology. They are more about how work and business is to be done. The companies that will be successful in the disruptive digital era will be those who look beyond technology solutions but also disrupt their traditional organisation and governance structures and invest in new business models.
The digital disruption is forcing businesses to change how business is done. This requires a business transformation that uses technology to create digital experiences for customers AND equally adapt or introduces new processes and systems to successfully compete. Through evolution of work design, organisations need to adapt and change processes and policies (and we are not just talking changes in IT only). This will be BIG – it means changing one way of being to another. A butterfly is nothing like a caterpillar.
 W. Edward Deming defines a system as a network of interdependent components that work together to try to accomplish the aim of the system. In this case the system is not an IT system, but the organisation as a system.
“One of the big success factors at Spotify is the Agile Engineering Culture.” – Henrik Kniberg
Spotify started as a Scrum company in 2008 but the standard Scrum practices were getting in the way as they grew, so they made them optional. Here’s an awesome video how Spotify scaled their Agile Engineering Culture. They decided that:
- Agile matters more than Scrum
- Agile Principles matters more than any specific Practices
- Agile Coach is needed rather than ScrumMaster (Servant Leaders more than Process Masters)
Kaizen (改善), Japanese for “improvement”, or “change for the better” refers to philosophy or practices that focus upon continuous improvement of processes.
Teams I coach frequently ask me for “best practices”. Do not assume that “best practices” in previous projects will be equally successful in another project. In some cases, “best practices” from one context can be counter-productive in another context. Practices and processes from previous projects should be used for learning and improvement. No practice or process is both complete and optimal – once we master it at one level, we see deficiencies that were previously hidden and the cycle of improvement begins again. You should always challenge yourself to experiement and find better ways of doing things and beating your own standards for excellence –
Improvement usually means doing something that we have never done before.
— Shigeo Shingo
Mistakes are a part of being human. Mistakes are not a sign of failure. Appreciate mistakes mistakes for what they are – precious life lessons that are used for learning and for others to learn form. Part of continuous improvement is learning from mistakes. The only failure is the failure of not learning from your mistakes.
Insanity: doing the same thing over and over again and expecting different results.
— Albert Einstein
James Hird, the coach of the Essendon Football Club (a team in the Australian Football League (AFL)) took over the coaching of a team this year that was struggling to win games in recent years. A priority for Hird was improvement in the team – “We’re trying to push for continual improvement.”
The club started the season well winning several games, however, they also made many mistakes along the way and had some big losses. The club learnt many valuable lessons from those demoralising losses which enabled it to obtain an all-important victory against the best team in the competition. One of the team players said:
“The coaches were never too up when we won and they were never too down when we lost.”
“The coaches are all just about learning, evolving and improving.”
Even when the team won games and making the finals was in sight, it was still about improvement and getting better. Hird is solely focused on continuing to develop his team – “improvement first, finals second.” Through continuous improvement, Hird believes they will build a good team that can compete effectively and achieve the goal of winning a finals premiership:
“Whether or not we make the finals this year… in 18 months time we want to keep coaching and teaching so we do become a good team.”
“Our team is not built on superstars it is built on all-round effort across the board.”
In a previous post, IDEO had a fail safe culture and which allowed them to fail often in order to succeed sooner:
Enlightened trial and error succeeds over the planning of the lone genius.
It is important organizations foster continuous learning so teams constantly get better at everything they do—improving their work, making decisions, holding good meetings. That’s why successful teams emphasize continuous learning, always going over what they’ve done, identifying what went well and what didn’t, and finding ways to get better the next time around.
The following from Gemba Panta Rei highlights the importance of learning from mistakes through continuous improvemment:
Here are three important lessons from Irish novelist and playwright, winner of the Nobel Prize for Literature, and wicked wit George Bernard Shaw:
“A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing.”
We often say that continuous improvement depends on the ability of people to experiment, make mistakes, reflect and learn from the mistakes. It is truly honorable when leaders create an environment in which it is safe for people to experiment, fail and learn. In fact it may take more courage to allow others to make mistakes than to make mistakes oneself. The good results of these experiments we call kaizen, and the learning that occurs from poor results we call development of human potential. When we achieve good results free of mistakes we call it competence, but mostly it is luck.
“The power of accurate observation is commonly called cynicism by those who have not got it.”
While opinions and ideologies can be had and held with only minimal effort from our armchairs, facts require that we put forth some mental and physical effort. The act of observation requires presence and attention, the accuracy thereof open-mindedness and the will to release held opinions when they conflict with observed fact. Seeing the truth can be uncomfortable. Having truth that conflicts with one’s belief can be even more so. Pointing out the misconceptions in the minds of others can result in being called cynical or worse. Accurate observation must be preceded by and paired with education, alignment and commitment to act to improve a situation, regardless of our preconceived notions in order for continuous improvement to take root.
“The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.”
I am an Agile Plumber – I eliminate waste, remove blockages and increase flow.
This week we had an agile workshop to establish some goals and create some epics for next quarter’s release for the agile change team at an organization I am coaching.
One of the items we covered in the workshop was to come up with a new team name for our agile change team as a result of some organization changes. Some of the names included:
- Agile Change Team (A.C.T.)
- Agile Capability Delivery Centre (AC-DC)
- The Enablers
- Centre for Agile Practices
….and there were many more.
When we went to vote on a name, a clear winner was Agile Plumbers. This name was quite humorous at first and we all got a good laugh, but the name is symbolic and there is some serious intent behind it.
An important aspect of agile and lean is about eliminating waste, removing blockages, and increasing flow which can really can change the way you build software.
There are many forms of waste including partially done work, extra processes, extra features, task switching, waiting, motion and defects. By looking at the waste that is in the steps you are doing and removing the waste you can do more with less.
We also have failure modes because we’re not paying attention to what it really takes to be agile. There are many roadblocks and blockages to getting to success. There are roadblocks that occur within teams and projects, but there are larger organizational roadblocks which are impediments to any agile approach. Agile touches on many aspects of an enterprise organization and changes many existing organizational processes that are more acquainted to waterfall. Examples include:
- Procurement, such as selecting and working with vendors.
- HR, especially what type of people we want to recruit, and changing manager’s KPIs to align more with a collaborative culture.
- Finance, how we structure the organization’s funding model to align with agile approaches and incremental delivery. Also funding may need to change to support a lean pipeline of work (continuous flow of work), rather than ‘individual projects’.
- Legal, how we write contracts that support agile teams and approaches.
- Training, creating training programs for agile (not only including agile specific topics, but also leadership and soft skills that are required in a collaborative organization).
- Governance, most traditional governance does not work with agile.
- Add your own organizational impact and blockage here that needs removing.
Finally, a goal of lean and kanban is increasing the efficient delivery of value through limiting the work in progress (WIP), making work visible and increasing the overall flow. Optimizing the entire value stream, from initial concept to consumption is fundamental to increasing flow of value through the organization. The idea is to get an idea into the development pipeline and out to the customer as fast as possible by looking at the existing processes and improving them and in the process eliminate waste and create value.
The other advantage of being called an Agile Plumber is that the name creates an memorable impression. In a large organization with many business units and organizational teams, one thing that can be difficult is being able to identify where agile help can be found.
So next time you need someone to help eliminate waste, remove blockages and increase flow, call your nearest Agile Plumber!
This is all too funny! Whilst the video is intended to be humorous, the pain of the “Agile Guy” maybe all too familiar for some. Agile changes many things we have become use to over many years – agile questions the status quo and challenges our muscle memory……..
Most people associate daily stand ups or daily Scrums when they think of Agile. And they are often the first practice that is adopted. I have observed some teams adopt the daily stand ups and a little of other practices (often with smells/anti-patterns) and say they are Agile.
The adoption of agile methods and practices is clearly producing enviable results by improving quality, time to market, productivity, increasing transparency and ROI. Agile is simple, but it is not easy. Few things that are truly worth doing are easy to do, and the adoption of Agile is no exception. As a result there is a propensity for Cargo Cult Agile teams looking for a silver bullet.
Cargo Cult refers to a phenomenon during World War II in the South Pacific where the natives observed what the Allied Forces were doing. The natives were not aware of the modern civilization, however, they did observed that certain actions of the military resulted in supplies of food, clothing, equipment and various other cargo being air dropped. When the war ended, the flow of goods and cargo ended too. Not understanding the underlying mechanisms for the delivery of cargo and in an attempt to attract further deliveries, the natives engaged in ritualistic practices such as building crude imitation landing strips, aircraft and radio equipment, and mimicking the behavior that they had observed of the military personnel operating them. However, no matter how well they mimicked the military actions, the cargo did not return.
In Agile we sometimes behave like Cargo Cult by imitating the superficial Agile methods and practices without having any understanding of the underlying essence. We adopt the daily stand up meeting because it is easy to do and many Agile teams use it. However, if the team is synchronized, communicating and collaborating well, the daily stand up may not be required.
What works for you, your team, organization, etc. can bring another person, team, etc. to a screeching halt. No practice will work for everyone or every team in every context. Before adopting any practice or technique, you should ask yourself does it make sense and does it align with the Agile values and principles? Does it help me deliver software more quickly to my customers? Does it help with achieving technical excellence? Will it help my team to be more effective?
You not only need to know the ‘what’ of Agile but also the ‘why’. Just because jumping jacks works for someone else, it may not work for you.