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

Inducting QualityQuality 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 :)

Leave a comment

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”).

Leave a comment

Daily stand-ups: second scenario of effective alignment

I’d like to share the way I used to run daily stand-ups. Depending on the case I use two models.

Team members attending mode

Usual team stand-up to align on daily progress. Yesterday-today-impediments questions applied to each team member.

But there is a second scenario that also works …

Work Items attending mode

When this is useful: imagine more than one Agile team is working on the same product/running same sprint and need to be aligned.

For this particular case I apply model to serve as peer management tool (for Scrum of Scrums aka SoS) with work items “attending”, where the yesterday-today-impediments questions is still used but will be from the perspective of the work item, rather than the person.

To run this one efficiently here is what I do:

  • I prepare list of aspects of product, teams have to address in common (e.g. regression bugs, functional tests, integration tests, unit tests, non-functional requirements and anything else teams consider as important);
  • I list them on the whiteboard beforehand (we have pre-agreed order of addressing those);
  • I invite max 2 team members per team to SoS to avoid long talks (one is also an option, however I’ve found 2 is optimal since in case particular team would need to make an on-going decision, another peer will help). Those guys are to talk for a team and report back to their teams whatever decisions were made, statuses changed, etc. in SoS;
  • Then I go through the list during SoS one by one (as if not teams attending, but “topics” and ask if each team has to align their peers on specific topic or has any related questions clarifying in which state topic is in presently);
  • I ask to share stories states not by default, but only in case there are questions or things that affect peer team(s) or causing dependency;
  • Then I ask if teams has anything else to discuss (and if that is technical, leave them alone);
  • Last but not least I ask if they have any impediments or may/are causing impediments to other team(s);
  • And of course I time-box to 15 minutes as max;

1 Comment

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

, , , , , ,

4 Comments

10 Tips to undermine Agile team ability to deliver

Many Agile coaches have their own list of top failure modes. My favorite one is Mike Cohn’s: “How To Fail With Agile: Twenty Tips to Help You Avoid Success“.

But I also want to publish my winning list of things that impact teams and undermine their trust in business and Agile  (combined from experience gained observing different teams at different times, so no particular team is meant here :) ).

So tips are written from the Product Owner perspective:

1. Argue in front of team at Sprint Planning. Let them see you were not capable to decide what you want to build them. Moreover, involve them into arguing. This will demonstrate how your (PO) team misses integrity;

2. Demonstrate that being on time does not matter: interrupt meetings with calls, side talks and questions. Leave the room occasionally and be late regularly. Doing this will make it almost impossible to demand on-time delivery from the team;

3. Continuously fail to deliver INVEST stories and integrity in sprint goal/product backlog. Let stories w/o details thought through, so that team feels you had not invest enough time to prepare them. This will also make it easier for team to fail delivering outcome of that stories to you, will make things more ambiguous, so that no one will understand where is failure or what was wrong and will never learn from it, so that improvement will not be feasible;

4. Ignore team signals on complex stories (the ones that are above ~13 story-points, the ones that are risky, big, and usually need to be analyzed and split into smaller chunks in advance). Just let big stories that have big doubts, leading to easier underestimations, over-commitments, sprint failures, causing less team confidence, further under-commitments and wastes of all kinds;

5. Present deadlines ignoring reality “I do not care how you do it, it MUST be done”. With this “masculine” management style you can always push things forward as Agile teams just delivery chain, so they must obey and no matter what they think and capable of;

6. Never share the Product Vision and mid-long term roadmap with the team (just keep it secret);

