HBR on Agile! May Issue.

The Harvard Business Review has 3 new resources on Agile now.

The original classic article is: The New New Product Development Game by Takeuchi and Nonaka.

https://hbr.org/1986/01/the-new-new-product-development-game

The first of three new resources is this article: https://hbr.org/2016/05/embracing-agile

 This is by Darrell K. Rigby, Jeff Sutherland, and Hirotaka Takeuchi.  Rigby is with Bain. Sutherland is the co-creator of Scrum. Takeuchi is a business school leader (now at Harvard), who also co-wrote "The New New Product Development Game."

 Key Topics:
1. Learn How Agile Really Works
2. Understand Where Agile Does or Does Not Work  
3. Start Small and Let the Word Spread  
4. Allow “Master” Teams to Customize Their Practices  
5. Practice Agile at the Top  
 6. Destroy the Barriers to Agile Behaviors

This article is in the print magazine.

In addition, there is a digital article.


Also a video.

Enjoy!

Scrum 101

Here is the slide deck I used in the talk with the Agile Halifax group. Scrum101.key You can see slides from other talks I have had here. Enjoy!    

Scrum 201 Course - Why?

Why the 'Scrum 201' course?

Problem:

This course addresses two problems. (A) how to get more success from Scrum. (B) how to advance your career. We are finding far too many teams are only getting 20% or so improvement with Scrum.  This is by far too low.  One way to address this problem is more education on the simple but complex thing called Scrum.  And education on the things around scrum that are necessary or typically helpful in bringing success.

Background:

The course is an intermediate course, somewhat more advanced than our intermediate CSPO course.  Participants must have a CSM or CSPO certification (or the equivalent).  The course lasts 2 days, and we strongly recommend the third day, which addresses mainly agile release planning with a real project per table. (For those who have already done this workshop with a CSM or CSPO course, we are expecting you to take it to the next level with the Team.) The course leads to a Scrum 201 certification from LeanAgileTraining. And leads to an additional 22 SEUs toward the Certified Scrum Professional certification from Scrum Alliance. And it provides 22 PDUs for the PMI.

How:

The idea is that interactive education can teach people to become more effective.  There are other methods (eg, coaching).  But we think this is a key element. Methods include lecture and discussion and exercises.  Just as we do in CSM courses, for example.  In addition, we expect attendees to engage more actively.  So, we expect everyone to propose a 10 minute segment on one topic, and to make that proposal before the course starts.  We will review the proposals, and select a few to use in the course. We also expect people to learn more in the small groups (tables) and then report back to the whole group. And do this more than in a CSM course. We also will allow participants significant leeway in deciding which topics we will address. And of course a lot of the work will include questions and answers. We will cover many topics, and many types of topics. We will generally address things in enough depth that you feel you have what you need to be effective. We will not spread peanut butter across too many topics. We will definitely review the basics, and discuss what we call Scrum-Butt.  We will discuss Jeff Sutherland's ideas on the 9 key patterns necessary for success. For more on the long list of topics we will pick from, see here. All subjects necessary to success are open for discussion.  This gives us a huge range of different types of subjects.  A few key words round areas we will address: technical issues, people issues, management, leadership, self-organization, decision-making, the flow of requirements, testing, disruptions, culture, metrics, business value, addressing the old culture or structure, managing change and getting change to happen, where does the X role fit in?, etc.

Who should attend:

Anyone interested in lean-agile-scrum.

• Managers
• Business people
• Implementers (eg, coders and testers)
• SMs
• POs
• People who want to Agile Coaches
• Others (ask)

Of course all the people in the team (this will be useful for every team member).  Whomever in your firm (or outside your firm) you need at the next level, to help everyone get to the next level. Together.

Advancing your career:

Our first goal is to improve your life, improve the life of your team, and to help you make the lives of your customers better. And, more specifically, advance your career. How? First, by giving you the knowledge to be more successful. Second, we provide SEUs toward the CSP.  We believe that for many of you, you will be given access to more opportunities to be effective with lean-agile-scrum if you have the CSP.  Or at least the knowledge that comes with it. Third, we think that many of the skills and much of the knowledge will help you in whatever direction your career takes.  Perhaps more if you stay in a lean-agile environment, but much no matter where you go.  For example, if you really learn servant leadership well, some of you will easily win many promotions as a manager.

