The New New Scrum Master: Two Main Focus Areas

I’m going to take a break from talking about the New New Product Owner to talk about the New New Scrum Master now.

Preface:  In the last 4 years, the Scrum Guide has had two very significant updates, including updates to the Scrum Master Role. In this article and the series that follows, I attempt to describe “The New New Scrum Master” role in Scrum.

The Scrum Master role has not changed as much in recent Scrum Guide updates as much as the Product Owner.  In many ways, however, what has changed, is the number and higher frequency of misconceptions about the Scrum Master role.  This is, in my opinion, due to late adopters to Scrum who don’t take the time or money to attend proper and professional Scrum training.  Yes, this appears to be a completely self serving statement since I’m a Scrum Trainer.  However, the bigger, and more important reason this statement is true, is because Scrum is a much deeper topic than people think.  We often use the metaphor of the difference between a Chess player who knows how the different chess pieces move, and a Chess player that has extensive experience and knowledge about how to be excellent at the strategy and techniques of Chess.  There is a vast difference between those two ends of the spectrum, between knowing the rules and being able to excel at winning.  With Scrum, people and organizations vastly underestimate just how long that spectrum is.  All you have to do to confirm this is to witness or hear about a Scrum adoption that is horribly painful or not working.    So, my hope is that we can clear up some misconceptions for the New New Scrum Master and help reduce some pain and increase some profits!

The two main focus areas for the New New Scrum Master are:

  • Teaching and coaching the organization on how to achieve the benefits of Scrum, and
  • Removing impediments that are beyond the reach of the Development Team.

For brevity’s sake, we will shorten these to “teach/coach” and “remove impediments.”

All of the other Scrum Master focus and duties derive from the above two focus areas.

For a high quality class that focuses exclusively on the Scrum Master role(the course is also great for management), see our Professional Scrum Master class and contact us if you’re interested in one.

Teach/Coach

One of the main focus areas for the New New Scrum Master is teaching and coaching the organization on how to achieve the benefits of Scrum.  Let’s talk about how this might be done.

The New New Scrum Master knows the “Why’s” behind Scrum.
In my experience, Scrum Masters would do well to understand the benefits of Scrum on several levels, before worrying about specific teaching or coaching techniques.

First and probably foremost, the Scrum Master should understand and *be able to succinctly communicate* the *business* benefits of Scrum to the organization. It is important to to be able to communicate these benefits succinctly because, in the wider organization, the Scrum Master will very often be given 5 minutes or less to convey them.

Each Scrum Master should have their own such list of benefits memorized, but certainly some of them should be:

  • Faster time to market
  • Quicker ability to pivot to market opportunities and competitor threats.
  • Higher Customer Satisfaction
  • Higher Productivity
  • Higher Transparency
  • Better Predictability
  • Better alignment between the business and software teams
  • And the list goes on…

A good study of the 11 key metrics in “Evidence Based Management” will help you to be aware of some of the business benefits, but come up with some of your own.  Make it yours!

Being able to rattle a good handful of these off, and then being able to *explain succinctly* how different sub parts of Scrum support these goals should certainly be in the New New Scrum Master’s toolbox.  When facing an organization that has not been to proper Scrum Training, be sure not to use too much Scrum speak — keep it very simple and mostly devoid of Scrum terminology.  Also, definitely focus on the business benefits of Scrum that align with organizational desires and goals.  The more you can point to those higher organizational desires the more buy-in you’ll likely get from those higher in the organization!

The New New Scrum Master should also be able to communicate the benefits that will appeal more to those on and around the team, such as:

  • Benefits to Development Team members
  • Benefits to Business Stakeholders
  • Benefits to Product Owners

Again, the same advice as above, be ready to rattle off a list, be ready to explain how different parts of Scrum support each of the list items, and be ready to avoid Scrum terminology for those who haven’t had proper training.

Knowing the “Why’s” behind Scrum will help convince others of “why” to pay attention to your teaching and coaching.  Notice I said “help convince” — it will likely take much more than that, but knowing these benefits is a “must have” for those conversations.

Knowing the “Why’s” behind Scrum is just one aspect of “teach/coach.”  Don’t misunderstand me, teaching and coaching is actually more than just teaching and coaching — using those two terms is simply a way to oversimplify this focus area.  You might also want to mentor, advise, and facilitate at times.  But even those things can fall under “teach/coach.”  We’ll explore this more in future posts.

Removing Impediments

The second New New Scrum Master focus area is removing impediments that are beyond the reach of the Development Team.

There is a common misconception that the Scrum Master is responsible for removing *all* impediments for the Development Team.  While the Scrum Guide is a little vague on this subject, it is somewhat hard to articulate the fine balance between the Scrum Master’s duty to remove impediments, and the Development Team’s responsibility to self-organize. This misconception drives a lot of failure in Scrum implementations.  We’ll explore this more in future posts.

