Category Archives: knowledge creation

We want a Stable Team

Posted on by
Reply

I think our (your) business is about knowledge creation.  (Well, knowledge creation is key for almost all the people who come to my courses and workshops.)  It is about innovation, creativity, inventiveness. About cool solutions to hard business-technology problems.  It is about some sort of intersection between people and technology. So, coming up with a great product requires something special.

And I believe the ‘special thing’ these days is far more likely to come out of a good Team.

So, from a business management viewpoint (and it is the managers we most need to convince about this) — we need a stable Team.

And it needs to include virtually all the functions (or far more so than we ever did before).  And that also means it needs to include business people and technology people.  Just for amusement, I like to call them suits and geeks. To me it suggests that it just might be ‘interesting’ to put them together.

We must mention two things.

It should be FUN to work in a real Team.  And in fact, in Scrum with all but dysfunctional teams, it is fun. (But maybe could be more fun, if you had a good ScrumMaster helping the fun along.)

It should be more satisfying working in a Team. It is my belief that the human animal has been selected to enjoy life in a small Team.  Like a family, but a bit different.  A small ‘pack’.  Maybe within a larger pack.

So, how long should a Team be stable?

To answer this question, we need to identify basically three situations.

1. Mediocre Team. This team improves 20-50% with Scrum.  Give them 6 months.  If they don’t become better by then, then try putting the individuals in different Teams.

2. Good Team.  This team improves in the 100-200% range.  Wow. Leave them alone. They are doing pretty darn well.

3. Great Team. This team improves in the 5x-10x range. Wow!  Don’t mess with them.  This is the goose that laid the golden egg.  You would be crazy to bother them unless and until they want to be bothered (want to change).  And, if you continue to give them good satisfying work to do, they may never need to change. But, of course, something will eventually happen…one of the usual human things (birth, marriage, death, move, etc, etc).

(There is also the situation of the occasional dysfunctional team. Usually that can be identified in a few Sprints. As soon as you are sure it is not just ‘storming’, then you must change the team composition or totally bust up the team.)

***

This idea of stable teams leads to a major shift in orientation. (The change can happen over time.) We no longer start with projects, and find people to do them.  We now start with a Team, and find good work for it to do.  Who knew that people were important?

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.

The PO – The Team Daily Scrum

Posted on by
Reply

I have some different views on this, and wanted to share them.

Your comments are of course welcome.

I am NOT asking what is or should be in the Scrum Guide. Or whichever ‘scrum bible’ you use.

I am just saying what my thoughts and experiences have, together, taught me.  I want to discover just what is most effective for ‘pretty good’ Scrum teams.  (Maybe not best for super teams or for beginner teams.)  So, I am trying to have a conversation — maybe about what to add to Scrum — not a religious war.

