Category: Uncategorized

Scrum Master the solver of all impediments – An Anti Pattern

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Scrum Master should solve all impediments

  • In the 2017 version of Scrum Guide the accountability of the Scrum Master was mentioned as “Removing impediments to the Development Team’s progress;”. This sentence was often misunderstood and it was assumed that Scrum Master is the one who runs around and solves impediments.
  • The term “Facilitator” is commonly misunderstood as a “coordinator”. Most teams come from a waterfall background and are used to having a Project Manager. In most organizations, the Project Manager is nothing more than a PMO who coordinates and does administrative activities. The essence of facilitation is to make it easy for the team to get to conclusions and decisions. Impediment solving is only one aspect of the Facilitation.
  • Most organizations implement Scrum Master as a replacement for the PMO responsibilities and expect Scrum Master to run around and solve impediments.
  • From the outside, this looks to be a great idea to have developers do the work and Scrum Master run around and get the administrative stuff done.

Negative Consequences of having a Scrum Master solve all impediments

  • One of the fundamental elements of Scrum is “Self Management” where the team manages itself. The Scrum Master’s job is to teach the team to be self managed and cross functional so that they can get the work done.
  • Team members other than the Scrum Master might be better qualified to solve an impediment
  • People often then shrug off their accountability and expect Scrum Master to be the PMO and even solve problems which they could solve internally
  • Problems are often too complex to be solved by one person and therefore Scrum Master may not be the correct person to solve the problem
  • Viewing an impediment from different angles helps to find effective solutions
  • Many problems have to do with the way how people work together, solving such a problem cannot be done by one person

What could be done to avoid this anti-pattern

  • The first line of defence for the team should be the team members themselves. The Scrum Master must teach the team to do this and not push everything into Scrum Master’s plate
  • The Scrum Master should not get overloaded with solving impediments. The Scrum Master should be an observer, a coach and making sure that facilitation is done.
  • For impediments which actually need Scrum Master’s help, only those Scrum Master should focus his/her attention on.
  • Scrum Master should use his anticipation skills to anticipate issues so that the team can start looking for solutions a little bit in advance.
  • In short, Scrum Master should become a coach and facilitator rather than just being a PMO.
  • To clarify the actual accountability of Scrum Master with regards to impediment solving, the sentence has been reworded in the 2020 version of Scrum Guide to “Causing the removal of impediments to the Scrum Team’s progress” – which essentially means that it is not necessary that everyone just dumps all impediment solving on the shoulders of the Scrum Master.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/scrum-master-the-solver-of-all-impediments-an-anti-pattern/

Hardening Sprint – An Anti Pattern

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Hardening Sprint seems a good idea?

Scrum Teams are under constant pressure to deliver features. The stakeholders and Product Owners often push the Developers for going to production as soon as possible. 

In these situations, the developers often postpone a lot of work to be done later. Examples include – documentation, code cleanup, defect fixing, commenting of code, hard-coding, bypassing checks etc.

Then the Scrum team introduces a “Hardening Sprint” after 4-5 Sprints to take care of all these pending activities. Therefore introducing Hardening Sprints is generally considered a good idea by a lot of teams.

User of Hardening Sprint introduces following problems

Pending work increases. Many times the Hardening Sprint does not get taken and the work just keeps accumulating

It becomes more and more difficult to tidy up the mess

Teams end up forgetting things later on

Increase in the possibility of the defects since things get fixed later

What could be done instead of Hardening Sprint

Follow the agile principle of “Simplicity” – the art of maximizing the work not done. That is, don’t push more features. Try to complete a lesser number of features with all things done.

Slow down – focus on quality rather than speed

Make the Definition of Done more stringent

Focus on engineering practices such as Automations, CI/CD, Automations, TDD

Say NO to a hardening sprint. Do not keep pending activities. This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/hardening-sprint-an-anti-pattern/

Basic Building Blocks – Incremental and Iterative

Meaning of the words Incremental and Iterative are

  • Incremental – Breaking into smaller units and building in pieces
  • Iterative – Repetitive so that feedback can be received

Scrum-incremental-iterative

Scrum is an Incremental and Iterative framework. What this means is that we break the work into smaller units and at the same time we aim to get feedback as quickly as possible from the customer.

The traditional vs Incremental-Iterative work can be described with following diagrams

Traditional Work

Iterative-Incremental Work

