Category Archives: learning

Leading Fearless Change

Posted on by
Reply

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

Posted on by
Reply

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 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 mistakes 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 admit.)

Read, enjoy, learn.  My and our gift to you.

The list is here.

Is release planning worth it?

Posted on by
Reply

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 a reasonable 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.

Choosing a Scrum course/trainer

Posted on by
Reply

This is a question I get from time to time: How should I choose between one course/trainer and another?

This is an important question and deserves some thought.  It does not deserve, in my opinion, a simple answer, as one might get from Zagat’s about a restaurant. The choice is very much different than choosing yet another restaurant.  For most, this is a once-in-a-lifetime choice.

The good news: Most people (I’ll say 95%ish) are happy with their choice. Or so I hear. But did they make the best choice for them?  Very very hard to know.

Here are some criteria for you to consider. I believe you can think for yourself once you have some context (a key Scrum theme).

1. Date, location, price. Yes, of course. You may think I am biased, but of those, by far the least important should be price.  Because in relation to the benefit, it is trivial.  OK, these three were obvious.

2. Course/workshop goal.  Yes!  What is the real goal of the course and the goal or goals of the instructor.  Even though they all say “CSM course”, they do not have the same goal(s).

My goal is this: I want results for the attendee, for the team, for the customers.  To me, those results are the only things that count.  But I am sure many other CSTs (trainers) would say something different. Or would not agree.  Or would at least word that challenge differently.

3. Instructor personality: Yes.  Trainers have different personalities. And this affects how you learn.  How would you learn about this?  Well, one way is to read the trainer’s blog. You might want someone who is the opposite personality to you.  Interesting ideas.

4. Instructor background: Not simple.  But if you are in finance in NYC, you might want a trainer who knows finance in NYC.  And a zillion other examples.  It can also be argued that, other things equal, the buyer should get it from someone who is from a different background. Maybe.

5. Instructor teaching approach: Each trainer has a somewhat different teaching style. To give an overly simple example: some use mainly a slide deck, some have no slide deck at all.  One related idea (theory): the training style should match your learning style.

6. Experience with Scrum. Some instructors have more experience with Scrum than others.  Jeff Sutherland and Mike Cohn would be good examples of that.  They have been doing Scrum for many many years.  (Oh, you thought I would only recommend myself?  Wrong.)

7. Accuracy of describing Scrum.  Umm. Some trainers understand Scrum better.  I do not know how wide the divergence is amongst the Scrum trainers.  I do know you will not hear the same thing from each one. Even about what I call ‘the bare bones of Scrum’.  And certainly not about what things to add to ‘the bare bones’ to make it work better, but maybe that is different than ‘accuracy of describing Scrum’.

8. Ability to explain the ‘abstraction’ of Scrum in a way that seems (is) do-able and practical in your specific situation.  Umm. Seems pretty important, right?  And yes, it is related to some of the other things already said.  But it is different.  One suggestion: read the trainer’s blog.

9. Workshop or not. My colleague Catherine Louis got me, against my better judgment to try doing a third day Workshop. So, now I do that all the time. Most Scrum trainers do not. Or they do a different kind of thing.  In any case, that is an important part of the choice, in my opinion. Suffice to say that I think the Workshop is very valuable, based on feedback from the attendees.

I am sure there are more criteria. But that is a good start.

One thing I suggest you not pay attention to….

First, there is a thing called NPS (Net Promoter Score).  It is used a lot on normal products, and many smart people (not all), think it is very good. I usually mention it when talking about the Business Value of products.

First, I think the course/experience/situation in a CSM course is very different from a normal product.

OK. Some trainers gather an NPS score. From attendees who have just completed the course.  I do this also. (For me, I find the information somewhat useful.)  Each trainer attracts, for many reasons, different kinds of attendees.

If you get a chance to compare NPS scores across trainers, don’t.  You do not yet have enough information to compare those numbers.  After you have taken the course from both trainers (of course, the first trainer will bias your observation of the second), you will almost have enough information to compare the NPS scores between both those classes.  If you could see only the NPS for each course (and both trainers would likely show those numbers to you, if you asked).  But NPS numbers averaged over a year’s worth of courses will not be meaningful.  To you (although perhaps a trend line might be meaningful to each trainer).

In general, for all the trainers I know, the NPS will be high, and the differences between the NPS scores will not be meaningful. Certainly compared to other factors.  IMO.

Hope that helps. Interested in your comments.

***

Kaikaku or kaizen? (2)

Posted on by
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.

 Subscribe in a reader

The primacy of learning

Posted on by
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?

 Subscribe in a reader

The Nokia Test (3): Agile Specifications

Posted on by
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.}

 Subscribe in a reader

How to learn more about Lean-Agile

Posted on by
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.

 Subscribe in a reader

Google, Agile and Business Value

Posted on by

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.

 Subscribe in a reader