Management Scrum Team - Part 4

This is the 4th of 4 parts.  See here for the 1st part. Links to all 4 parts are there. Or search to the right. *** Retrospective.  Again, telling the truth here can be difficult. The whole MST comes to this meeting at the end of every Sprint. For a 2 week Sprint, maybe 2 hours. The purpose: To get better. What do we do in the meeting? We discuss the good and the bad.  Some of the bad gets added to the impediment list (a list of things we want to fix or mitigate to make things work better here). I suggest we give the SM (the ScrumMaster for the team) a 10 minute time-box to explain what he has done this past 2 weeks. Which impediments he has worked on, what solutions he has gotten implemented, how much the velocity has increased because of his efforts (or efforts he drove). People say things like “wow, I guess he did something useful!” This is kind of like a ‘demo’ for the SM. We identify the biggest impediment for the MST itself.  As of NOW. We do this quickly. And we spend most of the time working together to fix the Top Impediment for the Team. As examples, the MST might:

1. devise a solution together
2. plan the execution of the solution
3. build a business case (eg, to justify spending some money). Is it clear now that the benefits are much higher than the costs? Etc.

The business case might go to the CEO or even the Board for a decision.  Often the business case simply enables the Team to work through the information and convince themselves of the best solution.  Often, also, the MST starts a business case, and someone else (the SM?) refines it, improves it, fleshes it out, and 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. Better can be measured many ways, but typically as higher velocity for the Team. This is more effective, in a bigger way, than the SM working in isolation. And more useful than just 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 3 sprints, the MST is working at 'normal' level.  Maybe 4 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! Right?) Now you have an approach to getting better as a Team.  And for avoiding your weaknesses (of individuals) and for drawing on your strengths (as a Team). 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' are not the right balance of people for a good 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 mis-trained (trained wrongly).  And 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. That covers the main things in Scrum that the MST must do. It gives a quick overview. It definitely does not answer every question you will have. Folks: Careful doing this at home. It may look easy on paper, but you will want to get all the help you can to learn how to do it semi-professionally as soon as possible. Get training, get coaching, at least. Now, please send me your reactions and comments. Joe at jhlittle@kittyhawkconsulting.com      

Management Scrum Team - Part 3

This is the 3rd of 4 parts. Part 1 is here.

***

Now we come to a harder meeting.  The Sprint Review.  It is hard because no one in this Team is used to showing anything completed in 2 weeks.

They are used to showing Powerpoints.  Vaporware. “Thoughts.” With knowledge workers or managers, when they show this stuff, can you tell if you have made any progress?  Of course they say they have done excellent work.  Meaningless. How do you know?  You don’t.  Sometimes they have actually made tons of progress.  Other times, the progress is negative.  Very hard to know when it is progress (they always say it is).

Ok, then, we have to change things then.  We need to have a better fix on whether we have made progress or not.  And, if progress, how much.

Sprint Review.  Alright then!

First, the MST has to do a general 'review' of things over this Sprint.  The CEO does this quickly.  An example:

• • We committed to the following 8 stories in the Sprint Planning Meeting. (He lists them.)
• • We completed 7 of them.  We did not complete the last  one.  We started an additional story, but did not complete it.
• • Our Velocity for the Sprint was 18 SPs (story points, or units of work).
• • That gives us an average velocity of 20 over the last 3 sprints.  With that velocity, we expect to deliver X on Y date and A on B date.  Just a bit later than what we said 2 weeks ago.

Note that the PO is summarizing for the Team. And the business stakeholders are there.

Necessary talking and summary.  Blah, blah, blah.  Keep this part short!  Very short.  This is altogether too much like the usual BS song and dance stuff they have been trained to waste time with….and they have done it for 5+ years.  People have been promoted for no reason except that they are good at this Powerpoint BS.   I could express this more kindly, but I won’t.  As a shareholder of many companies, I am disgusted at the long wasteful meetings that this stuff is usually done in.  Any questions?

But I do agree, we need a short, very short, summary by the Product Owner (CEO).  10 minutes?  Something like that.  Short!!

The other people can talk some at this point. Not much. These people are all good talkers.  The BS meters are running high at this point. Watch out.

Now, they have to show the real stuff. Demo.

