CSP… in demand…

We have a problem in Scrum.

First, we do well to call it more an opportunity than a problem.  We have a lot more opportunity sitting on the table that we have not grabbed yet.  Scrum, in general, can help us get a LOT more improvement than we have gotten. Yet

There are many root causes behind this problem (opportunity).

And many possible solutions also.

But I think the biggest solution is more education (more coaching is maybe next).

By more education, I mean of the whole man, or the whole team.  Not just explicit knowledge, but tacit knowledge.  Not just of rational things but also of more squishy things (that’s the technical terms for them – smile).

Which leads me to discussing the new SEU path to the CSP.  SEU means Scrum Educational Units. CSP means Certified Scrum Professional.

So, I am a big advocate of a well-rounded education.  Scrum education is what we are talking right now.

The SEU path to the CSP allows you to choose the ‘education’ that fits your specific needs. And it requires that you show significant related experience that at least indicates you have attained, both via education and action, a ‘professional’ level in Scrum.

Our specific contribution (more to come) is a Scrum 201 course.  This 2-day course plus the 1 day workshop gives you 22 SEUs towards the CSP certification.  But, more importantly, I think the Scrum 201 gives you essential information that will take your Scrum to the next level.

Next: I just received today a request from a headhunter for a CSP person in Charlotte.  A scrum-agile coach, and they want the person to be ‘good’, so they are asking for that person to gave a CSP.  Umm.  Start of a trend, I think.

What is really important?  Well, results.  Real results for real people.  What is next most important?  The ability to regularly achieve results.  (And, down the list, …does the person have a meaningful certification — and in the process of getting it, might have improved his abilities.)

Leading Fearless Change

What is the hardest thing about Scrum?  (Maybe in life.)
Probably, it is that we must lead change.
Getting people to change is difficult. And in Scrum, for example, we are always trying to change people. Always continuous change. Always removing impediments.
But first, we have to change them to agree to a fully dedicated real Team. Then to fewer disruptions and only one product (product release). Then to doing all of Scrum. Then to really understanding self-organization.  And on and on.
And then we start with the real hard impediments. Technical impediments. People issues. Managerial issues. Organizational issues.
Here are some resources to start with:
Leading Fearless Change by Mary Lynn Manns and Linda Rising. A good article by them. 3 pages.
This leading change course. With Mary Lynn Manns. In Charlotte in April.
By the way, this course will be about change. Any change. Not just change using Scrum or Agile. Any change.

Our Favorite Scrum Mistakes

Ah, Valentine's Day!
A day for a simpler love than "love your enemies". But even this simpler love is quite complex.  Well, as long as one is not besotted like Romeo on below the balcony. Or Juliet above. When one is besotted (well, as I still am), then love is simple. But on other days, it is not. Or so I am told.
So, as a Valentine's Day gift, we offer "Our Favorite Scrum Mistakes".
This list was put together by a bunch of great Scrum trainers.
Some you will readily recognize.  Some you might say "Oh, really? We might be doing that." You will find some of them to be similar to each other. You may be surprised with how many there are.  And I disagree with a few of them. (One suggests it is bad to estimate...well, it has problems, I think we must.)
Read, enjoy, learn.  My and our gift to you.
The list is here.

Is release planning worth it?

In a word: Yes, if done professionally.

How is release planning, and release plan refactoring…how are they useful?

A few ideas:

• It enables the Team to share ideas
• It allows the Team to see the same elephant
• It enables knowledge creation
• It enables cost, benefit, time trade-offs to become apparent
• It enables everyone to start to distinguish minor decisions from major decisions

Any professional also knows that planning is not and never will be perfect. So, we must put areasonable time box on doing the planning.

It is also useful to plan with good ‘agile’ people. Meaning people who will use the information developed from planning in a useful way (eg, will not do the ‘stupid waterfall manager trick’ of expecting the Team to always hit the date they planned on Day Zero).

Let’s talk about this last one (minor versus major)…

To put things simplistically, there are two types of decisions, which I will call minor and major.  Minor decisions has a minor cost if we make them incorrectly.  If we are clever, we soon learn that we are wrong, and we correct the decision.

But some decisions are major. To change the decision later, it can be very costly in terms of money or time or reputation or some other factor.  Once we identify a major decision, we want to do our best to decide it correctly.  This means first being sure we have framed the decision question correctly.  Then, assuming this is a difficult decision, we want to make the decision at the ‘last responsible moment’.

***

Can planning be useless or worse?

Well, of course.  If you have people who will not learn.  If you have people who will take longer than the current knowledge can justify.  If you too many people who want to use the information for ‘stupid waterfall tricks’.