The metaphor I like to use here is “Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.”  When respecting and coaching on the Development Team’s obligation to self organize, it is important for the New New Scrum Master to realize when is the right to time to give the fish, and when is the right time to teach to fish.  The answer is usually the latter, but sometimes the former.

Remember:  Teach/Coach, and Remove Impediments

I have thought about this a lot, and have even conferred with my fellow Scrum coaches on this.  Pretty much all of the responsibilities of the New New Scrum Master boil down to the two focus areas of “teach/coach” and “remove impediments.”

In future articles, I will go deeper on each of these two focus areas.

In the meantime, do you think any Scrum Master duties cannot effectively fall under those two focus areas?  If so, what are they?  Sound off in the comments below!

The New New Product Owner: The Product Marketplace Expert

In my previous post, I discussed the 7 focus areas for the New New Product Owner, as well as the “Product Value Maximizer” focus area.  In this post, we explore the “Product Marketplace Expert” focus area.

The New New Product Owner should be expertly aware of the marketplace for the product. They should constantly be gathering and re-gathering information and data regarding the marketplace, so that the product value is maximized. Getting out of touch with the marketplace can be a recipe for product disaster. Note here that the New New Product Owner may or may not be the one doing the legwork of gathering the marketplace data(they might delegate), but they should certainly be aware of the market research.  Often times the New New Product Owner will delegate to others or to automation to aid them in obtaining the market data.
POFocusAreas_NewNewPONote that your market might be internal (IT software) or external (Saas, Consumer software).  Either way, it’s important to gather the marketplace data.

With IT software, the market data will often include how the LOB(Line of Business) uses the software, as well as understanding the business function that the LOB executes on.  Heavy interaction with those in the LOB will usually yield this data, or again, the New New Product Owner might delegate or rely on someone in the LOB to supply her with that data.  A good starting point for gathering this data is understanding who your key stakeholders are.

Additionally, the New New Product Owner should never be afraid to change the vision or tactics based on marketplace changes. Being able to strategically re-pivot and capture value in new and different ways is one of the key benefits of an Agile mindset.

For a high quality class that focuses exclusively on the Product Owner role(the course is also great for key stakeholders!), see our Professional Scrum Product Owner class and contact us if you’re interested in one.

The New New Product Owner communicates all of this marketplace knowledge to the Scrum Team through daily ad hoc interactions as well as Product Backlog Management, Product Backlog Refinement, and in Sprint Reviews.

Knowing the market for your product can help you fulfill another key focus area, being The Product Visionary.

The New New Product Owner: The Product Value Maximizer in Scrum.

Preface:  In the last 4 years, the Scrum Guide has had two very significant updates, including updates to the Product Owner role that have far reaching implications. In this article and the series that follows, I attempt to describe “The New New Product Owner” role in Scrum.

In a series of upcoming articles, I will detail the different focus areas that the modern Product Owner needs to concentrate on in order to fulfill their duties on a Scrum team.
POFocusAreas_NewNewPOThe New New Product Owner understands that she will likely need to execute these activities at different times, and that she might need to delegate to others in order to effectively produce software that maximizes ROI for the software development effort.

The first and most important focus area is for the Product Owner to be the “Product Value Maximizer.”  There are lots of way to do this, but 3 key steps are involved:

  1. Order the Product Backlog by (estimated) value.
  2. Work with the Development team to get small increments of value to market quickly, for feedback.  Release to market = in production, available to end users.
  3. Rapidly assess value delivery feedback from the market, and then start over again at step #1.

These three steps will ensure that the New New Product Owner delivers “the right thing.”

Note that your market might be internal (IT software) or external (Saas, Consumer software).  Either way, it’s important to get features into production quickly, and to assess whether we have “hit the target” with respect to value… or not.  This quick release to production, every few weeks, is a key aspect of Agile software development.

If you haven’t already signed up for our blog, be sure and sign up (upper left hand corner) so you will get the future articles on this topic!

In future articles, I will detail the remaining six focus areas for the New New Product Owner:

  • Product Marketplace Expert
  • Product Visionary
  • Product Release Decision Maker
  • Product Backlog Management Leader
  • Lead Facilitator of Key Stakeholder Involvement
  • Effective and Active Scrum Team Collaborator

For a high quality class that focuses exclusively on the Product Owner role(send your business stakeholders too!), see our Professional Scrum Product Owner class and contact us if you’re interested in one.  We teach all over the USA.

User Stories – Focusing on Conversations instead of Writing – Gojko Adzic’s New User Story Book