Quickly, they have to demo the working stories.  Whoa!  (Neither demo nor 'working' imply or mean that the product must be released every sprint. Depends on many factors.  A typical situation is that it takes multiple sprints for a product to be built enough to release to customers, whether internal or external.)

We need good independent 'business stakeholders' (BSHs) to be there to give good, independent feedback on 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 build 'product' for external customers and some stories build '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 (or not 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, shareholders, consultants, Board members, 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.  Picking the right BSHs (as I defined them) is hard. And important.

And we need the BSHs to give complete, detailed, honest 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'.  Or blame Scrum.

This can be tough on the PO (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 the 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."  (Yogi Berra.)  And step by step they can all accept that they are imperfect, and improve. Be firm. Be kind. Be honest. Be patient.

Well, to be a bit more honest, at some point the CEO is very likely to see that someone 'needs a promotion to another company.'

The CEO again needs to be patient. These people are good people in various ways.  And the company's culture (or someone's culture) has mis-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.  But at some point, one person 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.

***

Part 4 is next.  Feedback is always welcome.

Management Scrum Team - Part 2

Part 2.  (See here for Part 1.)

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 about small enough.

Team. 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.

Done. 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 should 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.  The truth is we often learn that the BSHs are not happy with a couple of stories (that had seemed to be ‘working’). And, the bad news does not get worse with age. (Each failure is an opportunity to learn.)

So, each story must be demo-ed at the end of the Sprint.

Writing small stories that can be demo-ed 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).  [Too much sarcasm? Sorry.]  But, seriously, writing stories that can be completed and demoed in 2 weeks is hard for them at first, 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' requires that you have a good 'definition of done' and that always includes some 'verification and validation' by a competent and independent V&V person.   With software, we call this well-tested by a good QA person. This also is trouble for the MST people, since they have never done this before, usually. Or they have never made transparent what they do or don’t do for V&V.

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

A 15 minute stand-up where each person answers the 3 questions.

You will hear some lame excuses about why they can’t attend or did not attend.  '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 root cause: They do not think the Team is important and they have forgotten how to work as a Team.  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 the Leader 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.  Unless the people are perfect and the situation around them is also perfect. Rarely does this happen. Anything that slows them down from a perfect and fast delivery (of any story) of the highest value is an impediment.

Also, they need to tell each other the truth at the Daily Scrums.  (Stop that laughing! We are serious here.)  Also, not make 'political' statements.  And then, help each other.

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

***

Part 3 is next.

Management Scrum Team - Part 1

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

One reason: Managers need to learn about Scrum.  They can take a course, but they also need ‘reality’, that is, being in a real Scrum Team.  (Real does not have to mean a software dev team.)

Another important reason: Managers can be more effective in a multi-functional Scrum team. (Often.) We need to help managers be more effective.

Now, the purpose of this post is to learn.  Start to define this idea; kick it around, and see how it might be improved or be more useful.  This idea may not be totally figured out.  In fact, my main purpose is for others who have tried this idea or something similar, to give me (and you) feedback on their experiences.

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

***

What do I mean by a management scrum team?

A stable team of managers working toward one vision.  And working on ‘one set of work’ and ‘one product’ (even if broadly defined).

Below I will make my comments specific and practical, in case you want to try them.  Ideas expressed in a practical way are less likely, to be misunderstood.  And I will explain some of the underlying principles.

Reminder: Other people have a similar but different idea. Who is right? (Too early to tell.)  USE WITH CAUTION.

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

***

A Team. Again, we want to call it 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.  And have a reason to work together, a common purpose or goal.

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

Next, form them into a real, stable Scrum Team.

***

Now, distinguish 'leaders' from 'managers'.   Sadly, this distinction needs to be a long conversation.  For now, a leader needs leadership qualities, including setting a compelling vision for the people they work with, be decisive, and have the ability to inspire.  In the managing area, she is not 'command-and-control' at least, and hopefully well-skilled at being a 'servant leader'.  (The short version of a long topic.)

Some people think 'management' is a bad term.  I like Peter Drucker, and I think the word management is abused and needs to be clarified, but can be useful.  As well as manager.  I agree that when an organization tends to say 'management' and seldom 'leadership', it is a 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 Team. Probably each person is representing other ‘doers’ who are not in this Team.  So, the Team is (mostly) reporting on the work done by others. To me the key idea now is: the people in the Team 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 ‘real work’ people are in 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', which might be called '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 person 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, at this level, all the most important work for the firm.  It might include any type of work (or it likely represents a wide variety of needs).   The composition 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' or recurring (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 understood).  Other factors intrude too.