But if done with good people, using useful concepts, the Scrum Team (and others) can learn a lot doing Release Planning, followed by Release Plan Refactoring every sprint.

It is also true that we can learn by doing ‘real work’.  This is not to say ‘do only real work’…but one balances and shortens release planning (release plan refactoring) in the knowledge that we can and will learn some things faster by doing real work.

Learning more

If you are looking for more to learn from...
May I suggest, Alice, this rabbit-hole here:
http://leanagiletraining.com/AgileInfo/Agile%20Info.htm

Many rooms to visit. With people of many persuasions. All of them with one voice saying:
"Go, and do. Better than we have done yet, can you.
Some pain, yes, but with a far greater joy."

Suggestion: It is best to keep the cycle of thinking and acting tight.

Kaikaku or kaizen? (2)

I recently did a mail/internet survey, asking people what kinds of training they might be interested in. (If you would like to respond to this, please tell me.)

Someone responded, "how about adopting a continuous improvement approach?" Now, we don't know what the writer had exactly in mind (although maybe I will learn more). One assumes the writer meant something like: "continuous improvement is at least as valuable as more training." So let's play this out some.

In my view, training should be part of Kaikaku...which is a rapid, large, revolutionary change. In my view, there are times to make large changes. For example, when starting Agile. Or perhaps a new project. And there are also times to make small incremental improvements (kaizen or continuous improvement).

The preferred pattern is to have occasional large Kaikaku and many, frequent small Kaizen.

Now in general I am in favor with learning that is closely tied to, and proved by action. Which is to say. "The learner has not learned unless the actions become more effective."

So, training should be used to prepare for action right away.

But let's also talk about what action is. Not as simple as it might appear.

The hardest action is to change one's own mind. The next hardest is to change someone else's mind. (Proper action in the realm of the mind can lead to tangible improvements in satisfaction for real customers.)

Let's look at one example. One can imagine sending someone who is "resisting" agile to an agile course. The resulting action might be no more than a willing suspension of disbelief, so that the team can move forward without active resistance. So, while from a certain viewpoint nothing is accomplished, yet because the team can now be more functional, much has actually changed.

The primacy of learning

I am taking the view more and more that learning is the central thing about business.

What does this mean?

First, learning by itself is not that meaningful. It is learning combined with action. And then that simple seeming dichotomy (between thinking and action) is really not so simple; for example, one of the best ways to learn is to take action and inspect the results.

But is we stick with the simple dichotomy, we want more and faster cycles of thinking and action. Learn, act. Learn, act. (A slightly modified version of the Deming cycle.)

So, in business, my bias is that the key action is providing the best solution you can to the customer's (customers') problem. And learning, in various ways, makes those actions better.

And since the customers are always changing and their problems are changing every minute, there is much to learn. So, what do we need to learn?

• what the customer's problem really is (now) (which means walking in their moccasins)
• what they want as a solution
• who we (the solution providers) are, and what we are capable of (now)
• how are proposed solution fits into the context of the firm and of society (eg, can we pay our shareholders a good return)
• what technology we should use and how to get the most out of it
• how all the changes in people, business, technology and society are affecting this situation (both at micro and macro levels)
• how to prioritize the things we need to learn now

My premise is that if we consider learning primary, how we organize people and how we do work changes. But I find, even though I have had this thought before (that learning is primary), it has not yet affected my work and my thinking nearly as much as it should.

The team that learns the fastest wins.

To me, this connects to ideas about the Knowledge-Creating Company and to the concept of Ba.

What do you think about all this? Is learning a key principle as you use Agile to produce customer solutions?

The Nokia Test (3): Agile Specifications

The third line in the Nokia Test is: "The Iteration must start before the specification is complete."

What does this mean?

The first practical goal was to eliminate the analysis paralysis and delay associated with waiting until the specification was "complete". I don't know all the details at Nokia, but I have lived them at many other firms.

What is wrong with this old waterfall process? (at least in my opinion):

• too much delay
• a pretense that further change (or learning) won't happen
• a magical belief that the customer can really fully understand a spec (I have seen it happen maybe once)
• a magical belief that "all the questions are answered by the spec", when we know that people learn much better in a face-to-face Q&A format

As an aside, anyone who has made Waterfall succeed of course does not rely on the spec alone; we use agile-like conversations and other agile-like tricks to make the meaning clearer.

So, what are we advocating in Aglie (Scrum) to replace this broken process?

Well, it turns out to be a Goldilocks idea. We have some wish to make the team efficient and at the same time we know we are learning all the time. So, we advocate an Agile Spec. Not too much, not too little; just right.

What does this mean?

