How to stop SCRUMBUD

[Harold Brister]

Hello,

I recently became a CSM and I am trying to implement SCRUM within our organization. I am working with a small development team to build an app using SCRUM.

The team is made up of 2 developers and an interface designer. We had a sprint planning meeting, and we 7 days into a 10 day sprint, in which, not one user story has been completed.   

The challenge:

- The developers want to change the acceptance criteria for the first and most vital user story. Solely to make development easier for them. Their claim is that if they have to meet the acceptance criteria (established and agreed upon in the sprint planning), then development will take much longer.

- The developers are now claiming they need clarification on other user stories. the problem is those user stories aren't part of the current Sprint. 

- At this point, they have made it clear they will not complete one user story within the current Sprint.

As a note, this team has a history of this behavior, including missing deadlines, and not completing deliverables to standard. A common practice amongst them is claiming they had no clarification, or misunderstood an objective when they don't make their deadlines. Their manager was hoping SCRUM could help them focus and take accountability. 

We are not practicing SCRUM right now, we are in SCRUMBUD. I am looking for input as to if this is really a SCRUM issue, or if this is an issue their manager needs to address with them and hold them accountable?

[George Dinwiddie]

Harold,

From what you say, it's almost certain that the user stories are too
big. Learn how to slice them to get useful increments of functionality
in a couple days.

If you want, you can post the acceptance criteria for this story and we
can talk about ways to split the story.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Ron Jeffries]

Harold,

Some thoughts, and maybe some questions …

On Mar 30, 2017, at 9:26 PM, Harold Brister <h_br...@hotmail.com> wrote:

I recently became a CSM and I am trying to implement SCRUM within our organization. I am working with a small development team to build an app using SCRUM.

The team is made up of 2 developers and an interface designer. We had a sprint planning meeting, and we 7 days into a 10 day sprint, in which, not one user story has been completed.   

User stories are best, I find, when they require one or two days’ work. It’s really difficult to be ten days in and have nothing completed when stories are that small. So I’d want to look at the stories and find out things about them.

The challenge:

- The developers want to change the acceptance criteria for the first and most vital user story. Solely to make development easier for them. Their claim is that if they have to meet the acceptance criteria (established and agreed upon in the sprint planning), then development will take much longer.

Well, then, the one thing I’d bet is that they’re right. And the phrase “solely to make development easier for them” seems to me to be a bit of a red flag about someone’s attitude, maybe including yours, toward the developers. It sounds as if we think it’s OK for things to be hard and not OK to make things easier.

Fact is, when we set out to build something complex, it’s best to build it up in pieces. It’s best to start with simple acceptance criteria and then make them more complex and difficult as the code grows and evolves.

So to insist on some huge and complicated acceptance criterion for something that didn’t exist at all at the beginning of the Sprint is to work against reality. Far more productive would be to work to build up a series of refining acceptance tests.

To digress to a simple example:

When Chet and I demonstrate pair programming and continuous refinement, we work on a little program that calculates the scores in ten-pin bowling. We do a series of acceptance tests:

1. Calculate score for a game where no pins are knocked down;
2. Score a game where some pins are knocked down but no strikes or spares;
3. Score a game with a spare;
4. Score a game with more than one spare;
5. Score a game with a strike.

Each of these steps, it turns out, adds a bit more of the “meaning” of bowling, and moves smoothly toward the complete implementation. Doing the work stepwise is simpler, because each step is simpler.

It is in the interest of the whole organization to keep things simple and stepwise. If is, therefore, concerning to me to hear you talking as if the developers were being somehow bad.

It makes me wonder whether, at the beginning of the Sprint, the requirements were actually clear. Were there defined acceptance tests, each one testing just one aspect, figured out? Or were there no defined tests at all?

It makes me wonder whether the developers were told how many stories to do, or pressured to do more. It makes me wonder whether the explanations given during Sprint planning were clear.

My bet would be that there was pressure and that there was not clarity. My bet would be that in their hearts the developers knew that. I’d be curious to know, if that’s true, why they didn’t feel they could say so.

- The developers are now claiming they need clarification on other user stories. the problem is those user stories aren't part of the current Sprint. 

