Archive for category Lean
“Make everything as simple as possible, but not simpler.”
– Albert Einstein
I am going to tell you a story of continuous improvement and how we have enabled those recently in our team of teams… I have picked this story up because situation at many companies is often quite similar:
Although many of them understand need for continuous improvement it gets hard to plan those together with features… and in practice implementations are often missing or poor:
- There is an increasing demand to deliver..
- Development teams are treated as “feature factories”,
- And no time to improve, no time to “sharpen tools” to be more efficient
- More pressure… risking improvements
And all this creates: feeling we are stuck, frustration, demotivates, affects efficiency and quality in longer run… and gets more complicated in multi-team environments… as it also includes agreements and collaboration factors between several teams…
We have tried many things and eventually were inspired by Jeff Sutherland’s Cycle of Scrum Master from Scrum@Scale …and here is what we have done …
But let us understand circumstances first… and how does process look from a single team perspective:
- Development team plans and runs their 2 week sprint…
- That ends up with DONE product increment
- And a delivery of it together with other 5 teams
- These 6 teams are sharing codebase, decisions, tooling and environments together + they deliver in the same cadence
- They talk regularly as Team-of-Teams to Inspect & Adapt their delivery process aka Team of Teams Retrospectives
- In the past they were trying to implement findings of those retrospectives, immedeattely but only few were really managed…
Sprint 1: so this made us thought how we can Scrum those improvements back in sprints…..
- We have obtained an agreement with Product Owner team to let each team pull at least 1 SMALL Task from that backlog per team / sprint and that this task shall be prioritized as a part of the default sprint goal
- We have also agreed within teams to file their improvements as tasks marked accordingly that comprise so called Kaizen Backlog
We have put these decisions into actions and felt results almost after a sprint…
Sprint 2: why we must wait to come up with improvements?…
- Apart from those any team at any moment can propose an improvement and for that thy can use SoS to share their ideas with peer teams
- Those ideas after acknowledged by other teams are also parked in the same backlog
Sprint 3: how to make sure Task is READY? Development of that lead to…
- Distribution of tasks happens latest 1st Scrum-of-Scrum of the sprint for the sprint after current. This we have done for creating enough pace for the teams to refine / groom those and size them so that they are SMALL.
Sprint 4: after a while we have noticed that it would be good to prioritize that backlog…
- Besides regular intervals ToT also joins forces in validating this backlog, checking prioritization, etc. This we call “Kaizen Triage Meeting”. After a while we have looked together at this backlog and understood that we have there 4 types of improvements:
- ProdQuality – Quality of Production (Live Product) is ensured, i.e.Monitoring, Logs, Live Tests
- DevQuality – Quality of Development (or soon to be released) is ensured…
- Efficiency – Saving Time for Development, …
- ProdPerformance – Performance of the product for end users
On top: We have also thought about some symbolic celebration …
- After team implements an improvement task, they get a STAR
- Default expectation 1 star per team per sprint, but in practice some try and did more…
- After each sprint we acknowledge how many STARS we have produced all together!
- Many small practical improvements fast
- Feeling of continuously “steering” our technology
- Increased motivation and feeling of ownership in teams
- Was measured by tickets inflow / outflow + happiness
This worked because:
- improvements were small, easier to plan, implement and deploy them
- therefore, they are also less risky to do
- process is simple lightweight, easy to follow
- shorter improvement cycle allows faster response
- queue of the backlog is short and manageable
Before everything else, getting ready is the secret of success.
Many of us doing Agile do not understand that it is primarily business mindset, rather than just another methodology to deliver software. Balance and sustainability of constructive conflict (key driver of any prosperous business) is the secret sauce to implement Agile successfully.
Let me explain it from practical business perspective. I will drift away from IT and software now…
Imagine you’re running business delivering…. car repair services to your customers.
It is your interest to deliver services fast and having quality in, so that you retain your customers and attract more (as it’s known that satisfied customer may bring 1 or 2 others, while dissatisfied one may stop other 8 coming to you). On one hand the more services you deliver, the more money you get, so you will push for more. But if you start pushing harder than your team is capable of, your service quality will start to suffer and this will obviously cause problems with your customers.
So you will try to get as much as possible given your conditions, while keeping quality in.
Now let us look at it from your customers perspective…
They want to have their car repaired cheap, fast with quality in. When you say your’re busy this week and cannot take their car, they will consider someone else’s services, rather then agree waiting that log (reality of market competition);
So, there is conflict of interests and mismatch between demand and offer.
It drives 2 things:
- Your business development (we need to improve our service to deliver faster/more/cheaper);
- Your customer’s expectations (maybe these repairs are not doable that fast/that much/that cheap);
Two consequences out of that:
- When there is no demand, why should you care to do more/faster/cheaper?
- When there is no chance to change your customers expectations either you’re doing poor job or your customer won’t likely get any better services with reasonable price anywhere else (task for your client managers to drive customer’s expectations).
So mismatch of those two creates conflict of interests that drives change.
The art is to understand to what extent you’re capable to improve things at your business given your current circumstances, while managing your customers expectations in the way to have control over gap between your offer and your customer’s demand.
Controlling this implies another important thing: ability to recognize challenge that you will fail taking (you should constructively resist) and challenge you’re able to overcome (and should take) to improve and continue managing “the gap”.
If you do not understand this you will end up bad. Either you will not be able to deliver quality in to your customers or you will be “beaten” by your competitors. In both cases you will end up being out of business :(.
Now let’s come back from cars to software and Agile
Customer is Product Owner (PO), while your business is your development team. The more you think business-wise and consider your team a business the better your team will be satisfying your PO.
So it is as easy as managing just 2 things:
- Your PO’s expectations;
- You development (quality and predictability);
Agile is just business common-sense mindset, nothing else! So to implement it right start from considering that you run a business in a highly competitive market with goal to satisfy your customer.
And mind that there is difference between pleasing and satisfying your customer, so argue, stand for your point, do not let compromise quality, do never over-commit, protect your ability to deliver, manage expectations, and … satisfy. If you do not follow these simple business rules and will focus on just pleasing your customer (or PO) just as in business you will end up not being able to manage what you’re responsible for – QUALITY.
Good Luck 🙂
Recently I observed an interesting trap one team fall into. When asked how confident guys feel about hitting the target, they was almost jointly saying they’re absolutely confident, however burndown chart trend told me they won’t make it.
Well, I am absolutely sure that this is what we all want to have – 100% confidence, however here’s the dangerous trap.
We may stay satisfied and oversee problems (or pretend that tomorow the problems will be gone). Or try not to rise them. Or feel uncomfortable rising them. Or think that others will feel uncomfortable if we raise them, etc…
But, they will NOT disappear. Problems usually have tendency to pile up… And when such a team recognizes that, it’s already too late…. and painful.
Kaizen mindset and “Toyota way of Lean Leadership” cultivate culture of “continuous crisis” that requires continuous improvement . Only having daily cultivated feeling of urgency and need, maintains the rhythm of tense and productive environment that reduces risk of facing a FAILURE.
As Toyota management team stated in 2010:
“We realized we need to develop a grater sense of urgency, in our business. Success is good, but without urgency serious weakness sets in, customer focus declines, creative ideas dry up and before you know it, you’re in trouble”.
So here is the trick to recognize: before you know it, you’re in trouble.
But the word and concept has negative tone and may have de-motivating impact on a team. How to make it distinct and positive?
Here is an advice…
Unlike panic or hysteria, urgency is a constructive, ordered and focused sense, therefore it should not de-motivate. Simply because it results in targeted and the only correct decision and action. Deffer commitment + deliver fast, guys!
To illustrate this imagine fighter aircraft pilot that needs to make the only correct decision and act accordingly within 10 seconds left before he may crash. And here is the difference that also proven by multiple real-life cases:
- Panic: an ordinary pilot most likely starts to hit all buttons around (maximizes focus and work-in-progress) or worse, thinks about death (we will fail…), not believing that this happens to him (we will not fail, I do not see problem, it’s not about us/me…);
- Urgency: trained pilot usually freezes for 7 seconds (analysis, defer commitment), makes decision, then within 3 remaining seconds quickly does (focused, fast) the only correct action to stabilize aircraft;
Feel the difference?
A takeaway is simple: stay open-eyed with reality, constantly challenge your confidence, do not fall into trap of satisfied optimism, distinguish among your will and reality, spread urgency around and stay hungry © for constant improvement.
Came across an interesting study (Quality Software Management: Systems Thinking by Gerald M. Weinberg) that draws relation between number of tasks in progress and time wasted for context switch.
So if you are running two projects (do two tasks) paralleled, waste caused by brain context-switch is 20% (and you’re able to use effectively only 80% of your time), for three it’s getting worse – 40% wasted (only 60% used), etc…
The mechanics behind are simple: according to psychiatric studies when our brain is juggling different tasks, it is also trying to arrange focus and attention to those tasks. Therefore when we attempt to perform two complex cognitive tasks, the brain must shift its focus to manage one task at a time. This process is identified as “reaction-time switching costs” and represents a measurable period of time in which the brain is moving its focus from one task to another pretty much as computer’s CPU does.
The other consequence is that we get tired earlier, since switch itself eats-up brain energy and we are not able to do 100% switch (we’re not CPU, we’re humans!), so it is more like having main part of brain focused on one task, while some small part of it still stays with next (past) one.
All this makes limiting WIP (work-in-progress) vitally important to both productiveness and human health.