The future:

We understand that the Scrum Alliance is thinking about defining a course that will be very close to this course.  We will keep you posted as we learn more. We hope you and your colleagues will join us for a Scrum 201 course soon. See here for a list of courses. Your comments on the Scrum 201 course and ARP workshop are welcome.    

Jeff Sutherland Google Talk (2014) on "Scrum" (book)

Here is a fairly recent Google Talk by Jeff Sutherland. (Late 2014.)  The talk gives some key ideas from his recent book, Scrum. The talk is long, about an hour. But you can stop it any time.

Q: Becoming a good ScrumMaster

Q: "What is your advice on becoming a good ScrumMaster?"

A: This is a good and difficult question.  The main difficulty is where to start and how best to express it.

First, what is a good ScrumMaster?  What makes one better than usual?

You may think it odd, but the first thing I want to say is: the team is having more fun.  Why do I say that?  Mainly because more fun will lead to higher business value.  And it leads to a virtuous cycle or circle of cause and effect.

We do not mean silly fun.  Well, it could be silly a bit (as in a quick joke and some stress relief).  But we mean more the 'serious fun.'  People are enjoying their work. They think of work almost as play or fun.  They would almost pay the company to be allowed to do their job.  That kind of fun.

For example, they enjoy working in the Team.  And while they are serious, they often smile and laugh as they work with each other and talk to each other.

Second, more self-organization.

This is hard to explain, I think.  "You make people self-organize" is my joking way of saying it.  It is a joke, because you cannot really make the team self-organize.  But you can, as a SM, coach and advise and set up the right conditions for self-organization.  And then address any people (or other issues) that inhibit it.

You let people be free. Well, yes and no.  You help people to become the best each person and the Team has ever been before.

And you do not inhibit self-organization yourself. (Actually, we all want to control things, and while some control is good, most of us want to control too much.  At least, that is a common problem, even among the well-intentioned.)  You do not 'tell' people to do things, although you might ask 'could you help with X?'  But, gosh darn it, do not act like a 'command-and-control' style project manager. "I have a list of things for all of you to do, and I will be checking the list daily to see what you got done."  Not that. Not even anything close to that.

Still, you might need to explain why they need to have detailed tasks and answer the questions in the Daily Scrum.  And why that is useful for them.  Paradoxically to some, they do need to self-manage themselves rather closely.

Third, more impediments are removed, and the Team is gaining velocity.

You have to aggressively attack the most important impediment. And when that one is 'fixed,' attack the new most important impediment aggressively. So that the velocity of the team easily doubles in no more than 6 months. (OK, some of you are in organizations that really are hard to change, so you will work hard to double in 1 year.)

And then keep on improving!

Fourth, more business value.

What?  That is the SM's responsibility?  Yes, as we have already hinted.  But let us say more.

The SM should be helping the Team get better in every way. The Team of course includes the Product Owner, so the SM is helping the PO get better.

And the goal of the Team, of course, is to maximize the Business Value (in whatever way they define that) from the Team to the Customers. (There is no maximum.)  And release more quickly and frequently.

Obviously, if the velocity increases the BV will increase.  But we really mean more than that.  The SM should be helping the PO learn to do all those things a PO should do to help the Team maximize the BV.  Examples include: clearer requirements, focus on one release at a time, a clear Minimum (minimum!) Market Feature Set (aka Minimum Viable Product), slicing the stories smaller and re-Pareto-izing them, maximizing the feedback to try to improve the odds the customer will really be excited when they get it, maximizing the feedback (see Lean Start-Up) after the release and then 'adjusting' (pivoting, as appropriate), etc, etc.

I do not mean to suggest that the SM does the PO's job. I mean 'only' that the SM helps the PO become a better PO.  And not only the PO.  The ScrumMaster helps all the people (on what we often call 'the business side') to work better with each other so that the BV is maximized more.  And delivered more frequently (which also helps maximize it).

So, at least as general goals, the SM wants to make the Team the best possible team ever.

More specifically, that means:
<ul>
    <li>More fun</li>
    <li>More self-organization</li>
    <li>More velocity</li>
    <li>More business value</li>
</ul>
It is, of course, more blessed to give than to receive, so actually they will start to feel that delivering more business value faster is more fun.