7. Ignore technical debt (just concentrate on #5);

8. Bombard team with in-sprint questions and “Can you do it now please?” tasks. Explain them that SCRUM is good but now we need to be more “FLEXIBLE”. Moreover, assign tasks to team members without talking to entire team. Demonstrate that you were not been able to plan things for an iteration, this will ruin team trust that they are working on most valuable things and completely undermine their ability to deliver;

9. Never groom your backlog just leave it to the sprint planning meeting when it is already too late. This will lead to long and stressful discussions as you will have to do it mid-planning,will drain team energy, lead further to fatigue, wrong estimations, poor planning and sprint failure;

10. Always try to find something that team did wrong to pin point and focus on blaming. This is proper way to avoid Kaizen and let team protect themself by “storytelling”;

, , , , , , ,

Leave a comment

When self-organization does NOT work: teamwork hints

Scrum is based on “Empower the Team” Lean principle that prescribes self-organization. This means that regardless of age and experience team members are equal and serve as managers to one another. There is strong rationale behind: people that do the work are the best to manage it as they own responsibility of results and know best how to handle it.

Daily stand-up or daily SCRUM is a team tool to reflect on changing reality and adapt accordingly.

I’d like to point out some cases when self-organization does not work as should and help those teams out to boost their productivity.

Let us discover some sick stand-up/self-organization symptoms first…

1. Refraining from exposing problems (ignorance of reality):

  • Task takes longer than planned and reasons are not clear to everyone (or something holds back people from raising problems);
  • Task is blocked and impediment is not exposed/raised (this also may indicate some other problem with task that is not comfortable to raise);
  • It’s just a way it is (yes we all know that we’ve planned 4 hours for that task, but as usual it takes us 2,3,5,… times longer or this guy always messes things up, we can do nothing, etc…);
  • Team does not reflect during a day on changing reality (just in stand-ups), leading to impediments piling up and being addressed late, so that they mask something else;
  • Etc…;

2. Intolerance to critical feedback:

  • Team member pushes back heavily when someone tries to rise a problem related to his/her task;
  • Raising problems considered as de-motivating and team silently prefer to hide them until it’s too late;
  • Team members prefer to stay “nice” to each other rather than constructively criticize their plan in order to adapt it daily;
  • Etc…;

Those two are inter-related. As a team member one will hold back from giving critical feedback if receives push back from his/her peer leading to confrontation and poor->no self-organization…

Scrum Masters, look around. Don’t you observe those symptoms during your stand-ups and/or during daily work?

If yes then…

Try out following cures ….

  • Talk to push-backers one on one, try to understand what makes them do so? It could be personal issues with team members, lack of positive feedback or self-esteem, or other personal or inter-personal problem(s). It also could be absence of trust (readiness to look vulnerable to the team).
  • Explain that feedback is not oriented towards person, rather towards team (exposes problem) as there are no personal problems in a team, since problem causes wastes, further slowness, incompleteness and later sprint failure of entire team.
  • Focus person on constructiveness rather de-structiveness when exposing problem and coach on asking why 5 times, usually it helps to come up with adequate counter measures to remove root cause of the problem;
  • Educate other team members that raising questions is crucial and needed, but highlight issues and offer them to try out different ways to do so (there may be personal barriers for push-backers, so more “gentle” way may be less stressful while lead to the same result, e.g. instead of asking “Why you did not finish this task so far”?, try “What holds you back from completing this task”?
  • Cultivate more solution oriented then problem stating approach (as solution is vector, while problem is scalar);
  • Talk to entire team that problems are normal and ignoring them just postpones failure. So they require courage to face and team spirit to overcome, that makes difference between team and group of people. Exposing problem does not mean it shall become energy-drainer and de-motivator, rather it’s in-time red flag that shall re-focus team on next right thing to do;
  • If conflict is unavoidable and your peers do not go with “exposing problems approach”, steer it, but not let pile it up (nice article on conflict avoidance here);
  • Launch team storming to “shorten the distance” between team members, so that exposing problems is more constructive and easy (see: “Teamleads, “Storming”, Self-organization and Entropy”)
  • Propose and drive team branding activity to help them find out shared values and motivators (see: “Team DNA: how to Brand up your team”);

To summarize, work both ways with ones who raise (also including you if you are in SM role) and with ones who push back to make raising problems comfortable and easy.

Good Luck!

, , ,

1 Comment

Getting them on it right: focus, energy, commitment and motivation

“Problems cannot be solved by the same level of thinking that created them.” Albert Einstein.

Less Vicious Circle

I was about to write another one in the scope of “Getting them…” targeted for Product Owners (PO), however thought that before getting them (stories) out of the sprints it is crucial for sprint success how to get them (team members) on it right…

So story going to be about how PO influences team focus and instills feeling of urgency and what happens if he/she’s not…

To understand this we would need to get back to Sprint Planning meeting (SPM). When PO makes final accords, accepts team commitment and sends team out to the sprint it is very important for everyone to stay focused on the Goals PO presented.

If PO jumps in mid-sprint, having unplanned acceptance criteria, special circumstances, etc… this sends a message: goal is void, direction is being changed, things that had been agreed at SPM are not valid anymore.

Scrum is tense way of delivering software. Constructive tension comes from high commitment and builds up high velocity (aka deliver fast lean principle) that is impossible to achieve without addressing limited and fixed number of issues within timebox.

Let’s understand how this works…

Higher velocity is achieved by staying focused on what is most important. As soon as this vector changes, something that had been important yesterday, becomes less important today, or something else emerges focus drifts away.

But velocity is not single thing this impacts…

More drastic effect this has on team morale, since besides team has to conduct context-switch (that has it’s own impact: see another related post here), but also it throws team into “Less” vicious circle that is:

  • Less focus that eats up energy and leads to …
  • Less energy that impacts productivity and leads to …
  • Less commitment that impacts desire to work and leads to…
  • Less motivation that drain attention and lead to …
  • Less focus …
  • Etc …

Understanding this will help PO to plan sprints in the way to avoid de-focus, protect sprints from interference (and team members from de-focus) and minimize impact of unplanned issues.

Of course fire-fights happen, of course they are important, but it makes sense to dive in root causes and build real quality in rather than fight consequences… and eventually turn circle back into “More..” :).

, , , , , , ,

Leave a comment

Follow

Get every new post delivered to your Inbox.