Scrum your Improvements back within 4 Sprints

“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:

The Problem:

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 1^st 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:

1. • 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!

Results are:

• 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

 

 

 

 

 

Inducting Quality In with Quality Retrospectives

As in Mathematics, so in Natural Philosophy, the Investigation of difficult Things by the Method of Analysis, ought ever to precede the Method of Composition. This Analysis consists in making Experiments and Observations, and in drawing general Conclusions from them by Induction, and admitting of no Objections against the Conclusions, but such as are taken from Experiments, or other certain Truths.
For Hypotheses are not to be regarded in experimental Philosophy.
— Sir Isaac Newton

Quality is by far the most crucial aspect of software development.

I would like to bring  life tested approach of retrospective practice focused on Quality – ceremony to focus on elimination of defects by understanding core issues and addressing required preventive actions, leading to less time spent on fixing those and gaining more time spent building features. Let us call them bugs (negative features that make software functioning not as expected).

As any Retrospective…

it has it’s 5 steps and here is how those are mapped to practical actions:

• Set the stage – focus on reviewing bugs resolved during period (e.g. past iteration);
• Gather data – prepare in advance extract of bugs;
• Generate insights – gathered during retrospective as soon as team passes bugs one by one;
• Decide what to do – preventive action agreed and written, having assignee (es);
• Close – short summary of the reviewed bugs;

What helps to make it efficient:

• Agreement on scope: what bugs are to be reviewed (production, staging, development, what severities, etc…)?
• Right people in: depending on scope and nature you may need to have not only development team members but also release coordinating operations engineers, product managers, etc.;
• In multi-team environment you may need to involve only some team members of every participant team, given who had participated and/or who is best addressing, lead engineers, etc.;
• Prepare in advance (e.g. take iteration, release, etc.. extract of all bug resolved, pre-sorted/pre-groupped by severity, …);
• Have mandatory field when resolving bug with your bug-tracker (e.g. Jira) that must contain technical reason for the bug + projected preventive action to be reviewed further by retrospective. Having this is very valuable as decreases time spent on “gather data” and provides more “space” for “generate insights”;
• Keep it short:  60 minutes is usually enough/sufficient if everything is properly prepared in advance and practice is regular;

Inductive approach (during retrospective):

As team is passing from most to less severe production bugs, they review each and make sure technical reasons are understood and proper preventive action(s) agreed. Then team decides who will own the preventive actions (given team setup this may be teams or individuals). In obvious cases like: bug was not detected by automated and/or unit tests when it should have been, bug is simply stays opened until action is in place (as it is best practice to have those as bug “definition of fixed”).

As soon as bug is discussed team analyses possible patterns for the reasons of the bug by writing down short summary of the bug’s origin.

And moves on with the next bug, etc…

Since approach is inductive: moving from the specific to the general here interesting findings emerge from reality and most “aha-s” and bigger problems become visible.

Here are real-life examples of bugs “patterns”:

• “release misconfigs”
• “old legacy codes”
• “hardware issues”
• “story misunderstandings”
• “quick = dirty fixes”
• “3rd party misconfigs”
• “localization issues”
• etc…

Of course it is good to prevent same bugs popping up again by addressing required preventive action(s) but is not just enough if you want to address the core issue.

The inductive approach here will allow team to focus on systematic problems and start effectively eliminating bugs by coming from particular life-cases, reality (reasons) to more “patternized” reasons and risks of having future bugs of the same nature/origin.

As an example Quality Retrospective may have also outcomes / actions like those:

• 3 compatibility issues / define list of supported browsers (+agree not to support the others, thus do not file bugs;
• 3 old legacy code issues / address with your architect (team), consider reworking;
• 3 misunderstandings / address with your product team how those occurred and refine story writing, grooming to avoid/reduce possible misunderstandings in the future.
• 2 design issues / agree to address design issues incrementally (stop demanding their fixes as bugs, …);
• 2 release miscofigurations / review release notes collection and approval mechanisms, reduce human factor;
• 2 translation issues / address with your product team how those shall be handled;
• etc…

Team may decide to address them from having biggest impact or from more severe issues or more systematic, but at this level they will be fixing the root cause rather than just a symptom (particular bug).

Advice to facilitators: manage time in the way to avoid burning all of it reviewing all bugs (you may not be able and/or it may be not even needed), rather focus on most important ones + detect “patterns” as early as you can.

How to address preventive actions and follow up

As in any retrospective, I’ve seen two approaches working here depending on the efforts:

• in next sprint task approach – action owner plans a task (or time, depending on action nature) in the next sprint. Usually works when effort is quite small;
• “top story” approach – for “bigger actions” plan a story of top priority in the subsequent sprint;

Consequently follow up is done either at the sprint review or on the next retrospective.

Some “Side findings”:

• You will figure out that some bugs are not actually mistakes as from the coding perspective rather than “logical gaps” in user flows;
• Some bugs are unavoidable and you may not need to prevent them (e.g. the risk of having them is acceptable from business perspective or preventive actions are too expensive compared to the consequences, …);
• Some “Invalids”, “Cannot reproduces”, “Duplicates”, “Won’t fix-es” and “Works for me-s” causing development team distraction and eating up time – at some extent this is still unavoidable but keep an eye on if you have increasing numbers of those;
• Some do not fit into any pattern (just exceptions);

Good luck inducting quality in 🙂

What goes up must come down: Sprint “Descent” Point

Plans are useless but planning is indispensable.
Dwight D. Eisenhower

What goes up must come down. This is true of aircraft in flight. Bringing an aircraft back to the ground safely is the primary concern, but it also is necessary that the return to the ground occur at the intended landing point.  The descent from flight altitude must be started well before the intended landing point is reached, and the rate at which the aircraft descends must be calculated, so that the aircraft reaches ground level just as it reaches the desired landing point. This controlled drop in altitude is called the descent rate.

Let us use these tips to learn how we can apply it for Agile development team.

The analogy here is very close…

Imagine team is a crew and airplane is the sprint, while burndown chart (CI, established NFRs, …) are navigation tools that allow to land sprint properly, with all passengers (stories) safe, at right airport (release) and on time (sprint review meeting).

So the crew must take into consideration many factors as altitude, distance to destination, aircraft descent velocity, weather conditions, fuel consumption, etc..

One of the key factors that allow to have successful landing of aircraft is choosing the correct descending point. You for sure remember that at some point you see “fasten your seat-belts”  sign on and flight attendants start asking you to follow the “landing rules”. This happens not right before airplane lands but some time in advance…

Similarly Agile team must consider many factors to get things done on time with required quality baked in (number of stories in progress, time left finishing development, regression testing left, meeting agreed non-functional requirements, preparing for the demo, etc. ). And shall start finishing things in advance to guarantee proper “landing”.

How much in advance?

It heavily depends on variety of factors: team maturity and confidence, extent team can rely on automated testing (and extent product is covered with automated functional testing), need to check for non-functional requirements, all kind of risks, etc…

Sprint (Flight) Plan and Descent Point

I will bring real life example.

In a picture below team had planned sprint in the way to start checking product on development environment in advance (while possibly working on integration defects), then deploy it on staging environment the last day of the sprint to make required final performance/load tests, confirm release/deployment plan and test application closest possible to the real life conditions:

Part of this plan presumed that in case all is OK, free team members will focus on less priority bugs, increase unit tests coverage, prepare for upcoming sprint, focus on past retrospective action items and do other valuable things. While plan changed of course, reflecting changing reality leading team inspecting and adapting accordingly and team moved descent point according to the joint decision.

But there is still difference…

While airplane landing is an example of waterfall project with QA (hardening) phase in the end (landing), it’s still differs from Agile. The more you do Agile right the more your team is mature, your product is safe, having more quality in and things are more automated. The more you apply  engineering practices and earlier you start integrating and testing things (continuously), the later you can start “landing” and the more passengers you’re capable to take (stories) and the shorter your “flight” will be (you will “Deliver Faster”).

Agile is verge of productive conflict: controlling gap between demand and offer

Before everything else, getting ready is the secret of success.
Henry Ford.

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 🙂