It can be said that 'removing impediments' is the way to make those 4 things happen. Put another way, anything that is holding those things back is an impediment for the Team.  Fix it!

Have we fully answered the question?  No.

&nbsp;

What is Scrum?

I am starting a series of posts to explain quickly what Scrum is.

It turns out that Scrum is very simple, and yet also very hard to explain concisely.

The main purpose of this series is to give my course attendees a bit more of an introduction than the Scrum Guide does.

***

Scrum is an agile method co-created by Jeff Sutherland and Ken Schwaber in the early 1990's.

It was known then, and has been known since, to enable Teams to achieve much more productivity, to find work more satisfying, and to produce wonderful products for customers.  Scrum is not a miracle, it is not a panacea, it is no guarantee, but Teams regularly do impressively better by using it.

Scrum is one of many agile methods.

Agile methods are usually defined as those methods that follow the Agile Manifesto and the Agile Principles.  Jeff Sutherland and Ken Schwaber were both there when the Agile Manifesto and Agile Principles were created.  They helped create them.

One of the key things about Scrum is that it is simple.

Scrum is only providing a bare framework for a Team to work in.  The fewest possible constraints to enable the Team to pop up to a new level of functioning.

What is Scrum most essentially?  Ah!, this is hard to say.  It was created by two guys in New England, and they usually like to express themselves very practically, so you may have to experience Scrum for awhile before you can answer the question.

Team Sport

Scrum is a Team sport.  Scrum tries to enable a Team to be more successful.  Or at least to see how they are doing, and then decide what to do about that.

We mean a real Team. That is, all members of the Team are expected to collaborate.  And each is supposed to take full ownership of the full success.

This does not mean that everyone is equal or that they all have exactly equal skill sets, or that they all have skill sets in all areas.  But that, together, they are taking on the goal of success.  They are taking on the Vision as defined (usually and mainly) by the Product Owner.

We mean a real Team.  Virtually everyone in business has been told 'you are on team X.'  But mostly those are work groups or something similar, not real teams.

Among the attributes of a real Team is that each member is 100% dedicated to only one Team.  And the Team has a common purpose, and all members of the Team are bought-in to that purpose.  To accomplishing that goal.

Team Roles

Within the Team Scrum defines 3 roles:

Product Owner

ScrumMaster

Implementer (role)

Note that the current Scrum Guide calls the Implementer role the 'Team' role, which I think is confusing to beginners.  It gives the impression that there is a Team within a Team.  And I find this is unhelpful.

Scrum lore has the 'chicken and pig story.'  I am told some cultures do not like this story (I do not know which ones or why), and so it is used less.  But in the US (where I live), it is still a useful metaphor.  (Let us of course agree that no one truly wishes to be compared to a barnyard animal.)  I will not give the story here, but the idea is that the pigs are committed and the chickens are 'only involved.'  From the point of view of the pigs and their work, to be 'only involved' is not bad, but it also not good.  The chickens are normally less reliable in delivering what we want on time with high quality.  But we find that chickens are always necessary.  The pigs can never, in my experience, complete their work without some help from some chickens.

Roles Outside the Team

I want to mention two more roles outside the Team.

Customer.  Customers are those real people who will use our product. They may be internal or external to the organization we work in.  It is in delivering something wonderful to them that we get the greatest satisfaction. Very typically, the customers are in 'pain' (in some sense or other) and we are delivering pain relief.  One can appreciate the urgency in doing that.

Business stakeholders.  I use this term to represent the people that must work with the Team part-time, but every sprint.  Mainly to give us feedback. I will say more about them later.

***

The Management Scrum Team

This is an important idea that more and more people are talking about.

One aspect: Managers can only learn what Scrum is and what agile is by being in a ‘real’ Scrum team.

More important aspect: Managers can be more effective in a multi-functional Scrum team. (Often.)

***

STOP!  Why am I writing this post?  Well, it is not because I or we have this idea totally figured out.  In fact, my main purpose is to get others who have tried this idea or something similar to give me (and you) feedback on their experiences, and what they have learned.

Now, knowing our situation better, I hope you and others will provide feedback.

***