Perhaps I need to say again.... the people in the MST maybe do 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, usually.  I am thinking 2 week sprints.

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 2 weeks, or maybe a month.

Agile Release Planning.  This MST team must do something like what I call ‘agile release planning’ 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 different products.  And they are managing BAU as well (business as usual), which is often a zillion widgets or tickets of CSRs or whatever.  More generically, they define goals and metrics to achieve in some relatively short time frame (in software dev, we call this a release or two or six over, say, 6 months).   Then they define the basic work items (stories or smallish epics) to 'get there'; delivered.

***

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.  As 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.  "Try to do less, and you will accomplish more."  In agile we  have a similar phrase: "Stop starting, and start finishing."  Or, put fewer things in motion.  Or minimize WIP.  Say it whichever way you want...Do it!

***

End of Part 1.  Three more 'parts' to follow.

Part 1, Part 2, Part 3, Part 4

Wideband Delphi estimation

This has been a commonplace idea for many people for decades. And used in Agile for estimating effort for at least one decade. And only talked about in Agile for estimating business value for a few years. See Wikipedia's article here. See James Grenning's article here.

Agile Alliance website - Agile 101

The new Agile Alliance website has a new Agile 101 section.  Within that section is a "Practices Timeline." The timeline is pretty good, and will almost surely introduce you to some key ideas.  Some that you know (but maybe not well enough) and probably even some you don't know (but should).

Scrum at Scale - 4 parts

Jeff Sutherland has recently done a great job in describing his ideas on scaling.

Here are a couple of things I think are key:

1. Scale down.  That is, it is complex to get lots of people involved in one problem or effort.  Simplify.

2. Use patterns.

3. There are alternatives.  While there are some common patterns, and they can work, do not assume every pattern will fit your situation.  Be judicious and experimental.  Expect experiments may not work out well (for a variety of reasons, including ineffective execution).

Here are the modules.  They include video and slides.  See both.

https://www.scruminc.com/scrum-scale-part-1/

https://www.scruminc.com/scrum-at-scale-part-2/

https://www.scruminc.com/scrum-scale-part-3/

https://www.scruminc.com/scrum_at_scale_part_4/

Honesty and Scrum

Are people honest and transparent?

Short answer: Not completely.

Let’s digress first, and then come back to a better answer.

***

To digress….why are honesty and transparency important?

IMO, in two ways. The main reason: we can manage better with the truth.  For example, we get better feedback in the Sprint Review.  If we can see the product transparently and if people speak honestly.  The same notion applies in all official or unofficial meetings a Scrum team might have.

And because there is less to remember.

Honesty is also important in personal relationships.  People tend to like people who are honest.  More trust.  More sense that they know the real person.

And, of course, as it has for centuries, honesty has a bad side too.  These days we use the phrase ‘too much information’ or ‘over-sharing’.  Or we wince when someone gives feedback harshly.  Or says something in an ‘awkward’ way when a ‘smoother’ way would have been just as effective.

Then we have to face life, and some of us find certain parts of life very discomforting.  By this, I mean by work-related things, and things only indirectly related to work.

Here are some general facts we must face:

• our strengths and weaknesses
• time is short
• ‘all things must pass’
• humans are a lot like primates
• humans are not as rational as we want them to be (at least sometimes)
• certain body functions (was that delicate enough for you)
• the classic topics: sex and religion (and politics and money)

I tease.  Humans are primates. And in so many ways, maybe for good or ill or both, we refuse to think of ourselves as animals. Weird.

There are plenty of roughly similar ‘hard to discuss’ topics at your work.  But I won’t list those now.

As we work together, we must expect these ‘awkward’ topics to surface.

To some degree, as we gain trust with our teammates; they forgive us and we forgive them.  And its okay.  We talk openly, give feedback, and set some better boundaries.  But it can be awkward some times.

***

The main points here are a few.

