Peter Stevens’ Scrum Breakfast Blog

Home / Peter Stevens’ Scrum Breakfast Blog
Peter_steven's_scrum_breakfast_blog
Peter Stevens, Entrepreneur and Scrum Trainer

Scrum Breakfast

Blog about Scrum: Getting started, Crisis Project Management, and Transforming IT into a Lean Organization.

Scrum is simple to understand but difficult to master(?)

Posted on March 31, 2018, 11:02 am
According to the Scrum Guide, "Scrum is... Simple to understand, Difficult to master."


I have never agreed with this statement. Scrum is easy. I can explain it in 5 or 6 sentences. If you agree with the basic principles and design decisions, Scrum makes sense and is very easy to follow.

However, most organizations are not structured around these principles. Scrum therefore implies changes in how people work, and those changes are really hard for most organizations:
  1. Deliver something of value at least once per month. Many developers and teams are not capable of doing this, and have to learn a lot of new skills. Their organizations are structured around not doing this. Changing this is hard.
  2. A team solves the whole problem (from idea to done). This implies feature-teams, but most organizations are organized as component teams, so this implies a reorganization. This is hard.
  3. One voice speaks for the customer. The means decision-making about the product is delegated into the team. This fundamentally changes the conversations with the team, from commanding to discussing; from tell to consult, advise and agree; from about what to do to about why and how to do it. This implies rethinking how leadership works, and this is hard.
  4. A coach helps everybody get better. This introduces a new role whose value is barely understood to serve people whose value is massively underestimated.
  5. Inspect and adapt at regular intervals: this means examining yourself and changing. Inspecting may lead to recognitions that are not consistent with your self-image. When the team discovers something that needs outside help to fix, management is expected to make it happen. Who is now telling whom what to do? This implies taking priority requests from people you used to give orders to. Lots of things about adapting can be hard to do.
I think the challenge of doing great things with Scrum is reflected in “the first impediment”: not having a Scrum Team with the skills and authority necessary to be a Scrum team. The PO can’t decide. The Team is not cross functional nor does it own their time or infrastructure. The Scrum Master does not have time or access to management to make improvements happen. Fail before you begin.

If you want to get off to a good start with Scrum in your organization, get your management involved to fix or prevent the first impediment! Get the roles right. I believe if you do that, everything else is much easier.


Read on the blog

Lowest prices for Scrum Training

Posted on January 9, 2018, 11:14 am
Why do you want to teach your team Scrum? From a company's perspective,  one answer dominates: better results, faster. I spent much of last year talking to my customers about this goal, why it is so hard to achieve, and how can I better help my customers achieve this goal.

Click to watch 10 Things your Management Needs to Know about Scrum and Agile
Watch my Lightning Talk:

I have designed new services and new price options to better support you on your Agile voyage, including what I believe is the lowest published price for a 3 day Certified Scrum Master Training in Switzerland.

How can I help you to achieve these goals:
You can get help and support from me and other practitioners through my online mentoring program: Achieving Performance Through Agility ("APA"): Group Mentoring with Peter Stevens. You get help with your transition challenges; to learn from other practitioners; to discuss specific problems with your peers; to develop & cultivate your own Agile Mindset; and a forum to share your successes! You get to participate in monthly calls with me and your peers, access to our shared resources, and admission to our semi-annual Agile Retreat.

More importantly, I have designed course packages to help you achieve your goal of a high performance team and keep you costs down! Check out the packages:
  • No Frills. Book 90 days in advance for my best price! (60 days for the courses this spring). Just training, no additional services, so the course is even freed from VAT. As far as I know, this is the lowest published price for a 3-day Certified Scrum Master or Scrum Product Owner or training in Switzerland. Perfect for individuals and self payers!
  • Standard Economy - the classic course with lunch provided at the venue.
  • Premium Economy - Support for your first step on the road to a high performance team. Includes participation in your first group mentoring session with Peter Stevens
Booking "Business Class" gives you the APA mentoring program at a substantial discount!
  • Basic Business Service - Support on the road to a high performance team.
    Includes 6 months membership APA, including admission to the Agile Weekend Retreat.
  • Extended Business Service - Long Term Support on the road to a high performance team. Includes 12 months membership in the APA, including admission to the Agile Weekend Retreats.
Check out the prices and packages:
Of course, if you have any questions, you can always reach out to me here!



Read on the blog

A concrete alternative to estimating story points in Scrum

Posted on December 3, 2017, 8:33 pm
Estimating is such a pain. I remember when I first read about Scrum and saw that the team was responsible for estimates, not the Scrum Master. I was sold!

But... estimates are controversial. Without estimates many stakeholders are unwilling to fund development efforts. The upside is that the process of discussing the stories in the team helps everyone understand what the feature is about. It's about the conversation, not the number. OTOH, estimates do not produce value for the user, so they are potential waste, and may be used to beat up the team if the estimates are not correct, which is even more counterproductive.

Story points are particularly controversial, because they are vague and fragile. Using real or hypothetical hours has other disadvantages. (What do I do when my customer only wants to pay the hypothetical hours, not reals ones?!)

I believe you can base estimates on something more concrete and measurable: Acceptance tests.

This satisfies the need to estimate larger projects, while eliminating the main drawbacks of story points and maintaining the benefits of estimation from the team perspective. Let me explain how I came to this conclusion.

"Shouldn't we create estimates now?" Yesterday, I lead a group of aspiring Product Owners through a 1-hour Scrum simulation to create the "analogue version" of the products they had conceived in the previous exercises. After the teams had created their forecast for the sprint, they wondered if they should estimate.