What do I mean?  Well, below I will make my comments specific and practical, in case you want to try them.  Also, ideas expressed in a practical way are less likely, I find, to be mis-understood.  I will explain some of the underlying principles, maybe less than others.

Reminder: Other people with a similar idea … have an idea that is also somewhat different.  Thus, they will disagree with me on certain particulars.  USE WITH CAUTION.

Also, I am making a number of simplifying assumptions, and have not expressed all of them.  Again, caution. Also, I am not suggesting that the ideas below will work or even should work in all situations.

***

A Team. Again, we want to call is a Management Scrum Team or MST.

Get a bunch of managers at almost any reasonable level.  They of course need to be similar in some way.

We need about 7 people.  A team too large does not work well, and a team too small is ineffective usually.

***

Now we need to distinguish ‘leaders’ from ‘managers’.   Sadly, this really needs to be a long conversation. Let us say that these people need to at least have real leadership qualities, including setting a compelling vision for the people they work with, being decisive, and having the ability to inspire.  In the managing area, they are not ‘command-and-control’ at least, and hopefully well-skilled at being ‘servant leaders’.  Short version of a long topic.

Some people think ‘management’ is a bad term.  I still like Peter Drucker, and I think the word management is abused and needs to be clarified, but can be useful.  As can similar words, such as manager.  I agree that when an organization tends to always say ‘management’ and seldom ‘leadership’, it is smell…it causes me concern.

***

OK. Maybe we have the CEO and 6 key managers (leaders, gurus, coaches, call-them-what-you-will).

The next thing is to think of them as a Scrum of Scrums.  If at all possible.  To me the key idea now is, they are not doing ‘real work’ (as they always say) but rather are reporting back what their ‘home’ team has done. (The home team may or may not be a Scrum Team.)  It is probably OK if one or two of them is reporting into the MST directly.  That is, they are doing real work themselves.

What’s next?

Notice that I have not (yet) used the word scaling. Partly because few people agree on what the word means.

And because, I am not assuming that the org has or has not already done ‘team-level scrum’, sometimes phrased as ‘scrum with real people’.  To me, we can start doing scrum first with the MST.

Next?

Back to the composition of the MST.  Well, obviously one is a PO (product owner).  Maybe that is the CEO.  One is a SM (ScrumMaster, the key impediment removal driver for the MST itself).  The rest are the ‘doers’ (well, they represent the Doers in each home team).

We have a Product Backlog.  It is prioritized mainly by business value.

It includes…what it ought to include, obviously.  That is, the most important work for the firm.  It might include anything.  It depends on many factors, including the nature of the firm’s business.

It includes ‘real work’, innovation (if you think of that as different than real work), impediments from the Scrum Teams or the departments/divisions, agile adoption issues, cultural change, etc.  Whatever work needs to be done.  Maybe some of the work is easy and some of the work is hard.  Maybe some work is ‘always there’ (in some sense) and some work is ‘temporary’.

Again, the work is prioritized mainly by business value (or, more accurately, bang for the buck, as best they can understand ).  Other factors intrude too.

Perhaps I need to say again…. the people in the MST may not do the work with their own bare hands. They may ‘represent’ other people or teams that are actually doing the work.  In fact, that is much more likely the case.

Sprints.  The MST has sprints.  The shorter the sprint, the better.

With managers, you know, they don’t need any feedback, so maybe the sprints are 3 months long.  Oh, sorry, I was being sarcastic.  With manager work, getting good feedback and fast feedback is even more necessary than with other work.  “The bad news does not get better with age.”  So, seriously, try to get the sprints to be every 2 weeks, or maybe every month.

Agile Release Planning.  This team must do something like this periodically.  Maybe every 3 months, looking forward for the next 6-12 months.  It is complicated, because this team, at a practical level, is often managing multiple ‘releases’ of product.  And they are managing BAU as well (business as usual), which is often a zillion widgets or tickets of CSRs or whatevers.  But, more generically, they define goals and metrics to achieve in some relatively short time frame (in software dev, we used to call this a release or two) and then the basic work items (stories or smallish epics) to ‘get there’.