1. We want more transparency and honesty in Scrum.  Mostly this is just to help make work better.
2. Much of the honesty is refreshing and welcome.  It’s fun to be known for who we really are.
3. Still, humans will never be completely honest.  Ever (I think).
4. Sooner or later, you are gonna hear things you do not want (or need, in your opinion) to hear.  We will tease ourselves with this quip: Some things you can’t unhear.

The ScrumMasters, the Team and others will forever be working to help people be more honest.  Also, sometimes ‘less honest’ (about some things).

People will make mistakes; that it will be painful sometimes…is to be expected.  It will just happen.

Mostly it is better. “No place to run to, no place to hide” is a good song, mostly.

Christmas Baskets Program - You are Invited to Help

Every year a local Kiwanis group sponsors a “Christmas Baskets” program to help the children at Berryhill school.

Berryhill is an elementary school in Charlotte, NC with children and families that are struggling.  This is probably true at many schools in our area, but this is the school they selected.  And the Communities in Schools program facilitates this with Berryhill.

You are invited to help or donate funds.

Please contact Cassandra at the office, (704-376-8881) or email (info@leanagiletraining.com). She will put you in touch with the right person.

Below are details with some explanation.  You will be glad you gave; it is not hard to do.

***

What is it really?

Families with children at Berryhill elementary school sign up, asking for help.

We provide about $75 of food and other ‘essentials’ per family. (Donations toward this are gladly accepted by that Kiwanis group.  They do the shopping. I suppose you could help them shop.  Or find a firm to donate some items.)  The families typically do not have the funds for a holiday meal.  And, again, it is not only food, other basic necessities are requested.

People select specific families to buy presents for.  Basically, presents for the children. Typically, they need clothes, shoes and similar basics.  They also want toys and games, to have a festive holiday.

So, you are invited to ‘take a family’ and buy presents for them, (3 kids and a mother, for example).  They are most grateful.  You will receive a sheet with ‘requests’ and clothing sizes and ages), get a ‘return receipt’ (often the sizes will be off), wrap the presents and then deliver them.

You do not have to do the delivery; but I recommend it.  I believe the delivery will happen on November 19th.  I have had my daughters participate in the deliver every year for many years now.  It is a good experience for them.  It should respect for the receipts (whom we are helping, but really only helping a little bit), and it… it changes you.

On the delivery day, you will work briefly with a group of people who volunteered for this.  Some coffee and donuts.  Some briefly friendly chatter.  Some work (organizing stuff into boxes).  Some packing into cars.  Maybe a picture.  This is done at a church that is roughly near the Harris Y (but toward South Park Mall).

Some of the families who ask for help have their ‘act together’ to a good degree.  They may not have much money, but they are making progress, getting there.  Other families are struggling more.  It is a fairly wide range. But all the kids, as I recall over the years, all the kids are optimistic and have their whole lives ahead of them. They are always ‘playful puppies’ (if you do not mind a ‘masculine metaphor’ covering boys, girls, and all kinds of kids).  They have happy eyes, and they are eager to learn.

It is not very much work (especially if you do the shopping with your children and let them help with the wrapping).  It is fairly easy to do — when you deliver, the people are friendly, you talk with them briefly, wish them Merry Christmas (or sometimes Happy Holidays), and then you are on your way.

You will be glad you did it.

If you are interested in participating, please contact Cassandra at the office (704-376-8881) or via email, and she will put you in touch with the right person.

Poppendiecks: The Tyranny of the Plan

Here is a transcription of Mary Poppendieck’s talk. (The tyranny of the plan).

You will find this insightful on many levels.

You might find it more fun to see the video.  Your choice.

Larman's Laws of Organizational Behavior

This is what Craig Larman says on his website.  I quote that page in full:

Larman’s Laws of Organizational Behavior

After decades of observation and organizational consulting, here are Larman’s Laws of Organizational Behavior. These are observations rather than laws to follow.

1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.

2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.

3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, “religion”, and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.

4. Culture follows structure.

or, “culture/behavior/mindset follows system & organizational design”i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that’s why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. i discovered that john seddon also observed this: “Attempting to change an organization’s culture is a folly, it always fails. Peoples’ behavior (the culture) is a product of the system; when you change the system peoples’ behavior changes.”

***

Here is the original page.  Some key information on getting organizations to change.

The ScrumMaster Should Not be a People Manager - 2

This is a continuation of this post.

Some more observations.

***

Before we start…some more basics….

1. The PO has an important role.

Especially key in deciding which PBIs or user stories the team will get next, and important in many other ways too.

2. The SM has a key responsibility in making the ‘continuous improvement’ engine work in Scrum, and for the Team.

This is so important.  And soo seldom does it really happen.

3. Each Team is different, each SM is different.

So, while we can describe the SM (or any role) based on the ‘normal desirable’ state, we must also deal with people or groups that are different, or unusual SMs.  These are NOT included in this overall discussion, but are always something we must deal with, sooner or later.

4. Scrum is not the only way.

It is about the only way I advise, for many reasons. And there are some caveats, but too much to discuss here and now.  So, even though something else may work or ‘be better than we were before’, that does not mean one should not have done ‘real Scrum’ and have been yet better than that alternative.

Still, one can do something else, and maybe often get somewhat better results than you had before.

But the question should be: could we have gotten even better results with a different approach?

And, to the degree you are not doing ‘full scrum’, I am suggesting trying full scrum first.  Or as soon as possible.  And seeing if the results are not even better.

***

So, here are some issues:

A. The PO role is important, and the SM role should not challenge it.

It is true to say that the SM is a kind of leader in the Team.  The PO is a different kind of leader.  But it does not help if the SM challenges the PO in the PO domain. (I will call that domain: deciding which work is most important).

The SM often must teach the PO how to be a good PO, sometimes by helping him for a time.  But this is not taking over the PO job permanently.

B. The SM must make the Team own the success.

Talking as though the SM owns success is not going to help. As soon as the SM gets very powerful, compared to the other team members, it is not likely to be good.

In my opinion, as soon as you say the SM is responsible for success, everyone else in the Team drops down some in motivation and energy, and self-organization is not happening as well anymore.  Sometimes this is very subtle.  Sometimes it is ‘seen’ in the lack of increased productivity that we would have seen if they had continued to self-organize.

Just asking the team (‘do you own success?’) is not sufficient, especially if they know that the ‘right’ answer is yes.

C. The SM must ‘make’ the Team self-organize.

We have said this before.  The point now is, this is difficult, and almost on a knife’s edge.  If the SM moves much away from the servant leader, it is very likely that this will inhibit the self-organization of the Team.

Again, the change can be subtle, and people may barely perceive it at first.  And not talk about it.  If the SM pushes the Team, it may be mainly seen in the lack of improvement in productivity in the Team, rather than a clear decrease in productivity.

D. The Team needs transparency.

The Team must self-organize, self-direct, and self-control itself.  (Outside people can have some role and some influence.  More on that in a later post.)  To do that, the Team (that is, each of its members) needs to know where it is.  The facts need to be transparent. Or, more transparent, to enable the Team to use that information to self-organize more usefully, to make better decisions based on better information.

It is the SM who must foster transparency.  It is human nature to want to hide things, and the SM should be making it ok to tell more of the truth.

Again, the trendline on transparency is subtle.  It is usually either getting better or worse.  But is hard to identify the things that are not said, simply because they were not said.  People like to pretend they are very honest and open with each, and yet that is not really always the truth.  We know this without consulting Dr Freud’s ideas about the unconscious mind.

So, if the SM has power over the Team, especially all the Team, as the one who gives them reviews and compensation increases, then we should expect reduced transparency.  And yet, the SM will never know that the transparency is reduced.  If the Team kind of likes him, they typically will never say ‘I am not telling you everything.’  Often, they will not even admit to themselves they are withholding information.  And yet that is happening.

We think there are a few people who will say almost anything to almost anyone.  That is true.  And if their ‘boss’ is the SM, they will still say (almost?) everything to him (or her).  But we think these people are fewer than some of us want to think.  And even then, these ‘brave’ people are not quite as brave as they say, in our opinion.

Hence, we never advocate that the boss become the SM.  Never. It might work, but we do not advocate it.

E. The SM is essential to continuous improvement.

Even 100% dedicated SMs often ‘slack off’ in driving that impediments are being fixed every day.

If we give George additional roles, George is even more likely to not devote enough attention to impediments.

Impediments are all the things we can work on to become better, to improve.  And sem-naturally, the Team will address really key impediments, eg, the system is down.  But often they ignore impediments and focus on real work (as they call it).

