Advanced Topics In Scrum

The bait…
Sometimes it is easy to get a quick qualitative observation and think
“oh its working”. A simple observation backed up by the group opinion is
taken as “good enough”, to inform us our scrum implementation is working.

The twist…
These teams rely too much on memory, which fades dramatically after 3
months thereafter their observations and response when something is
wrong becomes increasingly blind. (in other words, the excel spreadsheet
of data in their heads runs out of buffer and becomes corrupt)

The fear….
Any metrics can be twisted and the word “discipline” can be used as a
way of getting tough. Which then defeats the purpose. Developing good
quantitative measure that do not get usurped by management (or other
force) becomes the challenge. The fear is that metrics will be used to
push the team when a downward interpretation is made and thus encourage
gaming the system.

The loss…
Scrum Teams fail to build and leverage informative history based on
metrics. They rely too much on memory. Their scrum implementation
initially looks good but lacks sustainability because the guidance is so
weak.

Response:
Good metrics are essential to helping teams improve long term and
organizations learn. However, all metrics can be abused and misused
which will defeat the purpose of the metrics collected. It takes
discipline to not be reactive but, instead use these numbers to help
teams and organizations get better.

The Nokia test has been pointed out repeatedly as the way to test for beginning good scrum. It is listed at the bottom in it’s original form. I like to use a series of questions for appraising a scrum implementation.

• Are your sprints time-boxed to less than 4 weeks?
     Very good teams can vary the length from sprint to sprint but, only do so when the product has a clear and compelling need. Exceeding 4 weeks is just a bad idea for people since our memories are not the good. Your efforts can always be broken down to 4 weeks or less and it is always worth the effort to do so. If it is 5 weeks then to 4 weeks and 1 week or some patter like that but, keep it time boxed and less than a month.
• Have software features been tested and shown to be working at the end of each sprint?
     It is so easy to call something done that is not quite done. Finishing is a challenge. Great teams and excellent products are built by those teams that develop an ability to finish. 
• Are you causing paralysis by over analyzing instead of moving?
     When you find an opportunity to proceed you should move. Great teams avoid analysis paralysis by moving when the opportunity presents itself. Even if nothing is clear movement in any direction will reveal more information about the problem.
• Is there a product owner available to answer questions and prioritize?
     When this position is vacant or absent the team’s movements are erratic and often in the wrong direction. Moral becomes an issue and quality suffers.
• Is a product backlog prioritized by business value?
     Teams will work on what seems important to them first. Even if it is not what the business needs next. No surprises there. Without an engaged product owner the needs fo the product are not championed and efforts are often mis applied.
• Does your team create estimates for items in the sprint backlog?
     Your team should own the estimates in the sprint backlog the product owner should budget for items in the product backlog. Read Dan’s work on estimating vs. budgeting to clarify this concept.
• Does the team express their work so that a burn-down chart can be created?
• Does the team know their velocity?
• Are others like project managers (or anyone else) disrupting the work of the team?

The Nokia test is broken down into two parts. Often we see teams doing the 1st part but, not the second.

Part I: Test for iterative development:

• Iterations must be timeboxed to less than 4 weeks
• Software features must be tested and working at the end of each iteration
• The Iteration must start before specification is complete

Part II: The next part of the test checks whether you are doing Scrum (in Nokia’s opinion):

• You know who the product owner is
• There is a product backlog prioritized by business value
• The product backlog has estimates created by the team
• The team generates burndown charts and knows their velocity
• There are no project managers (or anyone else) disrupting the work of the team

I first heard of this test from Bas Vodde who worked at Nokia to develop this test.

My experience is that people become used to a certain way of doing it.
They build up habits so that they don’t have to think so hard about the
basics. Nothing is wrong with habits, habits let me move fast
(efficiently), like grabbing my wallet from the same place each day as I
can run out the door. However, they can become unintended calcification.
It is the willingness to acknowledge that we all form habits good or bad
and our willingness to knock the calcification off when we detect we
should that helps us be agile. Our brains are essentially lazy pieces of
meat that will favor doing the minimum necessary. Path of least
resistance

So, when a new technology compresses a feedback loop’s time horizon.
Then it is not surprising that people are often unwilling to adapt and
leverage the new time horizon.Why? “It stresses me out”, “I don’t want
to change” and ” nothing is broken”… I see scrum as a framework (or
detection mechanism) that makes finding these habits easier and calls
them to attention in such a way that people feel safe to face the
change. That is why I like to say Scrum is a pathway that when applied
with CARE, leads to a well formed team (a group of people working well
together) who maximize their ability to adapt in the face of their
challenges. You can call the above soft skills or whatever. The science
behind these views is becoming very supportive.

We typically realize scrum’s promise in development domains that require
a rich set of blended metaphors to consider the problems. Software
products typically demand strong well structured expressions that exceed
the limit of one person’s head; it is often done better as a group
activity and often more successfully. Software development has some of
the most rapid feedback loops available in complex development domains,
good teams maximize these loops. Soccer would be faster but, it does not
allow for the complex abstract thinking that software does.

Products that are made up of software, hardware, chemical systems,
mechanical, numerous embedded components and human interaction are what
I would call about as hard as it gets; helicopter anyone. We do all
kinds of things to shorten the feedback loops and learn as rapidly as we
can about stuff we don’t know about yet. At the end of the day, after it
comes together, are we ever really clear on how it happened? or where
were we simply successful enough at dealing with stuff we didn’t
expect. I believe we have some clarity but, mostly not.

A question I like to ask is “For conceptually complex development
domains, how can we get better at being adaptable in the face of things
we don’t know about yet?” This question fascinates, humbles and energizes me

–
_______________________________________________
Douglas Shimp
Managing Partner and Senior Consultant, CST
www.3back.com

“Applied Scrum, where the rubber meets the road.”

Before I get to the state of sa certification a little background
seems in order. This my perspective and is based on details that I
have gathered during my involement with agile and then as a CSM, CSP
and CST.

The Scrum Alliance was born out of a desire by Ken Schwauber, to bring
the benefits of the scrum framework to people. He had orginally
written a black book on Scrum and thought that would be sufficient to
ignite peoples interest. It was not and his work in Scrum was in
danger of fading into the background as an old wanna be good idea.

To resolve the problem of scrum not being recognized and the simple
yet incredibly pwoerful technology from fading away, Ken thought of
offering a Certified ScrumMaster course. Little did he know this
course would explode with demand as agile practioners and wanna be
practiuoners came running to the course. Within a short time there
were other experienced agile experts who saw this course as a great
way to influence the industry. As a result Ken was swamped with a
demand to teach this course and he was swamped with a demand to
train/allow other to teach his course.

The biggest lesson that was showing up in the demand for scrum

Agile provides many pathways to a well formed team (WFT). A WFT is an assset that can be used in a deployable sense for the benefit of an organization. WFTs help organizations pursue complex goals and can deal with large amounts of complexity in puruit of that goal. An organization that has a WFT should look at this as a Capital Asset that can be aquired when scrum/agile  is applied with care.