Scrum is driving us crazy!

Quite a few teams in organizations implementing Scrum depict their frustration in statements like “Scrum is driving us crazy!”, “It’s too chaotic!”, “As if we didn’t have enough meetings, now we have to deal with a ton more!”, “So many metrics we need to improve upon?!?”. With the discussion that follows, it becomes fairly apparent that problem lies elsewhere.

After discussing with people, it turns out that their frustrations are primarily surrounding complimentary practices which are not part of Scrum. Few examples –

  1. User Stories
  2. Velocity
  3. Planning Poker
  4. Story Pointing
  5. Burndown charts
  6. JIRA tool
  7. Information Radiators

These practices are meant to be leveraged when they help the team; if they aren’t helping, gladly skip them to avoid carrying unnecessary baggage. By avoiding these (if needed), you will be able to relieve the teams from most of the issues. Some of the problems I have witnessed – Maintaining separate virtual Sprint Backlog in JIRA as well as physical board [a classic Lean waste]; write every requirement and feature in User Story format [people are forced to do this and abuse the format]; forcing teams to increase their velocity sprint-over-sprint [read more on this here]; Burndown charts have to look smooth so we know that we are delivering value continuously [not true and unfair to the delivery teams].

Now let’s talk about what Scrum is about. For delivery teams and management, core of Scrum lies in these aspects –

  1. Moving away from long-term plans and working towards common, yet shared goals
  2. Delivering products iteratively through short, high value Sprints
  3. Be empirical in your approach by regularly inspecting artefacts, processes, tools, etc. and adapt based on evidence in your hands
  4. Engaging stakeholders often to gather valuable feedback about the product to assist in tactical change in direction, if needed
  5. Shifting from project mindset to product mindset
  6. Focus on delivering value to your customers rather than ‘keeping people busy’
  7. Help improve productivity of the team by removing impediments that stall them from meeting their goals
  8. Give control to the delivery team rather than managing or ‘micro-managing’ their tasks
  9. Building trust by living the 5 values of Scrum
  10. Looking for every opportunity to improve upon yourselves as a team and as individuals

Remember Scrum does not solve your problems, it just surfaces the dysfunctions that exist in your ecosystem and sometimes it can be overwhelming. So it will mean you need to unlearn some of the old habits (most of them die hard!) and will surely drive you crazy till you start reaping the benefits of Scrum.

Agile Coach Toolkit #1: 5 Whys

As an Agile Coach, you frequently encounter situations which demand quick thinking to get things moving in the right direction. Over time I have found few techniques which come out handy and always keep these in my playbook in case need arise. This is first part in the series of tools that I have found useful in my role as Agile Coach – 5 Whys.

Brief History – This technique was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies. It is a critical component of problem-solving training, delivered as part of the induction into the Toyota Production System.

Purpose – 5 whys can be used for:

  1. Root Cause Analysis during Sprint Retrospectives
  2. Identifying impediments

Description – Discuss with team members to look at the issue and ask “Why?” up to five times to get beyond habitual thinking. It is imperative to distinguish causes from symptoms and pay attention to the logic of cause-and-effect relationship to identify the root cause. Be empirical in the investigation by leveraging the facts for decision-making.

Example – An issue identified is “poor Sprint Planning”. Let’s find the root cause for this problem.

  • “Why was Sprint Planning poor”?
    • “Well, we did not have a clear objective and the PBIs were not ‘Ready’
  • “Why were the PBIs not ‘Ready’”?
    • “The team did not meet for Product Backlog Refinement meetings”
  • “Why did the team not meet?
    • “Yes, we were supposed to meet on Thursday from 4 to 6pm, but the CEO called for an impromptu All-hands at the same time”
  • “Why wasn’t the meeting re-scheduled”?
    • “Well, there is no owner for the meeting”

So the real root cause for poor Sprint Planning was no accountability of the Product Backlog Refinement meetings. It is very important to identify the root cause, come out with action items for improvement, identify an accountable person from the Scrum Team and agree on the expected time frame for putting the improvements into practice.

Have you used this technique to identify the root cause of any problems? If yes, please share your story.

References

Scrum Insights for Practitioners – Hiren Doshi

https://en.wikipedia.org/wiki/5_Whys – Wikipedia

Agile Retrospectives – Esther Derby, Diana Larsen

Scrum Chapter Mumbai – “Leading Agile adoption”

Goal to answer the question:

“As an aspiring Agile Coach, I want to learn how to lead Agile adoption for my 1st prospective client, so that I can deliver maximum value and improve their ROI for the investment they make in me”

We had some excellent discussions.

Some insights we gained from our discussion:

  1. Understanding ‘The why”: Why is the organization is trying to embrace Agile?
  2. Derive the baseline of where the organization stands before the Agile journey
  3. Facilitate retrospectives and interviews with the C-level executives, mid level managers and the foot soldiers to understand the culture of the organization as well as their Agile readiness.
  4. Educate the organization on the new ways of working and get a top-down and bottom-up buy-in. This can include trainings, brown bag sessions, etc.
  5. Define quantitative business metrics to measure the progress with the idea of continuous improvement and the understanding that all we need to do is try to be “better than yesterday”
  6. … and many more

The 2nd edition of Scrum Chapter Mumbai is planned on Saturday, March 24th from 4:30pm to 7:00pm.

Topic:  Moving from “ScrumBut” to “ScrumAnd