So, the SM is key in making sure someone is working on the top impediment now.  Hence, the Team does not improve nearly as much as it could have.

Can a Team improve without an SM?  Yes, just in the fine art of working better together, a Team can get noticeable improvement.  And this can happen almost as if by magic.  But to get real continuous improvement, and start to get more of that faster, you must have a fulltime SM.

***

Can we live without doing all these things?

Well, certainly.  We did not die even though most of us a few years ago did not even know about Scrum.

Let me give one concrete example.

You have a person, George, who is the boss of the Team.  You look at the Team, and there is no one who would be a good SM.  You talk to George, and discover that in most respects George would be a good SM.  But, he is the boss of the Team.  You look at the relationships between George and the Team members, and you find that George is an ‘open’ manager, that his Team, by most standards, is very open with him.

Well, in this case, because there are so few options, it may be best to let George be the SM.  It is not the preferred state, and it should be fixed, but one judges that it is probably the least bad of several options, at least for now.

But, this would never lead us to recommend that the boss become the SM.  We might live with it as an accommodation to ‘today’s realities’, but we are not happy with that part of the situation.

***

Broader suggestions.  The SM must act on the following.

1. The ‘rules’ of Scrum are not as well known as we would like.

2. You may be forced to break the rules of Scrum, but try to do so knowingly, rather than without any thought.

3. Try to measure or in some other ‘open’ way, identify your Team’s biggest problems, and then do something about them.

4. If breaking some of the rules of Scrum turns out to be a big problem, identify that, and fix it soon. If it is a priority.

The Organization of the Scrum Course - 2

See part 1.  Now continue below with part 2….

***

One of the big problems is that the attendees, or many of them, resist intellectually.  So, as in Zen, we have to confuse the intellectual mind in order to enable real learning to happen.  Or, as the Army says, we have to break them down in order to build them back up again.

We have to ‘go around’ or ‘get behind’ the intellectual resistance that is common to just about all of us. So, one technique is to do exercises. Not following a highly logical flow is another technique. Surprising the attendees (in small ways) is another. Humor and improvisational exercises are other techniques. Food is another.  Addressing them directly, and getting to know them as a person is another technique.

For some, our techniques are…umm, disconcerting. If a person is a certain type – well-organized, intellectually rigorous, thinking, logical – it can feel a bit uncomfortable.  But if one has at least an intellectual understanding or some real experience that people and  life do not always follow pre-conceived intellectual notions, then it is not so uncomfortable. Very few people are uncomfortable, although a very few are.

So, I admit that the course to a new person, or to a few, might feel uncomfortable. (Actually, my impression is that most people enjoy it. About 98%.  But not all.)

During the course, if you tell me you have that an uncomfortable feeling, then I will offer some advice. First, I will address the topics that are on the one-page (two-sides) outline of ‘Scrum’ I hand out (it is really more than just Scrum).  I will follow the outline on the website. (Except not in that order.)  We will follow the slides, except  we will cover additional material.

We have a strong confidence that most real learning is not logical, per se. It happens in the sub-conscious mind, where experiences are ‘put together’ by the brain into a ‘logical’ way of looking at the world; assembled into a pattern or set of patterns. I try to  force your brain to break down old patterns, and rebuild new patterns.  I have confidence most of our attendees can do that.

And I know, sadly, many are ‘controlled’ by ‘waterfall ideas’ and they will not be able, after only 2 or 3 days, to really replace the waterfall patterns with agile/scrum patterns.  Some people are like that.

Would we succeed better if we presented things in a more organized, more logical way?  Well, a few people might say ‘it was a good logical presentation’.  That small group, would feel better.  But I am completely convinced that, if you look at the overall results, they would be much much lower.

Remember that our goal is not teaching. Nor learning. Nor even action by the attendees. Our goal is that attendees achieve real results with Scrum. For the person, for that person’s team, and for that person’s customers. One will never achieve real results with merely a ‘logical understanding’ of the work.

So, we are not after explicit knowledge. We are after ‘a sense of urgency’ and the tacit knowledge that leads to successful results.

So, I hope now it is clearer why I organize the Scrum course the way I do.

I wish you every success in having fun in achieving real results.