• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Agile Buddha

Demystifying Agile, Getting to its Core

  • Our Blog – Agile Buddha
  • Agile Workshops and Certifications
  • Agile Commune – Join Here!
  • Webinars
  • Contact
  • About Us
  • Show Search
Hide Search

Agile Thinking: Continuous Improvement – ScrumMaster 1.0 to 2.0

by Avienaash Shiralige 7 Comments

Readers, Our “Agile Thinking” series is focussed on bringing agility into our thinking as this helps in moving from Doing-Agile to Being-Agile. You can read our earlier article in this series Agile Thinking: Stop Starting, Start Finishing.

This post talks about continuous improvement and obviously this can be applied everywhere irrespective of it is a process, practice or a role. From my recent experience, I would like to share today, how ScrumMater (SM) role evolved in some of the companies.

In many organizations, ScrumMaster role is defined something similar to what is shown below. For conversation sake let’s call it as SM 1.0 (see pic below)

ScrumMaster

In service industry projects,  SM’s playing the role by book (SM 1.0) and expecting Product Owner(PO)  from the client side to write stories, acceptance criteria and prioritization did not work due to some of the reasons stated below.

  • Ineffective PO – Mostly many client organizations are new to this concept of product ownership (PO). Hence they lack sufficient skills and training to express their requirements in stories with sufficient details/acceptance criteria
  • Small projects of 2-3 months are too small a timeframe to learn this skill and be effective.
  • Resistant to change – Traditionally clients are used to hand-over a project to the vendor and go away, so backlog management is vendor problem – Mindset challenge.
  • Busy PO – Lack of  time to be in constant engagement with the team. PO has other commitments and responsibilities within the org and often it is impossible to rejig this role just for the duration of the project.

Additionally, teams were not able to go for full-time BA due to budget constraints and often full-time BA was seen as an overkill for 3-5 people team.

So for all these above reasons and more, development teams suffered from requirements being not ready in-time in chewable form. This was a major roadblock, and in-fact now I see many many teams across different organizations face this issue.  PO is like oxygen to the team. If he stops churning stories at the right time, then team starts suffocating. Check earlier article on How to Improve Sprint Throughput With Definition of ready which gives few suggestions on how we can address this issue.

To address this lack of strong product ownership on the projects, teams improvised the role of SM, which I’m calling here as SM 2.0 where-in business analysis, backlog management, prioritization, client stakeholder management were added to this role in addition to SM 1.0 responsibilities and off-course he became the scrum coach to the team and clients too. See SM 2.0 pic below:

ScrumMaster

 

This new role had following additional responsibilities:

  • SM created the product backlog post discovery with PO by writing epics and then splitting them into user stories with acceptance criteria.
  • SM started to drive backlog refinement meetings and release planning with PO.
  • SM ended up bringing different client stakeholders on the same page for quick decision making.
  • It’s important to note that accountability and ownership of the backlog was still with the client PO.

PO being seen as “single wringable neck” works well where we are able to find such a PO. If not you need a very strong leadership from the consulting company. Hence in such situations SM 2.0 works well.

This change brought few additional advantages:

  • Aligning SM to a project business domain helped in building domain knowledge within the team.
  • This made SM confident in making some business decisions, prioritization and able to comprehend reasons behind the prioritization – helped build a Big Picture.
  • Additionally, this helped in building industry specific verticals in the organization.

Be Agile, don’t just do SM 1.0 or 2.0. 

Readers, Please share your ideas and thoughts on “Agile Way of Thinking” which has worked for you in your organization. If you have some great stories to tell, I would be happy to share them here. Write to me.

Agile, Scrum Agile Thinking, Big Picture, Business Analysis, business analyst, ScrumMaster

Reader Interactions