Well, at a minimum it means that the business person involved (in simple terms, the Product Owner) at least thinks he understands the story (let me assume the team is using User Stories). And at least thinks he can answer all the questions. It is also a good practice for the Business Analyst (or someone) to write down a page or two or more of notes. In the course of doing that, she (the Business Analyst in this example) will ask the PO several questions, and find out that he doesn't have the answers yet, and so new learning will happen.

But the Agile spec is very short. Maybe a bunch of diagrams. The good stuff is not buried in wads of paper.

Who decides what the Agile spec looks like for a given team? The consumers. Primarily the coders, the testers and other team members who must use it. Different projects and different teams (and even different situations) may require somewhat different Agile specs.

Let me be clear. The Nokia Test does not say "use an Agile Spec". I (and others) are recommending an Agile Spec as a best practice.

And Scrum does not say "use an Agile Spec". Scrum does say "improve your engineering practices" and I (and many others) would suggest that one improvement area would be around "requirements", and more specifically, one would be using Agile Specs.

Be aware that some in Agile would advocate no written spec at the beginning of the Sprint. Nothing written; just have conversation in the Sprint. This has worked, although I think it typically is not optimal (ie, the team usually could have done more if they had used an Agile Spec). While I agree with the importance of the conversation, face-to-face with Q&A, I also think the 1-5+ page Agile Spec per Story is also helpful. As long as there is discussion between the writer and the readers about what in it was useful or in the way, or just missing (and needed to be written down). (Answer to a question: Yes, all the Agile Specs developed so far could be in one document, if the team found that useful.)

I would suggest that about 5% of the team's total time in this iteration should be used to prepare for the next Sprint. This includes building and discussing (at a high level) the Agile specs for the next Sprint.

Remember that we are always learning. Just because something got put in an Agile spec does not mean it can't change (if we now know better). At the same time, an unprofessional attitude about learning ("oh, I'll just let myself learn about that later") is not allowed either. We are trying to learn as fast as we can. By putting all our minds together.

{Note: To find our previous posts on The Nokia Test, you might search on that term in the Blogger search box at the top of this page. We have 3 earlier posts.}

How to learn more about Lean-Agile

Several people who have taken recent courses have asked "where do we find a discussion group where we can learn more about agile?"

Here are some answers.

First, find local people.

Agile Alliance has a list of agile groups. And the Scrum community has identified some local groups (often the same ones) here. In fact, the Scrum community has identified its community more broadly and specifically, here.

What are other ways to learn? Certainly there are many books. Here is a list, although not complete.

There are discussion groups, especially on Yahoo. Here are my top four:

scrumdevelopment
extremeprogramming
agileprojectmanagement
leandevelopment

There are other very good ones.

And there are some good blogs as well. Carnival of the Agilists highlights better blog posts. And the Scrum community has listed a lot of great blogs. And don't forget the blogs in the Blog Roll to the right (some repetition in these lists).

That should get you more than started.

Google, Agile and Business Value

Google announced on 4/20 that it earned $1.002 billion in the first quarter. The Net was up 69% from 2006. See WSJ.com - Google Displays Core Strength*. The sales increase was not too shabby either.

Maybe it's a company we can learn from. (Or maybe they are just lucky.)

Google uses Agile. As I hear, Agile isn't forced on anyone, and many different types of Agile are used. Which, in a way, is agile itself. My hypothesis is that the relationship between Agile and the increased profits is not coincidental.

But that is not my topic for today.

As I hear it, Google takes a very different view of how to use Business Value in its projects. It allows project teams to work on lots of things, as long as someone thinks there is potential of value. The value is not clearly defined upfront. Google gets a beta product in front of the customer world quickly, and gets feedback. After feedback and improvements, if the product has traction (internally and externally) then they release. Only then do they start to worry about monetizing the product (say, Google maps).

Again, they build, and give it away and build market share. And once they have a product that people want, then they figure out how to monetize it.

What's the idea here?

I am guessing the idea goes like this....
1. The first thing is serving the customers.
2. Some products (for Google at least) don't need to bring in money by themselves. They are looked at as filling out a whole customer relationship. It is those customer relationships that become profitable (in multiple ways, if you know how Google makes its money).
3. The first decisions are made by the bright employees deciding how much they want to invest (their own time) in creating or improving the product. My understanding is that each employee is almost an entrepreneur in the way he decides to invest his own time in projects. (I will guess this is something of an exaggeration, but you get the drift.)
4. Then each product team "sells" the product internally and externally, building users and buzz. And perhaps gathering input and more people (workers) for the project (product). So, the key tollgate is "does this product add value for the customer?" Early on, and to some degree later, internal people act as proxies for external customers. But the product is also out quickly to get external customer feedback as well.
5. Then, once they have a released "successful" product (ie, successful to the customers), then they worry about monetizing it (how Google will make money off it). Sometimes those earning are indirect (eg, via ads rather than via license fees to users).