I think of two main reasons for this. First, it’s certainly true that some changes are easy and some are difficult, to existing code. So it is tempting, at least, to want to know what’s next, so as to be sure the code will not be unable to easily support the next stories. I’d particularly feel that way if management were making me feel a lot of pressure to go fast, because I’d be expecting to be berated next week if I said things were difficult. Especially since you’re pissed off at me this week because I’m saying things are difficult.

Second, though, it takes a fair amount of experience building incrementally to become confident about the code quality, to the point of being confident we’re ready for anything. Even then, I like to know what’s coming up. I try not to over-prepare, which is always a risk, even with skill. I’m guessing these devs don’t have a lot of skill in refactoring and incremental development, so they’re afraid of being blind-sided. That makes me wonder if some training would help.

There may be other concerns. Those would be the top two I’d explore were I working with this team.

- At this point, they have made it clear they will not complete one user story within the current Sprint.

I would consider: Cancel the Sprint, plan a new one. Pick one story that they think they can complete in two days (of a two-week Sprint). This should be a slice of the most important story but a slice they are certain they can do it two days. One day would be even better. Product Owner works with them to come up with simple one-element acceptance tests defining this tiny story. Do the story, see what happens.

I am wondering now whether there even IS a Product Owner. I’m wanting to explore how the “deliverables” are defined, explained, understood. I’m kind of expecting to find trouble in that part of the process.

As a note, this team has a history of this behavior, including missing deadlines, and not completing deliverables to standard. A common practice amongst them is claiming they had no clarification, or misunderstood an objective when they don't make their deadlines. Their manager was hoping SCRUM could help them focus and take accountability. 

This phrasing, with words like “history”, “behavior”, “claiming” seems very much us versus them, and not team oriented. “Accountability” is particularly troubling. It suggests to me that there is a culture of blaming going on. It suggests that I might find people telling people what to do, without much clarity, and then shouting or being visibly disappointed when it doesn’t turn out as hoped.

We are not practicing SCRUM right now, we are in SCRUMBUD. I am looking for input as to if this is really a SCRUM issue, or if this is an issue their manager needs to address with them and hold them accountable?

The term we usually see is ScrumBut. Scrum is not an acronym so is usually only capitalized like a name. And the suffix “but” comes from phrases like “We’re doing Scrum, but …. We don’t have a Product Owner”, and other such things, where people are undertaking something maybe kind of like Scrum without actually doing what Scrum says.

All these ideas are just those that I get having worked with lots and lots of teams. Your situation is of course unique. And, of course, it is also probably a lot like the situations of many other teams all over.

Tell us more ...

Ron Jeffries
ronjeffries.com
Sometimes you just have to stop holding on with both hands, both feet, and your tail, to get someplace better. 

Of course you might plummet to the earth and die, but probably not: you were made for this.

[Andy Watkins]

Harold, 

If I've understood correctly, you're 7 days into your first ever sprint. There will be lots of aspects of Scrum that will take time to work out.

Ron is right about helping make the dev team easier. If I can use a car (automobile) analogy, the cam belt on my car needed changing. The mechanic said it was really easy, but you have to take half the engine apart to get to it. I bet he charged me more (in labour charges, maybe also adding an awkwardness factor) than on another car where the cam belt is easy to access.

Another thing to consider is that Estimating is not signing a contract about how long something will take. Estimating is a guess about how long something will take, with the limited knowledge we have during sprint planning. It's quite common for things to take longer as we delve into them and understand them better.

Take Ron's valuable advice, and break down the tasks (with the developers) into tiny pieces that can be delivered. If some of them slip, at least you have something to show at the end of iteration.

Andy Watkins

an...@wis.co.uk

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[miked]

Harold
Congratulations, you are on the way to being a great scrum master.
Here are some things you may find out as you grow.
All initial sprints are learning events.
1. The scrum team is learning how to talk and listen.
2. The user stories are poorly stated, contain hopeful outcomes,and are attempting to test with unverifiable acceptance criteria.
3. You and the product owner are just beginning to grasp how much coaching and assistance the business needs in defining user stories. In fact they may not even have an expressed goal or objective.

It is all good, it is how most of us start.
Use your retro to understand what all of you learned in the first sprint. Then sort the problems into two bundles. Escalate the bundle the team cannot addrees in a sprint. Create SMART actions for the ones the team can address.
Product Owners, each sprint invest time in the SMART actions. Finally the team agrees to work on only those stories ghat have a verifiable outcome. Amd you do another sprint.

[miked]

