Getting Better

My guess, based on experience and many conversations, is that these are 'our' top 5 impediments.

1. Need better Product Owners
2. Not enough focus on removing impediments
3. Need better automated testing
4. Technical debt
5. No trend of improving velocity

When I say 'our', I mean overall, considering all the teams I see and hear about.  On average.

So, do these resonate for you? Or, as a general rule, do you find other impediments in the top 5 in the first year?

I hear people often say 'lack of support for agile from top management' as one of the top 5.  If we phrase that as 'inability to convince top management to support agile' at least that gives us the power to change ourselves (become more convincing) rather than feel powerless as we wait for management to support agile.  In any case, often we can make great progress without their support (although maybe more faster with the support). 

Getting personal

One of the things I like most about Scrum is that it makes people, well, personal. It allows people to be themselves.

One of the best suggestions I ever heard for living was: Love your neighbor as yourself. (Might I be a touch sarcastic?) Of course, as a teenager, I chuckled about that word 'love', until I read about agape and caritas. (Techno-geeks may Google those words.) Then I realized that behaving well, on a personal basis, with other people is more serious, or at least complex, than a Hallmark card. (Notice that I moved from what some think of as emotion to action.)

So, I think Scrum, in a small way, forces us to practice this suggestion every day. This is a good thing. We don't have to be aware of it, we are not 'trying' to be good, we just learn, without being precious about it, how to act better towards other people. In my experience, there is a lot to learn.

A person recently described a teammate in this way:



Now, this may or may not be a very accurate description of this person. It does sound a bit contradictory (aren't we all!). And the person making the description may not be totally unbiased. My feeling is that some members of some teams would not be totally comfortable with some of these attributes (to the degree they recognized them). But my main point is that we have to get to know our teammates personally.

This is a wonderful thing.

In these days, it seems to be that 'things' sometimes have the upper hand. And people are no longer important. But this is not true.

People are the more important.

It is for people that we build new products. It is with our new best friends that we struggle to build something wonderful.

And Scrum does its little things, and somehow, at least within the team, we start to see again for the first time how compelling people are. Weird, and wonderful.

Business Value is a dream

There is a famous Taoist story about a person dreaming that he is a butterfly. And awakens and can't decide: Am I person who dreamt I was a butterfly, or am I a butterfly dreaming I am now a person?

This is not the kind of dream I meant, when I used that word in the title.

"We are such stuff as dreams are made on..." This is more the kind.

Business Value is based on what people want. And I think that what they want is, for good and bad, mostly a dream. That is, they imagine they have a problem, and they dream of the 'perfect' solution. Well, perfect in the sense of the best they can dream. And it is this dream that they want.

So, we, who spend our lives trying to fulfill the customers' dreams, must accept that it is all about dreams. Dreams can change. Nightmares come and go.

And in our dreams as implementors (not customers), if we are as good at dreaming as, say, Steve Jobs, we will imagine the yet-more-perfect solution to the problem. Example: The iPad.

Some of us a very practical. This leads to many good results. But in dealing with dreams, perhaps we practical ones should dream more seriously.

Some people say that Business Value is all about money. But before the money, they must want to buy. And that is dreaming. That is evanescent. And yet it becomes brutally real. (Cf Motorla Zoom just about now. I think.)

CSM Course + Workshop: Why?

My colleague Catherine Louis got me, reluctantly at the time, to do a workshop at the end of a Certified ScrumMaster course. And then a client wanted the workshop with the course (many courses with them since then). Now I am 'hooked'. As I have said before, the feedback from participants is always that the workshop portion (1 or 2 days) is essential. Fun. And it solidifies the learning.

So, now I am trying to get everyone who does not know to 'see the light'.

This is actually not great for me personally. I make less money per day with the workshop. It means more days away from my family. I am too busy already. But still it is the right thing to do.

I have described elsewhere (here) what happens in the workshop. I won't repeat that in this post.

What I am adding below is an email from a client (he is a manager) to a potential client, describing why he always pays extra for the workshop. (Well, I not sure he *wants* to pay extra for the workshop, but he does. And, as you will read, he does want the workshop.)

***

Hi Alex,

We have been going through a large scale Agile transformation for the past 18 months and have had many of our teams attend CSM and CSPO training with Joe. I highly recommend him. His courses are highly educational, interactive and fun. I always receive great feedback from people who attend his courses.

My rationale for a 4 day course over a 2 day course is as follows;
[Ed. Note: '4 day course' means 2 days of CSM/CSPO course + 2 days of workshop.]

If you read about Scrum on Wikipedia, it seems simple enough, actually pretty obvious. And it is, but there is significantly more detail when you actually start working this way. Going to Agile/Scrum is a significant change in the development cultural, it is a transformation that doesn’t happen overnight – it will take weeks, months or even years depending on the size of your organization. Most of the people in my teams have been doing software development in Waterfall for 10 to 15 years, so this is a big change for them. More training is better than less in this context.

The 4 day CSM/CSPO course is 2 days of theory followed by 2 days of ‘hands-on’ workshop for the teams. I think the workshop is the best part of the course; it brings the people together as teams and gets them going in the right direction. The bulk of the time is spent planning their first Sprint, but it happens in an environment where they are coached, can ask questions and get professional/experienced feedback and advice. Teams leave the workshop with a common vision and a shared understanding of the next set of things they will work on – really cool stuff.
....
Cheers,
Dave (at a large telecom company)
[Identifying details withheld; he has a 'day' job too, although he was kind enough to write this note. He probably would correspond with you if needed.]

***

Another note: The 2 days of course are not pure theory (as the note above might imply to some), but they include some theory and they include some experiential exercises that are not real work to the participants. Some of the exercises in the course could have been real work at another firm, but they are not 'real work' at the participants' firms.

By contrast, the workshop uses live ammo, so to speak. As much as possible, participants are doing real work at their firm. At the very minimum, the work is real work to the Product Owner for each team.

Planning Poker - 1

At Agile-Carolinas, Laurie Williams gave a great presentation last night on how she does Planning Poker. (Suggestion: Google her. She is a professor at NC State, but that is just the start. She is very good.)

Some of the discussion made me realize that there are many issues out there.

So, here is how I recommend doing it. This is overly simplified. Later I will discuss some small differences between what I recommend and what Laurie recommends.

The Basics

Assume for now we are in Release Planning (before starting Sprints).
Assume the user stories have been created. Some are epics.
Assume business value has been addressed (somehow).
Assume the stories are on cards.
Assume 50-400 cards.
Assume our domain is software development (not an essential assumption).

Gather the team of pigs, including the PO and SM. Assume the team size is 7.
Assume the PO does not know how to do 'real work' (ie, implement a story).

The team selects the smallest story from the set of user stories.
If the story is not 'silly small' (less than 4 ideal hours of work) and not 'too big' (umm, I won't define that here), then this story becomes 'the reference story'.

Give the team planning poker cards with the modified Fibonacci numbers. One set per person.

The PO explains the most important story. The whole team discusses, asks questions, etc.
The SM looks for 'enough discussion roughly equally from all'.
If the team has enough info to estimate it, then each implementor chooses the Planning Poker card (number) that represents the relative size-complexity of this story versus the reference story.

Each person is thinking of the full effort for both stories from all the skill sets, not just the effort for 'my own' skill set (eg, if he is a tester).

Each person is thinking about the 'definition of done' for the team. And the effort to complete the story in accord with that DOD.

The PP card is selected privately. Meaning people do not influence each other. We want each person's independent opinion.

The SM waits until everyone has selected a PP card/number. And then says something like "1-2-3, show" and everyone reveals his or her number at the same time.

The highest and the lowest numbers talk. Usually each person explains the assumptions they used to select that number. Typically, if they were business assumptions, they all look to the PO to 'answer'. If they were technology assumptions, they agree on which assumption is correct or they choose an assumption (perhaps a compromise of the two opinions).

Typically the team votes again with the PP cards.

If the result is that the team selects PP cards within 3 consecutive cards (eg, some 3's, some 5's, some 8's), then the team adds up all the cards, and divides by the number of voters. To arrive at an integer (no decimal places), representing the average opinion. Note that typically the final number will not be a Fibonacci number (eg, a 6, not an 8 or 5).

The studies on and methods around wide-band delphi estimation propose a fancier calculation (which I have forgotten), but averaging seems to be accurate enough and fast enough. So we do that.

The idea is that they have discussed and agreed on the story that much (feature and basic implementation). They do not have to fully agree on the relative size (effort).

So, you see that the team reaches a degree of consensus (ie, everyone in a 3 Fibonacci number range), but complete consensus is not forced. Or, we might say, differences of opinion are respected. So, we do not require that the team reach consensus down to all voting one Fibonacci number (the same PP card).

We are kind of fuzzy about whether we mean size, complexity or effort. My answer is 'yes'. (A bit over-simplified.)

In practice, it takes some time for the first few stories to be estimated. Maybe 10-20 minutes each. But as the team moves along, many of the basic assumptions have been decided, and things speed up. Some times perhaps too much. We want discussion and learning.

Now, two important feedback loops.

1. Product Owner: We do not want a stupid person (meaning: a person who has no clue about the 'real work' of implementation) anchoring the team on an estimate. So, we typically do not recommend that the PO vote. But, technology projects are all about cost-benefit trade-offs. So, what we usually recommend is that, after a story has been estimated, the PO can say 'well, I don't want to spend that much on that feature; what can we do?' And the team with the PO might modify the feature or the nature of the implementation so that the cost-benefit ratio is more reasonable.

2. At the end. After the team has completed Planning Poker (for all the cards?), the team should look back at all the numbers on all the stories. By now, the team has learned a lot. Do any of the story points on any of the cards now look 'stupid'? (That's the technical phrase.) If so, the team can refactor those story points.

***
Enough today. More later.

One thing I must emphasize. The value of Planning Poker is in the discussion-learning (80%) and only slightly in the final story points themselves (maybe 20%).

Scrum & Control

One myth about Agile is 'those agile guys are out of control!'

Of course, when one hears that, one must ask, what do you mean exactly?

For example, Scrum does reveal that the team is involved in a creative process, a process of identifying what the customer wants and how it will be implemented. And all the related trade-offs. In our usual situations, this has some elements of chaos. It is only natural and normal that creation and inventiveness and 'magic' should have some chaos. It is the nature of the beast. It is not Scrum's fault, although Scrum does reveal the chaos. Knowledge creation by definition has some element of chaos.

Now, some people think that waterfall (or their version of waterfall) gives them 'more control' than Scrum. Now, I have only 20+ years experience in waterfall, and I certainly have not seen every situation, but my opinion based on a fair amount of experience is that Scrum gives managers far more control than waterfall.

Where?

Well, first we must distinguish between real control and the illusion of control. Waterfall does provide an illusion of control. Well, I am embarrassed to say this since I did waterfall for so long, but in Texas they have this phrase: 'All hat and no cattle.' I was that kind of project manager for too long.

And we must remind managers immediately (and talk at more length than here) about the importance of the team self-managing itself. Especially in Scrum. ('Whatever self-organizing means!' you might say to yourself, but a topic for later.)

Ok, where indeed.

Let me pick on three key cycles of control.

First, adaptive planning.

Everyone should now know what the Romans knew, which is: "To predict is difficult, particularly of the future." Meaning, we know that the first estimate of 'how long will it take' is always 'terrible'. I actually think that a decent agile team with a known velocity can make a far less terrible up-front prediction of the delivery date than waterfall estimating (we call it 'release planning') ever did. But let's accept for arguments sake that agile release planning up-front is no better than waterfall.

BUT...agile re-estimates every Sprint. Based on known velocity. And based on all the learning by the team since then. (And, if it is a priority, the team focuses on learning that improves the estimate.) So, very early in the project (if we still call it that), the team always should have a far better estimate of 'what' and 'how long'. And can enter into good cost-time-benefit conversations with the key stakeholders to 'bring it in on time', as they say. (Time usually being the key variable.)

This provides much more control, with much better information. Never perfect, but much better.

Now, this assumes that people are playing Scrum professionally, with some good talent and rigor and courage. Not always the case, for a variety of reasons. To be honest, sometimes it seems they make something up and call it 'Scrum.'

Second, the working software.

The team has to deliver working software every Sprint. Any manager can walk into the Sprint Review. It does not take a rocket scientist or thousands of pages of lying reports or a highly-paid PMO to figure out that a team showing no working software (or working product, in another kind of effort) is not doing well.

There is no obfuscation. (Which is a fancy word for people trying to make things unclear. Which you may recall has actually happened at your friends shop.)

Now, managers must be reasonable in using this information. Sometimes the best teams make serious experiments. Any good scientists knows that most experiments fail. So, if they learned something useful from an experiment that failed, then let them continue. But if you are asking a great hockey team to play major league baseball, you might see a kind of failure that needs to be fixed. And you can see it and fix it.

The demo provides another kind of control. (The demo happens at the end of every Sprint, in the Sprint Review.)

Has it ever happened to you that the team did not understand perfectly what the customer wanted? OK, OK, yes, that happens universally. And lots of laws of software that explain some of the reasons why.

Now, if you believe as I do that 'the bad news does not get better wth age', then you can see that demos that enable feedback from good customers or customers representatives can provide more control. At least some of the bad news is no longer getting worse with age.

Third, the Daily Scrum.

Every day, each team member must answer the 3 questions to their other team members. This provides control in the form of motivation (positive and negative), focus (a key problem in our situations), and help with impediments.

The team is expected to make micro-adjustments to 'land the plane more successfully' by the end of the Sprint. (OK, some major adjustments too, if needed.)

The biggest impediments should not go unidentified for very long. (Again, assuming we play with talent, professionalism and courage.)

These three things -- adaptive release planning, Sprint demos of working product, and Daily Scrums -- are what give Scrum far more control than waterfall.

There are other things in Scrum that improve control, but those 3 things to me make the case.

Your thoughts?


Note: The image is borrowed from this page:
http://www.egos.esa.int/portal/egos-web/products/Simulators/Control_Center_Models/
At the European Space Agency.

Daily Scrum

What is the purpose of the Daily Scrum?

Well, first, how often do we have one?

'Obvious, toolshed, daily!!' Well, apparently not so obvious to all. Some people think we need one twice a week.

Let's go back to the purpose.

The purpose is to enable the team to make micro-adjustments in any dimension to land the plane more successfully.

What does 'land the plane' mean? Well, to deliver the team's commitment (or promise) made in Sprint Planning to deliver 8 stories that sprint. (Well, it might have been more than 8 stories, depending on their size and the team velocity.)

What does 'more successfully' mean? Well, all 8 stories first. Higher quality, less technical debt. And maybe another story, or at least another story started. And given the usual 'stuff happens' around here (as it always does).

So, who is making the micro-adjustments? Well, anyone on the team. Probably really everyone on the team, both consciously and sub-consciously.

What a Daily Scrum should not be

Another stupid wasteful meeting.
A status meeting for the ScrumMaster.
A time to brag about all the wonderful things I did yesterday.
An endless discussion of, and attempt to fix, several impediments (with all team members present).
A time to hide the truth, because God knows what those stupid people might do with it.

Why Daily?

Well, we work each day, so the situation is always changing.
And because a serious impediment could arise any day. And often we don't recognize the impediment until we get together and see the impact on the team.
There is a saying: "Take care of the small problems and the big problems will take care of themselves." Maybe not always true, but this might be one hypothesis behind the Daily Scrum. If we fix the small problems when they are small, they do not grow to become big problems.

Related to this is that the bad news does not get better with age. So, identify it quickly and hopefully fix is quickly, before the bad news becomes worse.

What do you mean 'micro-adjustments'?

Well, anything really, that can help us be more successful.
Working together more or differently.
Getting new information.
Fighting over a problem.
Asking for help.
Fixing an impediment.
Getting clarification of a mini-feature.
Different automated testing.
Etc Etc.