Handling Distributed Retrospectives

Following are some of my learning from handling retrospectives with Distributed Teams.

  • Build trust: The Scrum Master needs to develop a sense of trust and honesty within the team, which in turn will lead to a wider degree of openness.
  • Reduce effects of distance: The facilitator of a distributed retrospective needs to understand the cultural differences in the team. The Scrum Master needs to understand how different cultures interact when they want to change something or have issues they want to talk about that can help the facilitator encourage participation from all team members.
  • Set expectations: The facilitator, for distributed teams, should talk to the team ahead of the first retrospective and explain the expectations for the retrospective.
  • Understand the team members’ personalities: Teams have a different combination of personalities, and the facilitator of the retrospective needs to understand the personalities of team members to lead the meeting effectively.
  • Respect cultural differences: The Scrum Master needs to make sure cultural difference should not be taken lightly during the retrospective meeting in distributed teams.
  • Ask for comments before the retrospective meeting — what went well and what can we improve? Ask the team for comments about issues or problems they noticed since the previous Sprint retrospective and summarize them for team discussion. The result is still an action plan the team needs to change or continue in the period until the next retrospective.
  • Provide questions to focus the discussion: In a distributed setup, team members respond to a set of questions developed or selected by the team. The purpose is to focus on a few issues and address them effectively instead of trying to address a lot of issues and address them poorly.
  • Discuss reported issues: During the retrospective, the team reviews the reported issues and, if others feel strongly enough, the team addresses them, creates action plans, and logs them as actions they will revisit in later sprint retrospectives to evaluate their success.
  • Effective and overlapping retrospective meeting timings: To be effective and timely, distributed teams should call joint retrospectives as soon as possible after having their own team meeting. Depending on the number of teams involved in a joint retrospective, teams may want to limit the number of participants from each Scrum team to keep the meeting productive.
  • Hold joint retrospectives: The distributed teams working together will conduct their individual sprint retrospectives at the end of each sprint and then will conduct a joint retrospective. The benefit of this approach is that it promotes communication between the various teams involved in a project.
  • Conduct milestone-based larger retrospectives: Distributed team members should reflect and comment on release quality and capability. The team defines and records the various milestones within the project to improve on or continue in future releases.
  • Release retrospectives: The team talks about the project, then defines and records the milestones in the project, like initial training, team formation, stand-up meetings, start of development, middle of release, deployment, etc.

Cross-functional Team

Perhaps the most prevalent and persistent myth in agile is that a cross-functional team is one on which each person possesses every skill necessary to complete the work. This is simply not true.

  • A cross-functional team has members with a variety of skills, but that does not mean each member has all of the skills. A cross-functional team has access to all the skills necessary to effectively deliver value to customers. A cross-functional team does not have to consist of all generalists. A cross-functional team also does not have to consist of all specialists.
  • You will generally find that a cross-functional team consists of a mix of people who have some knowledge about a lot of different areas, and others who are stronger in one area but are willing to help out in other areas where needed and when they can.
  • You generally want a stable, focused team such that they are working solely on the work of that team, which may cut down on the number of specialists on the team on an ongoing basis. You may instead opt for people that know enough about a certain topic and bring in specialist knowledge only for very specific occasions.
  • A cross-functional team does not require specific roles. You don’t have to have a designer on the team as long as there are people who are proficient at design. You don’t have to have a tester on the team as long as there are people who proficient at testing. You don’t have to have a development on the team as long as there are people who are proficient at development.

DevOps, Lean, Scrum, Agile

DevOps shares many characteristics with the Agile/Lean movement, especially with the focus on individuals, interactions and collaboration. You might wonder if DevOps us just “rebranded” Agile/Lean. While Devlops has certainly grown out around agile/Lean methodology, it is a separate cultural movement steeped in the history of the computing industry with a broad reach that includes more than just developers. DevOps adopts and extends Agile principles and applies them to the entire organization, not only the development process. Some of the important practices which support DevOps are

Agile

  • Agile Manifesto defines the 4 Values and 12 principles around which the whole Agile movement revolves. Especially the 4 values are very relevant to DevOps Movement
    • Individuals and Interactions OVER processes and tools
    • Working Software over Comprehensive Documentation
    • Customer Collaboration over Contract Negotiation
    • Responding to Change over Following a Plan

Lean

  • The 5 lean Principles support the DevOps movement
    • Value : Focusing on Value being created for the customer not just on delivering requirements.
    • Value Stream : Focusing on elimination of wastage
    • Flow : Flow helps in focusing on completion and getting tangible delivers out to the customer
    • Pull
    • Continuous Improvement : Continuous improvement mindset results in constant improvements in your product which is one of the core requirement of DevOps mindset.

Scrum

  • Scrum is an Agile Framework which also supports the DevOps in various ways. Some of the examples are
    • Scrum advocates frequent delivery in the form of Sprints. The objective is to produce a potentially shippable increment every iteration.
    • Product Backlog help define operational elements, testing elements and end to end elements commonly called the Product Backlog Items
    • The Daily Scrum meeting is a useful meeting for inspecting and adapting daily. This helps in collaboration between the various teams to produce potentially releaseable increment.
    • The Review meeting every sprint is a good way to get feedback from the customer every iteration and thus inspect and adapt.

Distributed Scrum Teams

Today businesses are shifting to emerging economies (such as India) due to reduced business operations cost and an easily available workforce. The businesses certainly are more virtual and distributed, with “distributed” as its key element. Thus the need for better managing such teams, using the right tools and processes, is becoming increasingly critical for any enterprise company.

   Here are some reasons for the shift and need for having distributed Agile teams:

  • Globally distributed teams reduce costs.
  • They can reach the market more quickly with a “follow the sun” model.
  • Distributed teams expand access to new markets.
  • Acquisitions as a result of consolidation results in companies working together to integrate their businesses.
  • Expansion can aid innovation and thought leadership.
  • Telecommuting gives options for communicating with teams effectively.
  • Collaboration tools — improved tools for distributed communications and server-based, multiuser tools for product development — are removing barriers, and more teams view distributed collaboration as an alternative.

Handling Distributed Scrum Teams

  • Distributed teams increase the need for clear, timely communication between sites. You might be thinking of increases in complexity due to more time zones, language barriers, and cultural differences getting in the way.
  • Communication is the core issue among the distributed teams. Different time zones, conflicting working hours, cultural and language barriers impact communication and collaboration.
  • Investing in effective enterprise tools for requirements repositories, source Control management, build and deployment setup, defect tracking, and project management tools is essential.
  • Practicing Test Driven Development (TDD), Continuous Integration and Automation of Testing are recommended
  • Proper communication setup such as telephones and videoconference are essential in a distributed setup.
  • Telecommunication etiquettes such as conversation using round-robin technique, importance of mute etc are essential hence a upfront training or setting ground rules for telephone etiquette is essential.
  • Coordinating Agile and non-Agile teams: Making sure the non-Agile team is aware of the priorities of the Agile teams and keeping dependencies visible can help to prevent blockers between the teams.

GROW Coaching Model

GROW is a proven coaching model to structure coaching experience .

beauty of this coaching model is that it leads to a clearly defined end result through four phases. The coachee is personally active in identifying problems and generating ideas for solutions. As the coachee is actively engaged, the outcome is more likely to succeed

The GROW coaching model encourages learning through experience: reflection, insight, making choices and pursuing them. The success of a coaching trajectory with the GROW coaching model also depends on the time and energy invested into the process by the coachee.

The best part about working with the GROW coaching model is that you don’t need to be an expert in a specific situation to be able to coach the team. This model offers a framework with general questions to elicit objectives , obstacles, options and more without ever needing to offer advice or force any particular direction.

The steps in the GROW coaching model

The GROW coaching model consists of four steps. The word GROW is actually an acronym for Goal – Reality – Options – Will. This GROW coaching model enables you to to plan a journey. You start with the map: where are you going (Goal) and where are you starting from (Reality)? It then charts the different routes and modes of transportation (Options). At last, it helps you pick the option that suits you best while still considering the obstacles on the way.

GROW coaching model – Step 1: Goal

The first step in the GROW coaching model is defining the goal of the coaching initiative at hand. You will need long term (the central theme ) and short term (the goal for every session)goals.

Goals need to be SMART: Specific, Measurable, Acceptable, Realistic and Timely.

Example questions to identify the goal:

  • What Will help us achieve defect free code?
  • Why a defect free delivery will benefit the team?
  • What it means to be defect free? How do you define it?

GROW coaching model – Step 2: Reality

Step two of the GROW coaching model is making coachee aware of the actual situation on the ground . The coache’s role here is to stimulate thought with the coachee, and to identify the obstacles that have been holding the client back.

It’s important to stay out of the equation in this phase; people have patterns and stories they can repeat and expand on endlessly. Keep on summarising and repeating what you understand from the coachee. Often, this phase of the GROW coaching model reveals underlying fears and convictions that can be worked on during or in between coaching sessions.

Example questions to discover the reality of one’s client:

  • Hows the code quality now?
  • How do you know the current code quality is poor?
  • Why is the code quality poor?
  • Why it is problem to have a poor code quality?
  • What are concrete examples of this problem?
  • What’s been going wrong so far?
  • Is this always a problem or are there situations in which it isn’t?
  • What have you done so far?

GROW coaching model – Step 3: Options

Step three of the GROW coaching model is to generate ideas that can contribute to the solution of the problem. Try to start a creative brainstorming process without censure or conditionality. Generate solutions, then structure it to evaluate every option. If needed, you can also offer some suggestions.

Example questions to generate options:

  • What else could you do to improve code quality?
  • What would you do if you did not have a hard time pressure ?
  • What else do you need to reach your goal? Where can you get it?
  • Which criteria will you use to evaluate this option?
  • What are the pros and cons of this option?

GROW coaching model – Step 4: Will

The fourth and last step of the GROW coaching model is the choice of one option. This is converted into a concrete plan of action. Then the coachee’s motivation to follow this plan is maximised.

Example questions to maximise the will:

  • What exactly will you do to improve the code quality and when?
  • Which of these options will you take?
  • What concrete step can you take NOW to improve the quality?
  • What steps come after?

Critical Success Factors of DevOps

As I had described in the introductory post, DevOps is about a cultural and mindset change. It is not about just implementation of a few tools and techniques. Any type of culture change involves a number of critical success factors.

In the context of DevOps these include:

  • Management commitment to culture change : Without a Management commitment, it is hard to imagine a cultural shift as big as DevOps
  • Creation of a collaborative, learning culture : This is a continuous learning culture which involves improvement of processes, tools and the work that one does.
  • Common values and vocabulary
  • Systems engineering that spans Dev and Ops
  • Meaningful metrics : Sometimes organizations have metrics which are not in sync with the actual work going on on the floor. The metrics have to be meaningful
  • A balance between automation and human interaction : Most people think DevOps is about Automation only.
  • Application of agile, lean and service management methods
  • Open and frequent communication

Choosing right agile pilot

Many students ask me how to choose a pilot? To ensure success of your transformation, it is really important to choose a right pilot. Below I will give  a few suggestions. These suggestions have worked for me in while choosing an Agile pilot.

  1. Select a “Visible but not critical project”. It is important to choose a project that has visibility across organisation. This will make the next steps of spreading agile easier. When we select a visible project, it becomes difficult for detractors to dismiss the success. At the same time be wary of selecting mission critical projects. Too much is riding over success of such a project. In this case, the team will be less likely to experiment. The stakeholders will be even less likely to have the necessary patience.
  2. Size Matters!! I usually suggest to select project which is not too large. A large project has additional scaling challenges. These become  an overhead while trying to implement agile. Usually not more than 3 scrum teams is a nice rule of thumb to follow. I also caution against selecting a too small a team. Such project may also mean a success which is not as spectacular to be tooted across organisation. A really small project delivered by a small team is anyway likely to be succeeded and agile would not get the crredit for the success!
  3. Where possible avoid added complicating factors. If at all  possible, it is better to avoid a project with unnecessary complications.Some examples can be, technology which is too strange to the team , a team that is greatly distributed (more that 3 locations)  or a team that is too new and still in “forming /storming” stage. Changing way of work to Scrum is anyway stressful, it is best to avoid further stress. 
  4. Select a project that intuitively needs agile It’s best to select a project that has need to evolve requirements – in other words it’s best to have a pilot for starting a brand new product. It will allow the inherent agile qualities to shine..At the same time, we would avoid added complications of a monolithic architecture or a legacy code base that no one fully understands.
  5. On board the champions – Identify your supporters early and include them in your pilot. These people are any way convinced and they will work hard to prove the concept.
  6. Avoid The detractors – In the same vein, it is usually prudent to avoid strong nay sayers. They usually will come on board when they see the pilot succeed. This will reduce the stress of having resistance along every step of pilot