OK.  My views expressed too quickly:

  1. The PO is very important to success.
  2. Understanding business value and understanding detailed ‘requirements’ is very important to success. Both these ‘activities’ are extremely difficult.  Both for the PO and for the Team.
  3. Knowledge creation as a full team is very important. In multiple domains. All domains impinge on all other domains. (Key example: cost-benefit analysis.)
  4. The full Scrum team delivers the product. Each provides his unique skills and ideas and creativity.
  5. The PO is definitely a member of the Team.  Given real life, often 100% of his time is not enough (see also #7 below).
  6. The only team that matters is the full Scrum Team.  It is this team that self-orgs, most importantly. (Yes, every person, pair, teamlet self-orgs….not the most important aspect of self-org though.)
  7. I do not think it is useful to talk about a team within the team. (I hardly ever say ‘Dev Team’.)  Talking about a team within the team  creates an us-them attitude. And anyway is not useful. And at first at least, a bit confusing.
  8. The PO must spend a lot of time with ‘people outside the team’.  I will call them, at times, customers. managers, business stakeholders, etc etc.
  9. Still, the PO should attend the Daily Scrum as often as possible (by phone if not in person).  And should answer the 3 questions. His work affects the output of the Team.
  10. The simplest example is: On Day 1, a question is asked by the coder. On Day 2, the PO can give the answer (or at least say ‘I got the answer’) in the Daily Scrum.
  11. If the PO does not do the Daily Scrum (ever), I think most team members start to think or feel (sub-consciously): “who is that guy; he is not part of the real team”.

OK.  This is my experience.  Maybe limited experience.   Maybe just bad thinking.

Imagine that you disagree.

Where we differ, I expect my main reaction or push-back would be: “Well, I can see that happening, and it has happened to me, but I think we should coach them to be better, and often, if we coach them to be better, they actually will be.”  Meaning for example: If the PO comes to the Daily Scrum (usually), then over time it will make them at least a bit better.

Certainly some of you have done different things and been fairly successful. For example, with the PO not coming to the Daily Scrum.  But could you have been more successful by having him come?  Or might ‘my’ teams be more successful doing it your way?  This, to me, is the question.

Again, I am not sure I would coach all beginning teams to do it this way.  I am sure some super teams might be more successful another way.  My inquiry is: For most ‘good’ (but not super) teams, which is the best way to do these things? (PO, Team, Daily Scrum)

Of course, there are many other things in life and in Scrum than just the 3 things I discuss above.

BTW, while what I am saying above is not exactly how it is described in the current Scrum Guide, I do not think it is contrary to what the authors would want.  But it may be more than ‘the bare Scrum framework’.  The minimum that they want.

Agile Specification

Posted on by
Reply

This is a “just enough, just in time” concept.

Please read these blog posts:
http://scrum.jeffsutherland.com/2009/11/enabling-specifications-key-to-building.html
http://scrum.jeffsutherland.com/2008/09/agile-spefiction-is-it-hoaz-or.html

OK.  So, it is something ‘written’ that the PO gets done for the Implementers in the team. The Implementers define exactly what they need, and the agile spec is neither more nor less than what they need.  To get it done right. Quickly. High quality. Etc.

What might it contain?

Well, anything useful.

I think it is easiest to think of conceptually if you think of 1/2 page (or 1 page or maybe 2-3 pages if the drawings are big) tied to each small sprint-sized user story.

It is simplest to think of the Agile Spec being ‘written’ ‘one sprint ahead’.  And being checked for ‘ready, ready’ before the Sprint Planning Meeting.  But your real world may require some common sense adjustments to that. But be careful; common sense is remarkably uncommon.

Maybe hand-written, maybe on a wiki.  Maybe in a Word doc.

Who writes it?  Well, the best people, of course (self-organize!).

It might hold:

  • the acceptance criteria
  • a business flow
  • a list of business rules
  • a wire frame(s)
  • a mock-up of the screen (if that means something different to you)
  • a simple use case kind of flow (not all the darn UML use case stuff… just something, just enough) (to me, this is a variation on a business flow, using a few specific symbols)
  • a data flow
  • new data elements (or whatever you guys call them)
  • key data elements and key values in this context
  • a screen flow
  • a simple design picture
  • a data flow, maybe simplified
  • an example (eg, if X, Y, Z inputs, then we expect A, B, C outputs)
  • anything else they may find useful to build it quickly and for it to EXCITE the customer

Any one Agile Spec will NOT have all of these things.

It does not repeat the usual BS that we used to put in specs. That no one really read.

It does not say all the stuff they know well already.  It is not trying to be ‘comprehensive’.

We are _not_ managing through documentation. Consider this sentence repeated 15 times, 15 different ways.

We are sharing knowledge in one effective way. It is not the only way to share knowledge, and create knowledge. Two people at a white board is still going to be used. A lot.

And we definitely use the Agile Spec as a basis for conversation, to confirm that everyone is seeing the same elephant (well, in this case, the same small sprint-sized user story).

For some people, who maybe had too much fun in college, we need to write or draw more.

For some people, who maybe took their Ginkgo today, we need to write or draw less.

Any questions?

Ozymandias: Creation birth pangs

Posted on by
Reply

It is hard sometimes to create. We wonder, will our darlings ever survive.  I have spoken already of a book called The Courage to Create by Rollo May.

Now I want to show a short poem by Shelley.  Ozymandias, it is called.

I met a traveller from an antique land
Who said: Two vast and trunkless legs of stone
Stand in the desart. Near them, on the sand,
Half sunk, a shattered visage lies, whose frown,
And wrinkled lip, and sneer of cold command,
Tell that its sculptor well those passions read
Which yet survive, stamped on these lifeless things,
The hand that mocked them and the heart that fed:
And on the pedestal these words appear:
“My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!”
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away.

Ozymandias was once a famous king, of surpassing wealth and power in his time. And Shelley wrote this after seeing the ruins of his kingdom.  You will note that Shelley, the great poet, was not daunted by this vision of despair.

I note with irony and pun-ishness, that in our computer world, the lone and level sands stretch far away.  (Ok, Virginia, I am alluding to how sand becomes silicon, as in Silicon Valley. The valley of dreams.)

I hope that you do not seek that fickle goddess, Power.  Or wealth (perhaps slightly less fickle, if you know a good Swiss banker).

But if we only build castles of dreams in the breasts of our friends, even those dreams, once built, can die surprisingly quickly.  A new product will come along and charm them a different way.  I am sure any of you can think quickly of an example.

We must have the courage to create, and the laughter to let that beautiful creation come crashing down. And then to create again.

I will close with this quote from Henry Ford:

I cannot discover that anyone knows enough to say definitely what is and what is not possible.

Creativity

Posted on by

A friend was reading Daniel Pink’s book called Drive. And so I started reading it.

I had this series of thoughts.

First, I have for a long time thought that the key thing about our jobs is creativity.  Takeuchi and Nonaka call it knowledge creation, but to me it remains essentially the same thing.  And it covers many domains: business, technical, people, customer, marketing, etc, etc.  We must be, as a team at least, creative in all these different domains. Innovative, inventive, combining things in a new and interesting way, just coming up with something that seems weird at first, seeing something new that is elegant.

I find that there are, in overly simple terms, two types of people I run into.
People who are ok with creativity and chaos, and people who are not.

The people in that second group do not create much in the exercises we do in the Scrum classes.  They tend to want to ‘edit’ or restrict work too soon. They tend to both give and take restrictions on the ‘scope’ far too soon. They tend to ask me to restrict or define the exercise, as though they were afraid of chaos.

And Daniel Pink’s book makes me think that they (those in the second group) have not realized how their own internal thoughts and feelings inhibit their creativity. They want to be too orderly, too soon.  They want to edit themselves before they have gotten a useful body of ideas out on the table to play with. They fear that play is not real work.  They worry much too soon about ‘are we on target‘. They fear the subconscious, and want everything to be arrived at logically.

In other words, they have told themselves a bunch of lies about their own motivation (to focus on the subject of Daniel Pink’s book).  They are not inherently less creative, at least according to this (my) hypothesis.  They just have ‘rewarded’ themselves so wrongly that less creativity comes out.

Now, it may be that some teams are just less creative. Period.

But before deciding that, let’s give them dance lessons.  Let’s have them play.  Let’s ask them to break their own mental boundaries in some meaningful way.  And see what they can really do once the blinders come off.

If you run into a team that basically is in the second category, I would work with them to identify their ideas and concerns about creativity.  My hope is that by talking it through, they can start to allow themselves more chaos and creativity.  And also more fun!

In closing, let me repeat here what Jeff Sutherland has often said: If they are not having more fun, then they are not playing Scrum the right way.

I think he means this in two ways;
- only by having fun will their best come out
- fun, serious fun, is a value for human beings in and of itself.  It does not need to be justified in any other way.

Note: I do not think Jeff would condone ‘trivial fun’.  My example of that might be: eating a whole bowl of candy on Halloween.  Fun in a certain use of the word, but not good for you.  I mean, and I think he means, fun that gives deeper satisfactions than that.

Note: The picture or mindmap above comes from this page:
http://www.sorrythatusernameistaken.com/2010/03/04/creativity/

 Subscribe in a reader

Creation myth

Posted on by

It is Sunday morning as I write.

I like to read different bibles, from different cultures. It is my intuition that while they are all different, they are also all trying to give us pointers towards the truth. Sometimes the pointers are a bit rusty and bent, but if we use a bit of imagination (thank you Mr. Blake), then we can find our way a bit better. Even with the bent and rusty ones.

In the Hebrew bible, there are several creation myths. How the world was created, and maybe why, and maybe a hint or two about ‘what is it all about, anyway?’

And the Christian bible has a creation myth too. “In the beginning was the Word.” And a few lines later: “In him was life, and the life was the Light of men”. And then a few lines later: “And the light shineth in darkness, and the darkness comprehended it not.” An interesting progression. All Agile advocates can understand that last phrase, at least in the mundane way, that we try to shine what we think is a light, and often it is not comprehended.

Now, for those to whom the past is not prologue…

In the New Yorker, Malcolm Gladwell has another creation myth he wishes to describe. (I think he means it in not as profound a way as the Bible. Certainly I am not suggesting that it is as profound.) It has to do with Xerox PARC, Steve Jobs, and the creation of the Personal Computer. And of modern warfare. He is really talking about creation, invention, innovation, creativity. Which is what our Agile teams do. So, I think, a very important topic.

Read it here: http://www.newyorker.com/reporting/2011/05/16/110516fa_fact_gladwell
Or at least an abstract. And decide whether to read more.

Here’s what I think he says or implies, over-simplified into 2 points. (Which is usually one more point than I can remember for more than a day.)

1. We can win more and faster as a team. Meaning: If we pick the right diverse mind-sets (individual people), and put them in a team and let them fight about the product in multiple dimensions, we can get better innovation faster.

2. We win by being like the tree in my front yard. Meaning: We throw out many many seeds, most of which will die. Most will be “failures”. But those failures are good because they mean more possibilities will be considered, and we will discover those few possibilities where the new tree can truly flourish.

It feels risky, it feels wasteful. Yet, it is the way to win. And to have fun. But it does make me sneeze. (Literally: I have allergies now, as I am older. Symbolically: Probably still true.)

No, no: It is the way to make people’s lives better. Maybe even yours.

Malcolm Gladwell is, I think, a wonderful writer, and you may take different conclusions from his story. Please do.

 Subscribe in a reader

Innovation: The most important question

Posted on by
Steve Denning (a very interesting guy) tweeted about this article:
http://www.openforum.com/idea-hub/topics/the-world/article/innovations-most-important-question-matthew-e-may

The question (in the article) is: Is there a better way?

Read it. Nice story behind it. (Steve is a big proponent of stories. Google his books.)

Actually useful if you want your team to be innovative. (You do want your team to be innovative, right? It isn’t just hard work, right?)

My only comment: It isn’t a question (a thought), so much as a feeling: Goddammit, there’s gotta be a better way!!!

The way we envision people is grossly over-simplified. But one way is the well-known dichotomy: thinking vs feeling. And my hypothesis (cf. Freud) is that more action (results) derive from feeling than thinking.

 Subscribe in a reader

Complex Adaptive Systems

Posted on by

Self-organization, which we just wrote about, is only one of the ideas that we know contribute to the success of complex adaptive systems.

While we are not convinced that CAS (complex adaptive systems) have been fully figured out, we think it has a lot to add. (In fact, our hypothesis is that that E=MC(2) is only a working hypothesis (as are all the so-called scientific laws) soon to be revised…and soon might be 1,000 years). But we think anyone working with creative teams must be studying CAS. Well, and thus, self-organization.

Another key related idea is Knowledge Creation. We cannot talk about this too much.

In our businesses of new product development, the key thing is the amount of good new knowledge created and per unit of time. And good, in overly simple terms, means high business value (along with lots of other constraints).

We think self-organization is key to high levels of knowledge creation. As anyone who has done brainstorming knows, you cannot command-and-control creativity. Or, if you do, you should expect very low creativity, creativity smothered in a prison jump suit.

We think CAS and knowledge creation are key to better Scrum teams.

This leads me to this thought, said earlier a different way: Our biggest impediment is refactoring our wetware.

Now, one of my missions in life is to reduce and reverse de-humanization. (Sounds quite high-minded and daunting, but it is not; it is just a daily struggle, like brushing one’s teeth. Or mostly it is.) De-humanization is where people are not treated as being fully human, with all the good and bad and other stuff that implies. Where, for example, they are treated as a thing, maybe a computer. So, I am not in love, as a lover of words, with words like ‘wetware’ that take a computer model to explain the human CNS or mind. But, if it makes you happy…(as the song says).

PS. Takeuchi and Nonaka, the godfathers of Scrum, have spent much of their later careers studying knowledge creation. Seek and ye shall find.

 Subscribe in a reader