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]
I was recently approached about the relationship between Systems Thinking, Lean And Agile. Without going into too much depth and using too much terminology I have tried to summarise it in the following diagram.
Agile is an iterative and incremental approach for developing product and services through collaboration between self-organising, cross-functional teams. It promotes adaptive planning, evolutionary development, early and continuous delivery, continuous improvement, and encourages rapid and flexible response to change.
Lean is a management mindset and a set of tools to create customer value, using the least amount of human effort, capital, inventories, time and capital investment in the process. Lean focuses on continuously improving work processes, increasing throughput and flow and removing waste.
A system is defined as two or more parts that work together to accomplish a shared aim. An organisation viewed as a system consists of not only its departments but also all of its interactions (both internal and external) including customers and suppliers. The success of all workers within the system is dependent on management’s ability to optimise the entire system.
Systems thinking is about:
- looking at the whole instead of focusing on components
- understanding components within their context, not in isolation
- paying attention to the interactions between components
- seeing cycles instead of linear cause and effect
By thinking of their organisation as a system, managers can begin to understand and address the problems facing them, their staff and their customers. W. Edwards Deming, an American statistician and management theorist, found the majority of possibilities for improvement are in the system (95%) and the remainder are with the worker (5%). He learned that if you want to change behaviour, then change the system.
Last week I attended the LAST Conference (Lean, Agile, Systems Thinking) held at Swinburne University. The LAST Conference is a big departure from the Agile Australia 2012 conference I attended earlier this year. There was no fanfare, no big build up, little corporate advertising and significantly less people. It was also only $50 for the whole day but still contained lots of learning opportunities. It lived up to the advertised “low cost, grassroots mini-conference” message.
The conference schedule contained 5 parallel tracks so it was hard to attend all of it. I found myself at times wandering between sessions to get sound bites of what people where talking about. Being held at a uni one thing I definitely liked was the university lecture theatre style of some of the sessions – it felt right compared to sitting in a large conference center. Unfortunately, I couldn’t stay for the last sessions as I needed to head back into work.
I didn’t take any detailed notes, but here are my takeaways (in no particular order):
- Systems Thinking is the opposite of scientific thinking. Systems Thinking is not:
- Rocket Science
- Sea of Systems a handy guide to Systems Thinking
- Invention is the process of discovering something new or come up with an idea. Innovation is the act of of introducing that idea into the market and commercializing it
- Played some neat games that help with agile learning.
- Stages of learning:
- Unconscious incompetence
- Conscious incompetence
- Conscious competence
- Unconscious incompetence
- I had lots of fun in the Visual Collaboration session fine tuning my sketching skills. Use Wong-Baker Faces to visually represent levels of pain.
- Lots of interesting tidbits some of which I already knew but others just heard of in Edgy Agile things.
Here’s a selection of twitter posts on the conference (#LASTconf):
- @RonicaRoth: #LASTconf motto: you are not an attendee. Excited to participate!
- @lynnecazaly: Story structure: people + place + trouble …people want to know why, why this, why different #lastconf @unorder
- @hwiputra: A good storyteller uses concrete words not abstract words #LASTconf
- @hwiputra: Be comfortable with silence when getting stories out #LASTconf
- @AgileRenee: #LASTconf how to measure value? IRACIS – improved revenue, avoid costs, improved service
- @AgileRenee: #LASTconf my answer: the biggest waste in software dev today is doing the wrong work (benefits to cost don’t stack up)
- @libodyssey: culture is the product of behaviour #lastconf
- @ScrumMasterNZ: Work towards “Decision Meetings” and not “Status Meetings” #LASTConf #agile #lean
- @jodiem: Eg this guy has 3 levels of backlog – team-product , release-quarterly and sprint… #confused #lastconf
- @CEPitchford: The motivation for #offshore at REA was not cost it was talent! #win @hwiputra @frankmt #LASTconf
- @CEPitchford: Standup with #offshore team via Skype was hard. We couldn’t understand each other @hwiputra @frankmt #LASTconf
- @CEPitchford: Was hard for Chinese #offshore team to get visas to come to OZ @frankmt @hwiputra #LASTconf
- @CEPitchford: The whole local OZ dev team went to china for 3 weeks to handover to the #offshore team #LASTconf
- @AgileRenee: Find I’m mentally disagreeing with a lot said in the offshoring session in #LASTconf we have talent and should invest in building it locally
- @jodiem: Self service test environments… Where QA env is exactly the same as production env. Cool #devops #lastconf
- @antomarsh: Team rotation from Aus to China critical #LASTconf
- @gusbalbontin: Words such as “framework” and “governance” should never be in the same sentence as the word innovation. #LASTconf
- IrithWilliams: #Lastconf the real job at a standup is to ‘listen, inspect, adapt’
- @magia3e: Too many context changes slows down the #scrum team. Focus on getting to-do done #LASTconf
- @rooosterboy: How is #LASTconf different to #agileaus ? Seriously.
- @magia3e: If u don’t have some sort of continuous integration toolset/capability it will limit your velocity #LASTconf
- @c2reflexions: @AgileRenee doing a song and dance at #LASTconf
- @magia3e: Document the right stuff, but don’t waffle it out. Cut to the essence of it. communicate it with the right collaborative tools #LASTconf
- @CEPitchford: More control from management = less innovation from empowered teams #LASTconf @frankmt
- @CEPitchford: It’s not about execution anymore. It is about learning. #organizationalchange #LASTconf @frankmt
- @CEPitchford: Change programs: do we actually want to change? Or adapt, innovate and LEARN? #purpose #LASTconf @frankmt
- @CEPitchford: The way we still run companies was invented by people who lived in the last century @frankmt #LASTconf
- @CEPitchford: Project schedules and budgets are a work of fiction anyway @brown_note #LASTconf #fishbowl
- @hwiputra: All good leaders believe in their teams. #LASTconf
- @Drew_1609: Best value and most fun conference attended in a long time #lastconf
- @njhoughton: MVP … what’s the minimum thing to go-live … hold this as a meta-frame as you sprint … my examples are #foresight and #Innovation #lastconf
The visual recordings by @lynnecazaly were done using the iPad Brushes app. I have downloaded the app and now I just need to brush up (no pun intended) my skills. Thanks Lynne for the inspiration to try visually recording my notes.
Thanks to the organisers, Craig and Ed for putting together this great event. Snaps!
In the book Switch: How to Change Things When Change Is Hard by Chip Heath & Dan Heath, the authors described the results of a study to answer the question: Would people with bigger popcorn buckets eat more at the movie cinema?
As part of the study, it was carefully engineered to serve the popcorn five days stale. Some people received medium sized buckets and others got a large bucket. The results were stunning:
People with the large buckets ate 53 percent more popcorn than people with the medium size. That’s the equivalent of 173 more calories and approximately 21 extra hand-dips into the bucket.
The book further states that other popcorn studies were always the same:
It didn’t matter if our moviegoers were in Pennsylvania, Illinois, or Iowa, and it didn’t matter what kind of movie was showing; all of our popcorn studies led to the same conclusion. People eat more when you give them a bigger container.”
No other theory explains the behavior. These people weren’t eating for pleasure. (The popcorn was so stale it squeaked!) They weren’t driven by a desire to finish their portion. (Both buckets were too big to finish.) It didn’t matter whether they were hungry or full. The equation is unyielding: Bigger container = more eating.
Recently in To Change Culture, Change the System David Joyce says:
Deming learned it’s not a problem of the people it’s a problem of the system that people work within. He found that if you want to change behaviour, then you need to change the system, and change management thinking that creates it. Doing so, culture change is then free.
To change someone’s behaviour, you’ve got to change that person’s situation.