What is the value-add of the estimate? At this point, not much, because they have already made their forecast, which is itself an estimate, and they would be wasting time that they could use to actually produce the result.

I suggested instead that they make sure they are clear on how to verify that the goal of each story has been achieved. Write the goal on the front of the card, and the confirmation on the back. If the goal or the confirmation are too complicated to fit on a single card, make more cards, each with a goal and confirmation, until the cards add up to the original goal.

Does you recognize the XP (Extreme Programming) approach here? The three C's - Card, Conversation, Confirmation. The description and the confirmation have to fit on one card (I use 1/3rd of A4, but A5 or 4"x6" are probably okay too). A card corresponds to an acceptance test.

Does anyone see the similarity to Pawel Brodzinski's "#Noestimates scale"?
  • 1 - fits easily into a sprint. 
  • TFB. (T means "too", B means "big" and F is for you to figure out)
  • NFC (N mean "no", C means "clue" and F is forever the same)
Estimating in #NoEstimates is simply breaking the stories down to until they are standard size, then counting the cards. My understanding is XP cards are usually very small; many fit easily into a sprint. So XP cards count as a "1" on the #NoEstimates scale.

Counting the cards is the same as counting the acceptance criteria, which in turn is creating an estimate.

How can you use acceptance criteria to estimate a project?

Story points and planning poker were a big leap forward. The discussions between the development team, product owner and other domain experts facilitated a common understanding of the problem to be solved, and eliminated the need to do work-breakdown analysis. Using this approach us you can use simple math and charts to predict and monitor how much functionality will be done by when. Using the Fibonacci sequence or the Cohn scale addressed the problem of false precision.

The main drawback of this approach is that story points are vague and fragile. If you put them under pressure, they break. (Is this a 3 or a 5? The product owner wants higher velocity, so let's call it a five!) Because they are difficult to standardize, it is difficult to compare velocity of different teams. Teams often ask to re-estimate because something is more work than they thought it was.

What if the basis could be more objective? 

Acceptance Tests: A concrete basis for estimates

How might this work in practice? Given this story for a job portal: 
  • As a job hunter, I want to submit my CV with my application for (reasons that should be obvious)
How to know how big the story is? After discussion the team and product owner agree on the following workflow (I call this "how-to-demo"):
  • Given I have selected a position to apply to...
  • Step 1 Create an application
  • Step 2 Attach my CV by dragging it to the application
  • Step 3 Preview the application to submit and see that the CV is attached.
Assuming that these steps are sufficiently granular that they fit easily into a sprint, each one becomes a point, and the story is a three-pointer. 

A tangible estimate

One point equals one step in the how-to-demo. 

If any of the steps are too big, it becomes a new card with its own how-to-demo. So let's say Step 2 is "TFB", then we would make a new card. Create and preview the application are each one point, and Attach the CV depends on the number of steps to validate it. If this is also three points, then the total for this feature is 5.

How do you estimate before the start of the project? Simple. Use planning poker, but instead of applying some abstract size, you are guessing the number of acceptance criteria you expect to satisfy. 

Tracking progress

As you implement the project:
  • you take credit for acceptance tests satisfied, just as you did with story points. (The issue of partial credit disappears, because the stories are very small, and a test is passed or not).
  • if the requirements change, you update your guesses accordingly. Do you expect to have more, fewer or the same number of acceptance tests?
  • In backlog refinement (getting ready to implement), your guesses become actual acceptance criteria.
  • Replace your guesses with the actual number of steps in the how to demo. This enables you to keep track of how good your estimates are, because for each story there is an estimated number of steps and the actual number of steps.

Budgeting

As with story points, this approach requires a baseline for comparison. How many individual acceptance criteria can you team actually get done in a sprint? Once you have established this, the math should be the same as for story points: (Size / velocity) * Team Size * Sprint Length = Estimate in Person days.

Summary

A point corresponds to a step in your how-to-demo confirmation workflow. An estimate is a guess of how many steps there will be to confirm the story. Backlog refinement confirms or updates the estimate and produces fine-grained stories which are ready for implementation. Velocity measurements, budgeting, a estimating function much like convention story points.


3/12/2017 -- Updated to recognize Pawel Brodzinski, the source of what I dubbed the #NoEstimates scale.  His discussion of the topic is quite illuminating!



Read on the blog

10 Things to tell Management about Scrum and Agile

Posted on October 7, 2017, 5:38 pm
I was recently asked, "what does management need to know about Scrum?" Here is my answer, in 10 bullet points:
  1. Market forces are driving shifts in how leadership leads
  2. Scrum is a simple, team-based, “Agile” framework for solving complex problems
  3. You can probably get twice the value in half the time through Scrum
  4. Changing for better performance seems obvious but requires a huge shift in your culture 
  5. Only apply Scrum if you are prepared to make the necessary changes to get better performance
  6. Agile is a mindset not a toolset, nor a religion
  7. The transition to Agile is an investment
  8. Shared goals and the ability to agree on priorities are key success factors
  9. Start with a concrete project and follow quickly with your leadership team
  10. You can do all the stuff you did before, like budgeting and scheduling, just differently (and probably better).

Edit: updated to reflect that Agile is neither a toolset nor a religion.
Read on the blog

How to become a Scrum Alliance Certified Scrum Trainer

Posted on September 26, 2017, 10:39 am
What does it take to become a Certified Scrum Trainer (CST)? The bar is known to be very high. In this one hour webinar I held for the Discuss Agile group, I talk about the challenges of becoming a CST, tell my story, present the requirements for becoming a CST and discuss the challenges of finding a good mentor.

Read on the blog