Comments

  1. Abhishek Aggarwal says

    at

    Truly agree with what you said Avienaash.
    I am already playing a role of TPM where creating and managing PB, prioritization, business clients handling and software delivery. I have seen companies merging different roles due to competitive market and want immediate results rather than looking who will do what!!
    It all depends on you whether you want to acquire someone’s idea or get acquired…

    Idea is to have agility in thoughts & work and accept & adapt any change!!

    Reply
    • Avienaash Shiralige says

      at

      Agree Abhishek. Business teams are not still not used to work with dev teams. They restrict themselves to business side. This is the evolution that will happen slowly. But companies can not wait, have to deliver. But focus should be there to bring this cultural change in parallel.

      Reply
  2. Sunish says

    at

    Avie,

    The role of the Product Owner has already been debated numerous times and is a major dysfunction in most Organizations adopting Scrum. Though it is good to read that the concerned Org saw improvements (hopefully, quantifiable) moving to SM2.0 (SM1.0 + part PO) but I feel it is still not resolving the real issue of a dysfunctional PO role and SM2.0 does add to this dysfunction and do not reduce it. The roles defined in Original Scrum have a purpose and that’s why there is segregation between the roles. I’ve seen numerous situations where multiple POs (Tech PO and a Business PO etc.) or multiple BAs working with a PO etc. try to share the responsibilities and SM2.0 is also doing that here. Having said that, it is not that this should not be done as context is different for each and every Organization and each one has got their own constraints to manage, improvements might be seen as well but how sustainable are these is the question I always grapple with.

    Btw, I do hope Goa is treating you well.

    Rgds,
    Sunish

    Reply
    • Avienaash Shiralige says

      at

      Sunish – I really love the way Scrum role segregation is defined. I have worked in 3 product set-ups where we had the privilege of such strong PO as defined in scrum. This expertise is very rare. For all the reasons I have mentioned in the post it is much more tough to find good PO. On service projects, we can not wait for the Ideal PO to arrive for projects to start. They HAVE to be delivered in said timelines. So you still make client PO accountable and facilitate him to make decisions for the team and supplement his weakness by such strong SM 2.0 kinda role. This is quite sustainable also, as the bar for SM’s raises many folds and that sets culture for hiring in the organization. When these same SM’s move to other projects they use similar experiences to deliver. I have seen this culture change happening in the companies across many teams. That said, on long term product development, I would invest time to coach the PO rather than making SM move to 2.0.

      BTW – Goa is Awesome! Loving everyday here!

      Avie

      Reply
  3. M sabir says

    at

    What about a BA who takes up the role of scrum master. Is that also 2.0 or can that be considered 3.0?

    Reply
  4. Proquotient Team says

    at

    Nice explanation on how an ineffective product owner can make the whole team inefficient , The ScrumMaster 2.0 role seems to be a good way to deal with some of these things to make the overall process much more faster and efficient. Agile is continuously growing and so the roles it requires should also evolve like this.

    Reply

Trackbacks

  1. The Operations of Leadership: 4 reasons to change your mind about leading like a “turn & crank” operation – Square Peg Solutions, LLC says:
    at

    […] in plain sight. Most operators work in a state of continuous improvement – kaizen, kanban, lean, scrum, andon, poke yoke, standardized work. Little by little, yard by yard, they find ways to improve […]

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

LikeBox

Tags

5 Whys Acceptance Criteria Adoption agile Agile Culture Agile Estimation Agile Offshore Agile Teams agile testing Agile Thinking Agile Transformation Agility Appraisals ATDD Automation Backlog Grooming BDD Big Picture business analyst Capacity Planning case-study code quality Collaboration Daily Scrum DevOps distributed agile Distributed Scrum Estimation Good Practices kanban kanban-mythbusters lean Metrics Planning Poker Prioritisation product owner Scrum ScrumMaster Sprint Sprint Demo Sprint Retrospective Story Point Story Points Sustainable Pace User Story

Categories

  • Agile
  • Agile Leadership
  • Agile Testing
  • Agile Transformation
  • ATDD
  • BDD
  • Continuous Inspection
  • Culture
  • DevOps
  • Distributed Agile
  • Estimation
  • In Conversation with Tim Ottinger
  • Java
  • Jira
  • Kanban
  • Lean
  • noprojects
  • Patterns
  • Presentation
  • Product Owner
  • Scaled Agile
  • Scrum
  • Software Metrics
  • Testing
  • Testing Practices
  • User Story

Copyright © 2025 · Malonus Consulting LLP

  • Email
  • LinkedIn
  • Twitter
  • Facebook
  • Privacy Policy