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

 

 

 

 

 

8 Key Aspects of Scrum Master Role

Ever since I was a child I have had this instinctive urge for expansion and growth.
To me, the function and duty of a quality human being
is the sincere and honest development of one’s  potential.
Bruce Lee

Working as active Scrum Practitioner for almost 9+ years I have come up with my understanding of what is Scrum Master’s role, service to the team and key responsibilities. Earlier I have written about what Scrum Master should master, here I would like to concentrate on 8 Key Aspects of Scrum Master work. Focus areas so to say. Here those are….

Facilitator

• Facilitates Sprint Planning Meeting
• Facilitates Sprint Review Meeting
• Facilitates Backlog Refinement (aka Grooming) Meeting
• Facilitates Sprint Retrospective Meeting
• Facilitates Daily Scrum
• Facilitates Release / Roadmap Planning Sessions
• Facilitates whatever/whenever else Team and/or stakeholders communication is required to be facilitated (not about any collaboration)

Purpose: to improve shared task clarity, planning, bring in more transparency over status quo for team to see where do they stand (and plan to go, and what have they achieved and how they want to improve) and their work results, help team to be able to enhance communication and perform their daily work

Team Builder

• Cultivates “us” vs. “me” culture and mindset
• Enables and fosters team to self-organize
• Helps team to make decisions
• Supports team through stages of its development
• Coaches individual team members on communication, collaboration and teamwork when necessary
• Increases “bandwidth” of communication among team members
• Observes team and talks to every single team member
• When required does one-on-ones to help through raising conflicts
• Navigates conflicts (involves management when necessary)

Purpose: to build up better team => better understanding each other => improved collaboration among team members => improved team performance

Team Guardian

• Guards team agreements, decisions and process (e.g. retrospective decisions, agreed “howtos”, DoD, DoR, review process, etc)
• Make team stick to its agreements, drives teamwork and respect towards owning decisions, leading to performance improvements
• Keeps balance between fulfilling business (Product Owner) needs and maintaining team sustainable pace, so that business needs are addressed by PO requests while team development and pace is not forgotten.
• Makes sure environment is as Team empowering as possible. Empowerment raises team feeling of ownership that rises up dedication and servers to better results
• Helps the team and Product Owner to maintain their artifacts (product backlog, sprint backlog, task and action boards, sprint/release burndown charts, tickets comments, story maps, etc.)

Purpose: create and maintain environment where high demand is possible. Here is why that is important

Impediment “Fisher” & Resolver

• Creates environment for effective impediment “fishing” and removal. Cultivates transparency and information radiation as pre-requisite for impediment clarity and removal
• Enables team to respond to impediments
  • Raises awareness of team’s impediments
  • Coaches team in resolving impediments (the one’s that could be solved by team)
  • Helps team to discover new impediments (wastes). Constantly questions the status-quo
  • Helps to resolve impediments / take ownership of those cannot be solved within / by team
• Improves efficiency of the team by helping with eliminating impediments
• Escalates and follows up on impediments to where they belong

“High Focus” Promoter

• Shields team from external interferences (extra tasks, todos not agreed with Product Owner, etc)
• Enables team to concentrate on most important todos, achieving “state of flow” and high concentration.
• Helps to avoid wastes caused by context-switching and to avoid team member burn-outs
• Gardens team’s sustainable pace, so that combined with “empowered” environment of high demand is possible
• Increases feeling of “urgency” and highlights how much is left to achieve (e.g. tickets, story tasks, story points, etc.), e.g. with the help of burndown charts, tickets left, etc.
• Helps team to focus on regularly achieving small thing to create feeling of fulfillment and good progress

 Motivator and Coach

• Promotes positive thinking, open, honest and respectful feedback culture
• Motivates team to improve team productivity regularly
• Helps to raise team morale, to increase dedication and to improve team deliverables
• Helps to create feeling of achievement
• Creates environment of excellence and continuous improvement (and mindset of seeking for improvements)
• Creates mindset of “quality first”, intolerance to poor quality and continuous improvement
• Regularly takes care of team’s “happiness” (and involves management when necessary)
• Coaches and teaches required mindset, frameworks and engineering practices (Lean thinking, Scrum, Kanban, XP, pair programming, continuous integration, test automation, etc.)
• Teaches and integrates new team members into working process and agreements (and into the team)
• Serves as agent for change and positive challenger of the team
• Reflects integrity and leads by example (e.g. being on time, continuously self-improving, sticking to agreements, etc.…)

Reflector

• Reflects Lean thinking and Agile principles to the team
• Reflects on reality and promotes transparency on status-quo to question
• Makes things measurable where applicable and possible to illustrate team progress: brings transparency about what is done, how much is achieved, so that weaknesses are easier to identify and potential improvements are easier to see
• Helps team to radiate information (e.g. burndowa, burnup charts, impediment boards, hapiness matrix, knowledge matrix, peerwork matris, etc.)
• Introduces required measurements for team to see regularly its work results (e.g. tickets achieved, stories done, story points achieved, bugs popped up/fixed, retrospective decisions implemented, ..)
• Uses collected data to think and question team and act if required

Agileist: outside of Scrum Team

• Shares Agile/Lean mindset within organization
• Shares best practices and tools, so that other Scrum Masters can benefit / see different perspective of managing things and company can benefit from enriched toolbox of methods and practices
• Collaborates and helps other Stakeholders to learn how their requests could be fulfilled with the team doing Scrum (or Kanban), so that other Stakeholders could get their requests address while team’ pace is also protected
• Helps to improve organization by creating learning organization
• Helps to address organization’s impediments

Last and not least there are many other things that do not belong to this structure. Those are dependent on situation and circumstances.  And those are still handled by great Scrum Masters 🙂

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;