This has to be some combination of top down and bottom up.  That is, one would expect ‘new ideas’ to have ‘gone to the top’ (no matter where the new idea originated), to be considered and prioritized.  And one would expect lots of basic ‘necessary’ and continuing work to have been identified (or re-estimated) at a lower level and submitted to the top for ‘overall’ consideration.  The CEO often has little choice on the ‘necessary’ or ‘previously approved’ work, but at least in terms of allocating people and resources, the ‘management team’ needs to put it in the picture.

Obviously, this is adaptive planning.  Enough said for now.

Sprint Planning. The MST needs to set a Sprint Goal.  At least a somewhat coherent Sprint Goal.  Always remember what Yogi Berra said: “You have to be very careful if you don’t know where you’re going, because you might not get there.”  In other words, a typical failing is to ‘focus on everything’, which is the same as saying ‘focus on nothing’.  Which means that nothing gets done.

This is a classic problem.  It affects individuals.  It affects Scrum Teams.  And it is probably even harder for the MST.  So, get some focus each sprint.  Maybe another way of saying this is: ‘Try to do less, and you will accomplish more.”  In agile we also have a similar phrase: “Stop starting, and start finishing.”  Or, put fewer things in motion.  Or minimize WIP.  Say it whichever way you want to….Do it!

Now, the work of the sprint needs to be defined in small ‘stories’.  To me, for two weeks, 8 stories for a team of 7 is reasonably small enough, and maybe 16 stories in a month.

Did I mention that this is and should be a cross-functional and multi-functional team?  The ‘people’ within the MS Team are all about the Team accomplishing the Team goal(s)!  So, we are expecting the people in (parts of) the MST to help each other.  We expect multiple people (parts) to typically work on each story.

We also expect the stories in the sprint (the work of the MST) to be ‘completed’ by the end of the Sprint.  To be ‘working product’ that can at least be ‘inspected’ by someone independent (eg, some independent business stakeholders).  The BSHs could look at it and say ‘this is good; customers are really gonna want this stuff’.  Or, at least, this is the feedback we want at the end of the sprint, on each and every story.

So, each story must be demoed at the end of the Sprint.

Writing small stories that can be demoed is a new art for the MST people.  Well, they can write stories that will never be demoed (Sorry! I mean stories that can be demoed after they have left the company…. Sorry!  I meant stories that can be demoed in 5 years).  But, seriously, writing stories that can be completed and demoed in 2 or 4 weeks is hard for them, because they have never done it before.  If you have never done something, in fact it usually feels impossible!  It is not impossible at all, but they probably will feel like it is.  These are tough guys to coach.

Remember that ‘completed’ means having a good ‘definition of done‘ always includes some ‘verification and validation’ by a competent and independent V&V person (in software, we call this well-tested by a good QA person). This also is trouble for them, since they have never done this before.

Daily Scrums.  Daily.  Any questions?  I mean, seriously, can there be any question?

You will start to hear some really lame excuses.  ‘I have another meeting at that time.’  ‘A customer called.’  ‘The President of the US wants to see me in 5 minutes.’  You can’t make this stuff up.  Honestly, some of these ‘distractions’ are important.  But the key root cause is: They do not think the Team is important and they have forgotten how to work as a Team.  And they do not see how the Team is going to help their career.

Jon Defriese thinks this is because the Leader (in our case, the CEO) has not established the right culture.  Often because the Leader himself has not dealt well enough with these issues in his or her own head.

In any case: Daily Scrum.  Daily.  Answering the 3 questions.  Slightly rephrased.

• What did I (or my home team) do yesterday that helped the MS Team meet the Sprint Goal?
• What will I (or my home team) do today to help the MS Team meet the Sprint Goal?
• Do I (or my home team) see any impediment(s) that prevents me or the home team from meeting the Sprint Goal (of the MS Team)?

No impediments is almost never a reasonable answer.  (We focus on the most important impediment, of course.)

Also, we want them to tell each other the truth at the Daily Scrums.  (Stop that laughing! We are serious here.)  And not make ‘political’ statements.  And then to help each other.  (Stop laughing!)

Seriously, it can be tough to coach this team at first.  Often they have totally forgotten how to work together with any team, and especially each other.  Some of you have a better culture, so if you have that case, be mindful that when a new person joins the MST, often he or she comes from a company with a very different culture.  Give that person some time and some coaching to adjust.

Sprint Review.  Alright then!  First, the MST has to ‘review’ things over this Sprint.  Blah, blah, blah.  Keep this part short!  These guys are all good talkers.  The BS meters are running high at this point. Watch out.

Quickly, they have to demo the working stories.  Whoa!  (Neither demo nor ‘working’ imply that product must be released every sprint.)

We need good independent ‘business stakeholders’ (BSHs) to be there to give good, independent feedback in what has been accomplished.  We need to know if we have made real progress.  Or, have we just been ‘working hard’ and accomplished nothing?!  Hence, independent feedback.  Feedback that represents the ‘customer’ for each story.  Some stories are ‘product’ for external customers and some stories are ‘product’ for internal customers. And ‘external customers’ much too often these days means ‘the regulators’.

We need people at the demo who can quickly give us feedback that these different customers will like what the MST has finished this sprint. And I call these people (BSHs).  Note: your firm may call them lots of things.  Examples: customers, managers, dept heads, SMEs, gurus, wise old heads, customer relationship managers, product managers, etc, etc, etc.

Also, often the word ‘business stakeholder’ already has a meaning in your firm different than my meaning.  Watch out for that.

And we need the BSHs to give complete, detailed feedback now.  So, you will not ever get perfect BSHs, but do the best you can.  “The bad news does not get better with age.”

For the MST people, receiving honest feedback can be tough.  They have often not heard that in a good while. All kinds of ‘acting out’ can happen. Some want to ‘shoot the messenger’.  This can be tough on the CEO in at least 3 ways: (a) he or she is getting way more negative feedback than in the past, (b) the direct reports are complaining loudly about the negative feedback they are getting, and (c) the CEO can see that the ‘team’ culture that had been ‘talked about’ for ages does not really exist in they way they had hoped.  This can be tough to swallow.

If there is not much negative feedback, there are two possible reasons.  (a) Everyone is Steve Jobs (or pick another business icon).  Unlikely. (b) People are lying or don’t know how to give feedback.  Often because we picked patsies as the BSHs (and deep-down knew they would give only ‘sweet’ feedback).

Get good and honest BSHs. Insist on the truth.  Remind people that the bad news is the good news.  Because “the bad news doesn’t get better with age.”  Meaning: now that we know it, we’re gonna fix it now, before it becomes more expensive to fix.

Be patient.  “Little things are big.”  And step by step they can all accept that they are imperfect, and improve. Be firm. Be kind. Be honest. Be patient.

Well, a bit more honestly, at some point the CEO is very likely to see that someone ‘needs a promotion to another company’.  The CEO again needs to have been patient. These people are good people in various ways.  And the company’s culture (or someone’s culture) has miss-trained them for many years now.  So, it will take more than 2 sprints for all the dysfunctions to come out and for all the re-training to occur.  So, give people a reasonable chance to adjust.  At some point, someone is likely to be ‘at the far end of the scale’ and you have to give them a ‘promotion to another company’.  (Often we say “It’s not you; it’s me.”  I say this only partly to add a bit of levity.)  And it is tough, but it is also the best thing for that person at that point.

Retrospective.  Again, telling the truth here can be difficult.

We discuss the good and the bad.  We identify the biggest impediment for the MST itself.  And we start to fix it.  As examples, the MST might:

1. devise a solution together
2. plan the execution of the solution
3. build a business case (is it clear that benefits are much higher than the costs)

The business case might go to the CEO or even the Board for a decision.  Often it simply enables the team to work through the information and convince themselves of the best solution.  Often, also, the MST starts the business case, and someone else (the SM?) refines it, improves it, fleshes it out, completes it later.

Who ‘fixes’ the impediments?  Well, it depends.  The SM, the MS Team, or people outside the MS Team.  Depends on several factors.

The key thing is that the Retrospective enables them to get better each Sprint. And in a bigger way than the SM working in isolation, or from identifying the (usually smaller) day-to-day impediments in the Daily Scrum meetings.

***

How much difference could an MST make?

Hard to say.  We do not have enough experience in enough situations to know well.

My experience suggests that in about 2 sprints, the MST is working at ‘normal’ level.  Maybe 3 sprints.  Typically.  But the problem is you had no ‘before’ metrics on the ‘velocity’ of the MST.  So, there is nothing to compare the new Scrum velocity to.

The good news is you now have a metric for the productivity of the MS Team.  They may not estimate the ‘story points’ well yet.  But they are learning.

Usually you find that ‘the velocity is lower than we wanted’.  Is that really a surprise?  (CEO, you did know that already.)

Now you have an approach to getting better as a Team.  And for voiding your weaknesses and for drawing on your strengths.

The difference can be huge.  If people engage, if you allow yourselves to see the truth, if you have the courage to take reasonable actions.

***

One key issue.  I think it is typical to find that the people you have in the ‘management team’ arenot the right balance of people in the MST.  The MST must be balanced against the vision and the items in the PB.  Often you see an imbalance.

Thus, you often need to move some of these people outside the MST, and probably add some other ‘skill-sets’ to the MST (new people).

This is a feature, not a bug.  Meaning: seeing what kinds of people you really need in the MST is a big help.

***

Those are my simplified and initial ideas on an MST.

I hope my humor about the problems of life and the problems we often have being managers was taken the right way. Manager work is hard, and being a manager is hard.  I do have sympathy, despite my sometimes sarcastic tone.

One could cry about the situation, cry at the measureless waste in the lives of the managers and the people they manage, and the impact on the customers.  Or one could laugh. I choose to laugh.

This problem of measureless waste and ‘not good enough yet’ is true for all of us.  And it is sad and we can be sarcastic.  Just to be sarcastic is not good enough.  We must act to improve things, as best we know how.

In this vein, one must have sympathy for managers.  In my opinion, they are usually not trained well to be managers. In fact, they are generally miss-trained (trained wrongly).  In the Peter Principle (they rise to their level of incompetence) is too true.  And their ‘boss’ is too…hmmm….lacks the courage to fix it when the Peter Principle occurs. These are good people, some of our best usually, but badly trained and often badly positioned.  To the degree we can fix this (and I think we can, at least some) it can make for a big improvement.

***

Please give me and us your feedback and suggestions.

Changing the Culture Through Invitation and Engagement

Some of you know my phrase: “People are remarkably good at doing what they want to do.”

It is a down to earth way of saying: I think self-organization is the right thing. Or, I believe in freedom.

Believing in freedom does not mean Congress will always vote the way you want.  Or even vote ‘correctly’ (in 20-20 hindsight).

But it does mean that usually ‘two heads are better than one’, especially if we are reasonable in picking the Team. (I want a Team of 7 usually, not a team of 2.)  We (the leaders) put some basic constraints on the Team (eg, he Vision and ‘don’t break the law’) and NOT too many constraints, and then let’s them run.  Let the horses run!

This also applies to how we broaden the adoption of Agile.

Here is a typical scenario….

We do a pilot project in agile, with some success.

Then the Leader says: I want more of that!

The Leader must set a vision.  Usually tied to normal business goals, such as increasing customer satisfaction, higher quality, faster innovation, etc, etc. the usual stuff.  (Steve Denning talks about profits as the wrong main goal, and maybe some firms put too much emphasis there.  I agree that is an issue.  But not what I am discussing here.)

Then the Leader needs to say something like ‘We have tried some small Agile experiments.  With success.  And it looks like more ‘agile’ will help us.’  And then he needs to roughly provide a vision of Agile.  Maybe that is the Agile Manifesto and the Agile Principles.  Or something like that.  And he needs to say “Let’s see if more Agile leads to better business results. Let’s experiment more…”

He needs to get his people some education on agile. And then he needs to let them ‘figure it out’…or self-organize, decide on the details.

And they will do remarkably well, what they want to do.

Now, this does mean they need to know what they are talking about.  If they don’t know anything about physics, I think it will take them a long time (too long) to come up with E=MC(2).  So, somehow they need some education on what agile really is. Not forcing, just education.

If they ‘allow in’ good agile ideas, they will self-organize well.

Or, in any case, they will do whatever they do better than something that was forced on them.

One of the keys to success of a change is engagement of the people involved in the change.  This approach gets them engaged.  They all contribute to making the change happen.

One of the key phrases about change is: People do not resist change; they resist being changed.  And our knowledge workers are all pretty darn smart people.  Maybe some are stubborn, but all are smart.

***

Related to all this is a set of ideas called “Open Space Agility”.  I invite you to check them out here:

http://openspaceagility.com/