In my recent article on telling user stories instead of writing user stories, I mentioned that many Scrum Teams focus way too much on documentation and way too little on good collaborations.

More support for this concept comes from the first chapter in Gojko Adzic’s new User Story book, Fifty Quick Ideas to Improve your User Stories.

User stories imply a completely different model: requirements by collaboration. Hand-overs are replaced by frequent involvement and discussions…. If requirements are just written down and handed over, this discussion does not happen. Even when such documents are called stories, by the time a team receives them, all the important decisions have already been made…. Try telling stories instead of writing down details. Use physical story cards, electronic ticketing systems and backlog management tools just as reminders for conversations…Engage business stakeholders and delivery team members in a discussion, look at a story from different perspectives and explore options. That’s the way to unlock the real benefits of working with user stories.

Gojko has been nice enough to publish the “Tell stories, don’t write them” chapter available completely free here!  It is also important to note, that this chapter is tip #1 in his book, as it really sets the stage for the best use of the User Story practice.

The User Story practice was always intended as a very close, verbal collaboration between the Dev Team and the PO/Customer. In modern times, you can achieve this very easily with good Product Backlog Refinement practices.

Anyway, it’s totally worth another five minutes of your time to read Gojko’s free chapter, and be sure to share it with your teams and organizations too!

To maximize your Scrum and User Stories practice, bring us into your company to deliver coaching or our User Stories Class.

Focus on Telling User Stories, NOT Writing User Stories

Ebin Poovathany has written a wonderful article on how we should focus more on the verbal conversation aspects of User Stories rather than focusing too much attention on “writing” User Stories. I myself have written an article about this as well (See Trap #’s 1, 8, 10,and 13). It’s great to see that this topic is starting to get more attention in the industry.

As Ebin points out, using so called “User Story Templates” (“As a user, I want..”, “In order to…I want…”, etc) causes people to backslide into older waterfall habits, and creating the same old kinds of documents that we used to create in waterfall, along with the same old problems. He sad this is sad, and as a User Story proponent, I agree. It’s a horrible misunderstanding, but it’s rampant in our industry. The User Story practice was always intended as a very close, verbal collaboration between the Dev Team and the PO/Customer. In modern times, you can achieve this very easily with good Product Backlog Refinement practices.

Anyway, it’s totally worth your five minutes to read Ebin’s article, and be sure to share it with your teams and organizations too!

To learn how to avoid User Story Traps and maximize your User Stories practice, see more info about our User Stories Class.

New advanced Scrum certifications!!

Happy New Year!!

I’ll post more updates on this exciting development as the new assessments and credentials go into service!

http://blog.scrum.org/scrum-org-professional-series-updates-2015/

We will be providing PSM II courses later this year for those who want to take their Scrum skills — literally — to the next level.

Should I use hours to estimate my tasks in Scrum?

My new recommended “starter” “complementary practice” for new Scrum teams is to simply create tasks and use the “number of tasks remaining” for a burndown.  (I also usually recommend that they try to make it such that the vast majority of their tasks are roughly 1 day or less) I encourage them more to focus on PRI (potentially releasable increments), Sprint Goals, and achieving a moderately consistent level of skill at meeting their Sprint forecasts (used to be called “Sprint commitment,” it’s been re-named in the Scrum Guide).  I also caution heavily against trying to achieve perfect forecast accuracy as that’s a fool’s errand in complex domains.

Using hours for tasks can lead down some really bad roads, most notably:  Former PM’s turned SM’s and other organizational members who try to apply PMI tactics (100% utilization, tracking actuals, etc) tactics to complex software development.  By preferring “sticking to the plan” over “responding to change”, they are completely violating Agile and Scrum.

This same bad road can also lead companies into think that “schedule/scope/cost” is an optimum model for software development.  As far as I’m concerned, schedule/scope/cost is a dead, failed model for software.

Now, using hours for tasks doesn’t have to lead down those bad roads — but in my experiences, they usually do.  Let’s not forget, Scrum used to require hours for task estimation, many years ago, but the Scrum experiences of the wider community over 20 years has spoken on the topic — hours is not always optimum.  I would go farther than that and say, at the Sprint task level, it’s usually NOT optimum.

Given the above, I’ll leave it as an exercise to others to describe where using task hours might not lead down those bad roads.

_____
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com

New Courses from ScrumCrazy.com:

  • Scrum For Executives
  • Agile Requirements: Product Owner and Team Collaboration Techniques
  • Scrum Product Owner: Techniques for Success
  • Evidence Based Management for Software Organizations(TM)
    • Class for Software Development Managers and Executives

If you’re interested in any of our classes, training, or coaching services, feel free to contact us.

Follow

Get every new post delivered to your Inbox.

Join 387 other followers

%d bloggers like this: