Becoming agile

Agile, through the storms

Archive for the tag “SCRUM”

Just like riding a bike

I have heard more than a few times that games and simulations in training courses are irrelevant – specifically in Scrum and other agile courses. That doing Scrum using Lego bricks is too simplistic and does not represent real life in any way.

Similarly I have heard, and keep hearing, that the agile management tool should be selected early, even before the implementation starts. The rationale is that individuals need to learn the tool and become familiarized with it before they learn the rules; also that the tool will imply limitations that must be integrated into the process.

Photo by boegh
http://www.flickr.com/photos/boegh/5676964602/

Empirical research suggests that this is not quite the case. Actually quite the opposite may be true.

I am starting my argument with a reference to series of experiments on rats, researched and partly conducted by Edward Tolman. In Cognitive Maps In Rats And Men, Tolman describes how rats learn a map in their mind. It is an interesting read, written in an easy to understand language, even if you are not in the habit of conducting research on social science.

Tolman describes, in one set of experiments, how rats that learn a maze without being stimulated (“incentivized”) to reach a food-box, improve their performance once food is presented – at least as much as rats that were stimulated for food from the first attempt. Moreover, some rats have learned the approximate location of the food-box and jumped out of the maze, running in a straight line to their goal. That is, rather than learning only the correct maze route, they also concluded the spatial location of the food-box.

This last spatial map has also been researched and is described in the same article. Even when the maze was subsequently blocked, and the orientation of the experiment setting turned 180 degrees, most rats figured out the location of the food-box relative to the room. That is, the rats understood where they want to get to, rather than how to get there.

The term Latent Learning describes this ability of learning without having to express it immediately.

Additional research proves that squirrels remember the location of their caches, not merely using smelling as a guide. See Jacobs and Liman research as one example for this. Moreover, squirrels returned to their own caches, not to nearby caches of other squirrels.

Initially these experiments tried to refute the ‘hard core’ behaviorists that suggested that learning can only exist when sensual stimuli is present. But they brought, as Tolman’s title suggests, a deeper understanding of learning and remembering.

How is this related to the title? And why do people think that learning by simulation or that changing agile implementation tools is not productive?

I believe that this is related to a common human dysfunction, a cognitive bias, called Functional Fixedness a term coined by Karl Duncker. This is the opposite of out of the box thinking: Say you are on a phone call at the office on your Android device, and the other party asks for a phone number stored in your phone book. Some people will search for the number on their phone, having to stop the conversation momentarily. Where is the functional fixedness? Since you are at the office, you could login to your Google account on your computer and get access to the entire phone book from the Contacts application, since Google automatically synchronizes phone and Google account.

The funny thing is that we are convinced that others suffer from Functional Fixedness more than we do, and we attribute others with tendency of not being able to change from one tool to another. The fact of the matter is that we are all functionally fixated at times, just like any other person. At the same time, we all have capacity to learn cognitive maps, and are able to adapt, just like any other person (even like most rats, as it turns).

So if you are embarking on an agile journey, and considering a tool, start by using a physical board and sticky-notes. Experience shows that introducing a CR (Change Request) to the physical board has an incredibly better time-to-market response, at a fraction of the cost, compared to changing other software based tools. Yes, even if this means making configuration changes to a free tool (as someone will have to spend time making and testing these changes).
Even when distributed teams are involved, the cost of a HD camera and Skyping daily stand-ups will be much cheaper than any online collaboration tool.

Now, please don’t get me wrong – I think that tools are important; and the bigger the organization the more important they become for visibility, collaboration, continuous planning and more. But it is much easier to make mistakes on a physical board, and start afresh next iteration, than carrying the history of your mistakes for numerous iterations to come.

Similarly, the importance of simulations during training course and workshops is immense. There is huge value in practicing though games and simulations while you are in learning mode, in Beginner’s Mind or Flow. Running several Scrum sprints in a couple of hours will help you practice Scrum while you are focused on learning it. When you learn Scrum on the job, while you are busy with yesterday’s bugs, where to eat lunch and your upcoming appraisals is rarely as effective as learning during a training course.

We tend to believe that we are rationale beings, not affected by patterns; that once we tell ourselves to try out a new thing it will work right away. Evidence suggests that our minds are more complex this. Learning the principles of agile using simulations and then practicing through one tool later implementing another appears to work. Just as learning to ride on a training bicycle and gradually advancing to specialized models.

Bread Scrums

There are many reasons to go SCRUM in particular or agile in general. Each organization will have their own reasons and motivations. According to the 2011 State of Agile survey, top three reasons are to increase time to market, to cope with changing priorities and to increase productivity.

The question is, how do you know that you are getting there?

The default answer for most is KPIs. Measure it, and you will know that you are there. The problem with measurements is that they are very elusive. You want to measure one thing, and ending up affecting another. Regardless of the measurement, you may impact something that you didn’t intend to.

Why is that so? This is because when you measure things, you leave a trail, and this trail is not merely the guide to go back, it is also the guide to go forward, a kind of a forecast to the next target.

In fact, a trail is more useful to going back in order to fix things, rather than to predict where to go next. Take breadcrumbs navigation: It helps you go back in the application to re-navigate; it also helps you navigate faster on successive uses of the application. But it doesn’t help you predict what you are going to do. It can help you measure what users are doing most, in order to improve the navigation. Like in Hansel and Gretel, the kids wanted a trail back home, not a guide to go forward.