Ron
ScrumBut is a worn out phrase. It implies there Scrum is a known good solution and if we create a checklist then we are doing it right. Right?? Yuckie fail taste.
Let's try two complimentary posits that already exist in Agile and Scrum.
1. At any given time you are doing the best you can
2. Scrum and Agile principles require that you get better iteratively and incrementally.

[Pierre Neis | We&Co]

Mike, at least there is a checklist but also some principles and behaviour. Now there are 2 options: following these simples principles or not.

Now you can consider that the goal is to reach a scrum.

Scrumbut is usually the consequence of "pickup the brand of scrum" like:

• having scrum masters and product owner but no teams (rebranding the management position)
• pushing back work to developers with upfront analysis from an expert (master and servant)
• development team working for different Product Owners for several projects and support activities
• having developers working for several scrum teams
• scrum masters micro-managing the development team
• product owners having no vision and just collecting expectations (rebranding BAs)
• variable sprint lengths within one team
• not doing retrospectives
• not doing dailies
• not reviewing just demoing for acceptance by the Product Owner
• product backlog which never burns down
• transforming the managers in Chief Product Owners
• just focusing on the « methodology » and not understanding what to do (robot syndrome)
• considering scrum as a framework (where you only pick the cherries on the cake) and not as a « framework » or « scaffolding » enabling a safe to fail experiment
• thinking that you must ship each sprint
• etc… 

A couple of years ago, trainers used the « Shu Ha Ri » principles from japans martial arts to explain that you have to follow the rules (shu), then master the rule (ha), then build your own (ri).

Scrumbut is just doing badly the other way around.

PierreNEIS
Senior Lean Agile Coach | Associate
M: +352 / 661 727 867
UK: +44 / 203 239 52 60
wecompany.me | You can book me

Actually Scrum Coach for S4HANA/Hybris Billing @ SAP SE

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

[miked]

Pierre

 there are guidelines, not checklists. Checklists lead to constraining behavior measuring how well you fill in the checklist.  Guidelines encourage people to explore ways they can develop styles with the framework. Within a gudieline approach A team who spends 5 hours to plan a two week sprint is doing the best they can, we know this is a smell and that to lay this at the team's feet is an equal smell. The guideline approach shows more traction as it lead to improvement and work it through the same frame work.  Checklists lead to interrogations 

[Pierre Neis | We&Co]

Mike

Then, the best should be to follow these guidelines without calling what you are doing « scrum ». That is the point.

Indeed, Scrum is more structured for Development than Research and Development and a little discipline is required: the boundaries of the safe-to-fail container.

Scrumbut impact is stronger in organisation with multiple teams think you have a team in Phoenix, one in Toronto, one in London, one in Inverness and one in Capetown. On the paper you are all english native speakers, in the fact you have to find a common language to avoid misunderstandings.

In other hand, you can be in a R&D organisation where you are focusing on diversity of thoughts without goals or deadlines in any manners, then I do agree you can choose what ever you want. There is not a problem to use techniques from scrum but why do you need to call it scrum?

PierreNEIS
Senior Lean Agile Coach | Associate
M: +352 / 661 727 867
UK: +44 / 203 239 52 60
wecompany.me | You can book me

Actually Scrum Coach for S4HANA/Hybris Billing @ SAP SE

[Tom Mellor]

Why wouldn't you call it what it is.  If you play rugby, you call it rugby...not football, or cricket, or the 'ball game.'  People understand what you are doing or trying to do, in some form anyway.

[John Miller]

Tom, 

That is a great point! You changed my thinking around this now.

I also think of Mixed Martial Arts, where you take the best from each, to fit the purpose.

But, that is still saying what game are we playing. Being clear on that would be helpful.

John Miller

Certified Enterprise Coach

agileclassrooms.com

agileforall.com

On Apr 18, 2017, at 10:02 AM, 'Tom Mellor' via Scrum Alliance - transforming the world of work. <scruma...@googlegroups.com> wrote:

Why wouldn't you call it what it is.  If you play rugby, you call it rugby...not football, or cricket, or the 'ball game.'  People understand what you are doing or trying to do, in some form anyway.

[miked]

Since Scrum is based in bayesian logic, and it works supremely well in acquirig knowledge, you comments are a mystery to me. When scrum was first conceived, it was in a creative environment, a created a framework for addressing complex axaptive systems.
The current definition of scrum hightlights this.