To me, the main lesson here is that Google folks expects to learn along the way what the customers really want. And what business value really is. So they start getting feedback as soon as possible. It's a question of who can learn more useful stuff faster.

Do we have to use the F-word?

OK. It's a provocative title. I like to talk about two F-words: Feelings and Failure. This post is about failure, and how to use it.

I was working in a firm recently and someone said: "We can't talk about failure around here. That would hurt our careers." Ummm.

First, let me (apparently) change subjects completely. As I mentioned earlier, Mary & Tom Poppendieck are coming to Charlotte May 9-10 to lead their Lean Software Development - Practitioners course. So I want to talk about some of the things they will talk about.

They posit 7 principles of lean software development:

• Eliminate waste
• Build quality in
• Create knowledge
• Use the scientific method
• Standards exist to be challenged and improved
• Predictable performance is driven by feedback
  
• Defer commitment
• Deliver fast
• Respect people
• Optimize the whole

As with all good ideas, most of these are obviously good at first glance. What is apparently (from what I see in real life) not so obvious is the full meaning and application of these principles. Which the Poppendiecks explain.

You will notice that I gave detail for only one: Create knowledge. (The others have more detail, not shown; perhaps subjects for another day.)

So, let's talk about the scientific method. "But wait, weren't you going to talk about failure?" Ah, I am talking about failure. Imagine the many failures of the Wright Brothers (two of my favorites) or Alexander Graham Bell. Only after a couple of years of failure did we hear: "Mr Watson—Come here—I want to see you". And the telephone was born.

The Poppendiecks explain the scientific method this way: "Teach teams to establish hypotheses, conduct many rapid experiments, create concise documentation, and implement the best alternative."

When we are creating something new (with software we always are), we need to fail, fail, fail, succeed. This is embedded in the Red, Green, Refactor of test driven development. This is what all inventors do. (Now you can call yourself an inventor. Really.)

Now, using failure to learn and make progress and discover is not an excuse to use failure to hide shoddy work or laziness. (Very few workers really want to do shoddy work or be lazy, but a few of us have that kind of motivation from time to time. Examining why is perhaps a subject for another post.)

So, if your firm or the people around you don't want to hear the F-word, tell them your team is using the scientific method. You are testing hypotheses to identify the best one. Only by failing can we succeed. (Another paradox resolved.)

Good luck with your project.

What is Business Value? Part 1

I have noticed a bunch of projects lately (mine and those of other people) where the business value is not so clear.

As Yogi Berra said, "If you don't know where you're going, you might not get there."

But what is Business Value? I mean, what is it really?

First, I like the definition of Lean. Value is defined by the end customer. Value becomes meaningful when talking about a specific product that meets a customer’s needs at a specific price at a specific time. (See here: http://www.lean.org/WhatsLean/Principles.cfm#specify)

End customer. So, all the rest of us are just making guesses at what the customer wants. Remarkably, sometimes we are right. And the next sentence is also important. There has to be a context. In fact, I believe the context is much larger and harder to define than this. We buy things based on a conscious or unconscious comparison to all the other things we might buy or do or not do.

For example, when I go to Starbucks for a decaf coffee (don't ask; no, I hardly ever buy a latte), I am implicitly comparing to all the other cool things I could do, places with social scenes, drinks I might have, other bars or coffee houses I have gone to lately.

My main point is business value is complex. And it changes. The customers are changing and my understanding of the customers is hopefully improving along the way. Indeed, I should organize things so that I can experiment with new products, to find out if my hypotheses about the customers were correct. (Yes, Virginia, even end customers can't always explain to you what they really want. Accurately.)

So, with agile project management, we are learning about what the project is and how to do the project and who the team really is. At that same time, the business lead is learning "what really is the business value here".

"As you from crimes would pardon’d be,
Let your indulgence set me free"
- Shakespeare, The Tempest
The business lead must accept the Team is learning, and they must accept that the business lead is learning.

Now, the fact that we are learning does not mean we start with totally sloppy thinking or no thinking. We need to make a relatively quick first estimate (hey, it might even be accurate enough). And then test that. I would not suggest starting a project just on the hunch of a "business lead" who has no track record of successful hunches.

A couple of suggestions:

• Demand to understand the business value of your project (be reasonable in how you put this)
• Talk about it (anyone might have a contribution)
• Talk about it some more; see if everyone is motivated by the business value as articulated so far
• Develop an approach together to getting more confirmation that the business value of your project is really there (Hint: incremental releases might be part of that approach.)

We have some more things to say about business value, and then we will talk about the relationship between a SW project and a process.

+ Joe Little