Source: http://www.flickr.com/photos/koiart66/3877752234/ by koiart71

Take an example. Many teams use velocity as their planning tool. They use the amount of done stuff, in relative size, in order to plan how much they can sensibly fit into the next iteration. It is a planning tool, not a measurement.

Yet, organizations try to use this velocity to do more than planning. After all, velocity can be a good measure for productivity or even predictability, can it not?

Yes, if your organization’s main business is velocity. When were you last asked by your customers: “For the next release we would like to order 54 points and 21 epics, please”? Is this the kind of predictability you require?

Check out Smith and Jones Predictable Lighthouse sketch – are you convinced that predictability is something you welcome that much anyway?!

What kind of trail can you use that will record something deliverable, and not an artificial, game-able, number that can have collateral impact that is potentially undesirable?

Let’s examine few of the options:

  • Velocity: Dear team, please provide more story points.
    No problem, dear manager. We’ll just skip all those tests, and the number is set to increase. Given that we do not provide the support, escaping defects will be anyway handled elsewhere.
  • Predictability: Dear team, please provide a consistent number of story points.
    No problem, dear manager. We’ll just provide the same number of points. When something big comes in, we’ll just bloat the estimate, so we don’t have to deal with breaking to smaller stories.
  • Cycle time: Dear team, please provide a standard ratio between points size to the time to develop it.
    Now here’s a good one. Cycle time can actually be a rather useful trail. But only if you consider it from a systemic point of view – which makes it much harder to measure. Otherwise, it may become similar to velocity

The problem with all the above is that it mixes several concepts into one number. The trail and the measurement are not one and the same. This is why using points or velocity as a measurement is risky. It becomes goal in itself, rather than means to a goal.

A much preferred trail is executable specifications, developed and described by Gojko Adzic in Specification by Example.

In such a trail, for every story you specify, in business context, WHAT is the system expected to do. This specification is turned later to an executable sequence that will verify that the developed code does WHAT it is expected to do. Note, that specification by example is not about HOW, it is about WHAT.

This makes a trail of business rules that have been proven, and are now part of our regression suite, and upcoming trail that is what business rules are to be proven in the coming iteration. In an analogy to the breadcrumbs navigation, where have we navigated so far, and where are we navigating to now. Note that over specifying (forecasting several iterations ahead) is likely to become waste.

Recall from the top of the post, the trail helps you go back and make corrections. In this executable specification trail, it enables you to either fix business rules that got broken due to changes, or to remove redundant rules – and code, in order to navigate better in the future.

Coming back to measurements – this trail is not a measurement. It is a trail.

If you must measure, try to check, for example, how many routes you are navigating on concurrently. WIP can be a good measurement for that. Yuval Yeret has a good explanation of WIP and using CFD to measure it. Once in place, you can start measuring also cycle times, but as a supporting tool for your WIP, not as a guide to limit story duration.

Alternatively, try to use Agile Earned Value Management (EVM). You may read about it in Tamara Sulaiman’s article here. While Agile EVM is useful for planning against budget, it has some hidden assumptions, such as scoping for the entire release.

The merits of one measurement or the other is the subject for a separate post. I will just comment that I like these measurements more than others because a) they are good tools for decision making, and not merely measuring; and b) indeed they are based on the trail but not measuring it.

As long as you remember that the objective of the trail is to correct yourself – to make the right decisions, you will be ok. Don’t force measurements if you cannot effectively use them for decision making.

Otherwise, you may find that you were hoping for breadcrumbs and instead of SCRUM you we left with, well, just the crumbs and no trail.

Suggestion Box

How do you get your team to become innovative? To generate new ideas?

Our default intuition is to ask people what they would like to improve. Well, this is good, but the real question is – is it good enough?

Take this photo, for example. How effective would it be in generating good suggestions? How sustainable will it remain over time?


Photo by Sethoscope

Our intuition tells us that if we tell others to do something, they will do it. However, we rarely apply the same intuition on ourselves. Say someone else put the suggestion box – how inclined would we be to participate and contribute new suggestions?

A learning team needs to nurture a learning culture. Think of those two words: nurture, culture. This implies that we need to cultivate it, and provide the fertile grounds for it to sustain.

Recently Mark Levison provided us one example of how to overcome technical debt and to increase the team’s evolvement and evolution into a team that learns how to learn.

He has used Michael Feathers’ brillirant book, Working Effectively With Legacy Code, to try out techniques of carving out problematic areas of our code, and refactoring them into code that is more maintainable and sustainable.

The point is one of courage. Will you be the first to lead this change? If someone is already leading such a transition, or attempting to, will you be courageous enough to join the ride? Take Derek Sivers‘ short clip about the underestimated kind of leadership – being the first follower.

Courage, as I have found out, is something you realize in the aftermath. Looking back in retrospect you say to yourself – “Where did I find the courage to do this?”

The order “Be courageous” in that sense is about the same as saying – put your suggestions in the box. If you are looking for courageous people, think whether you, as a team, are cultivating the atmosphere for such behaviors to emerge.

Not sure how to start? Make the first courageous decision, and get educated on the values, principles, and practices that will get you there.

Taking a good SCRUM course may be a good starting point. My colleague Elad Sofer is running a SCRUM course at the end of April (as do several others in Israel, and many around the world).

Register to this course at the course website at http://www.practical-agile.com/training/scrum-training-menu/practical-scrum

If you feel courageous enough to improve your retrospective skills, try our one day workshop

Post Navigation