Question: Advice to a beginning ScrumMaster

Virginia asks: “I am a beginning ScrumMaster in a tough situation.  I have some ideas, but I am unsure what to do.  And unsure what to do first.  What can you suggest?”

Answer:  I think this is a common problem.

But, in reality, there is no end of things that a ScrumMaster can do to help the team.

First, take what you already know about Scrum, and remind the Team what Scrum is.  And why….what the values and principles are.

This can be done in a thousand ways.  One example: Post the Agile Manifesto and the Agile Principles in the Team room.  After each Daily Scrum, ask each member of the Team to take two minutes to explain something about one line or one item from the list.

You will be impressed how well they explain the agile ideas to each other.  And then, you can add an additional insight. Maybe something you think they could improve on.

Read or re-read Agile Project Management with Scrum by Schwaber to get lots of stories and ideas about how Scrum should work.

Second, get a better list of impediments.  Ok, let’s be honest — START a list, a public list.  Yes, of course collect the ones they tell you in the Daily Scrum and in the Retrospective.  Add the ones that you see.  Read this blog, and steal some impediments that apply to you and your team.

You want a list of the top 20 things to improve, broken down into actionable things, where you could see, smell, notice improvement in 2 weeks or less.  Yes, you often start with some epic impediments…but just start there…

An impediment is anything, ANYTHING, that is slowing down the Team. Example: Anything that stops a story, slows down the Team. People issues, technical issues, organizational issues, the weather, I need coffee, I need a dentist, we need a different culture, whatever. Whatever.

Ok, we have to discuss two things that happen universally in the Daily Scrum, at least at first.  They don’t divide the tasks into small pieces, and they talk vaguely about what they worked on, and do not focus on what was DONE (completed).  The tasks must be mostly in the 2-4 hour range.  And they must say whether or not it was completed. If a 4 hour task is not completed in one day, clearly there is some kind of ‘impediment’ (eg, I cannot estimate very well).

Then, they must give their biggest impediment. (What slowed them down the most.)  Time itself is not an impediment.

It might be: “I don’t know this area that well.”  Or: “The servers were down.”  Or: “Well, if the tests were automated, then I could have found the bad code faster.”  Or lots of other things.  Saying: “None” is not an option.  Implying that ‘things are so good around here, that there is no way it could possibly get better’ is also not an option.  Things can always be better.

Also, you must give them a challenge.  Tell them: “We have to double the velocity, in a way that we believe, and not by working any harder.  So, what do we have to change to do that?  And imagine that anything could change. Anything. And that the managers will approve anything, if we can make a good case for it.”

For the Retrospective, see also Agile Retrospectives by Derby and Larsen for more ideas to uncover the real impediments. They have forgotten lots of impediments because they have become used to them, or they can’t imagine that it could be changed.

Third, aggressively attack the impediments.  Every day. Every hour.  Take the top one, and go after it. If you can’t fix it yourself, that is fine.  But get someone to.

I do not mean go crazy. Use some common sense. If the cost is greater than the benefit, than do solve it that way.  Sometimes you can only mitigate the impact. Etc, etc.  But still, every day and every hour, attack the top impediment.

Fourth, tell them.  Tell the right people what you will do, what you are doing, and what you have done.

Mostly, you tell the Team.

How?  In the Daily Scrum (you answer the questions, and tell them).  In the Retrospective.  And in other ways that make sense.

Why?  Well, not to brag as such.  But you need to know they care.  They want the ‘fix’ that you will give, are giving, did give them.  Also, once they know things are getting fixed, they will get more creative about talking about things you could fix.

Fifth, keep a list of ‘fixes installed.’  All the things you did, or got done, to make their lives better.

Why? So, when you are discouraged, you can look at the list and get some encouragement.  So, so when the wonder why you are not doing ‘real work’, you can remind them of your value.  So you can justify the managers why you deserve a raise.

Track the list, and make a reasonable guess as to how much of the improved velocity of the team is attributable to the fixed or mitigated impediments. Typically 100% is effectively attributable to you.  Yes, Scrum itself did some (but you still take credit). Yes, the Team did some things, but honestly probably would have done very little without you, or would have done it very much later.  It does not matter that you did not do it ‘with your own hands’.  You made it happen, you were the key.  It does not matter than some improvements cost ‘extra’ money. The benefits were huge, and mostly would never have happened without you.

Do not slack for even one day.

The Team and the customers deserve everything you have to give.  And you too will be rewarded in ways hard to explain but very clear…by all the good things you make happen.

Sixth, to help you become a better ScrumMaster faster, start a ScrumMasters club with other SMs in your area.

Learn from each other. Maybe have a brown bag once a week, and present ideas and experiences to each other once per week over lunch.

That’s a start. There are many places and ways to learn.  As you act, you will discover more ways to learn, and more things to learn about.

Does that help?

 

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss

Organizing a small-ish company to do Scrum and ‘regular work’

Holly asks: “I am relatively new to this methodology, but I would say I would like to learn more about how resources are assigned to Scrum teams.  Resource allocation – do Sprint team members need to spend 100% of their time in a Scrum Team?  If so, how do we account for existing job responsibilities?”

***
Good question or questions.

In simple terms, we are dying from complexity.  So, we want to keep things as simple as possible, to help people become more productive.

This is what I am thinking from what I know so far of your situation.  Imagine that your company has 800 employees, but most are ‘in the field’.  So, you have 75 people who support ‘BAU’ (business as usual), who are not ‘in the field’ and so are also potentially available to support Innovation.  And, to some degree, do need to support Innovation.

So, for 125 of the BAU people, I would have a rule that they are 80% dedicated to BAU and each person can use up to 20% of their time to support ‘innovation’.

I would maybe move 25 of the current BAU people to an Innovation group, which would include other people already doing innovation (technology people, project managers, etc.).  Then we call this the group of people doing ‘Innovation’ or ‘Change’, which now has about 75 people.

Let’s assume my ratios of BAU and Innovation people is roughly factually correct for now.  For example, it provides enough hours to do the related BAU work (if 20% of their time is also given to Innovation).  But it still raises two questions:
(a) is this the optimum ratio?
(b) should the firm be investing more (or less) in Innovation?

These two questions should be of prime interest to the Exec Team.

Note that often the Innovation people are doing work to benefit the BAU people, directly or indirectly.

These are the two main groups.  Note that the innovation people include business people also.

I would form most of the people in Innovation into Scrum Teams.  But the BAU people are NOT part of the Scrum Teams. At least not as ‘pigs’, although they may work with the Scrum Teams some as chickens (in their 20% time).

And we would group work into ‘Product Backlogs’ that have groupings of stuff that can be released quickly.  And we get a limited number of ‘projects’ or product releases in flight at any one time. In simple terms, one project per Scrum Team (per 7 people in a Scrum Team).

Obviously, we can only support, with the Innovation people that we have, a limited number of product releases at any time (in any year).

Each Innovation person is 80% dedicated to one Team (but can advise others with 20% of their time).  And the Innovation people are 100% innovation…no meaningful BAU responsibilities.  They can ‘advise’ others on BAU work in their 20% time.

It may be that some lower priority projects will ‘require’ some BAU people to be involved. But a lower priority project can only start if someone feels that they can get enough BAU support to be viable.  Or can get enough ‘business support’ elsewhere (within Innovation, via consultants, whatever).  And this will not be the case; this may represent a significant constraint on the number of inflight Innovation teams. So that some projects will be blocked until higher priority projects complete, and ‘release’ certain BAU people.

So, X project may not be able to start.  The Exec Team can decide to hire people or not, to fix that impediment.  Or, we go to the next viable priority project.  (Remember that business information can get into a Team either from Innovation people (eg, product owners or BAs or whatever we call them) or from BAU people.

Why?  We need to be focused on getting things DONE, not on how much work is ‘in process’.  We need to be focused on clear accountabilities by Team. Each Scrum Team is focused on only the one next release.  (That means the release is much more likely to get done well and quickly.)

How to form the Teams?  Here is a good option.  Have 3 managers draft up a set of teams.  And let all the Innovation people look at that and then ‘self-organize’. They can modify the proposal.  Maybe give the Innovation people a week to meet and discuss and change the proposed teams.  With the understanding that any person in a Team is 80% dedicated to that one Team, at least.  And then the 3 managers get to review the alterations and give final approval.  But the group usually does a very good job.

Usually later we discover a few things, and realize we need to make some adjustments, but the Teams usually can manage that.

The real issue is when to start and stop ‘projects’.

Whenever we have a better project than one currently in flight, we need a way to start to pause the existing project (or get it to release early) and start the higher value project. Before pausing a project, we tell the related Team, and ask them ‘we want to ‘pause’ your project…can you release most of what you have now ‘real soon’?  How soon?’  And then adjust according to their advice.

Another issue is: when does the ET know that a Scrum Team is coming ‘free’?  I give the Scrum Teams the responsibility to ‘brag’ about a Release that they are about to put out.  And they are clearly expected to release quickly, and also to release high value and high quality products.

So, when a Team has just released, it is also a time when the ET can give the Team a different ‘assignment’ or ‘mission’.  The Team may make a case that they need to stay on Product1 for the next release.  But the ET gets the final decision.

So, in this vision, the main jobs of the ET are two (for the innovation teams)
1. Fix impediments
2. Be decisive about priorities.

This last includes….when a Team finishes a release, what do we give them next?

Given where we have come from, I suspect the Team will have to say (probably repeatedly for awhile): “We are only working on one and only one release at a time…the top priority one.”

 

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss

Learnings from the Toronto Scaling Workshop

Last week we had a Scaling with Agile Workshop in Toronto.

More and more I am convinced that this scaling workshop is necessary for many people to figure out how to do Scrum well in their business situation.  They just need to work through how they will make it work in their context.  And many of the problems have to do with ‘scaling’.

Of course, not every person or team or company has ‘scaling’ problems.  So, ‘scaling’ solutions do not need to be included with Scrum (for everyone).  And of course these scaling issues vary widely and differ from situation to situation. Often in the same company.

We like to define scaling and the related words precisely.  Scaling as such, to me, is really limited to having 3 or more Scrum Teams working together on one Product.  (We use other words for the other problems that often come along with scaling or are included in ‘scaling’ by some people.)

Scaling, as we define it, still is a common problem. Often, as just suggested, many other problems come along with it. Cultural change, agile transformation, distributed scrum, etc, etc.

In the Workshop, we gave the attendees a basic framework, and an approach to defining their problems.  We tried to focus on scaling proper, but we also took questions and issues with ‘scaling’ more broadly defined.  We took their real issues.

It was impressive how different the real problems were.  Yet both were ‘scaling’.

To give them background, we discussed patterns, we discussed ScrumPLOP.org, we discussed basic and classic Scrum patterns; we discussed LeSS, and we discussed SAFe.  The key concept is: how do we try simple patterns that fit the specific needs that your situation has?  And see if we can make some progress today, and not make things overly heavy or complex.

It was impressive how, with a few key concepts, they could easily design solutions to most of their pressing problems.

One last key concept.  The real energy is inside the Team.  All the bright people running all the scaling stuff do not add any value directly. At least so far as  the customer can tell.  They may be necessary, but not essential.  So, maybe you divert some energy from the Team(s) to the ‘Scaling stuff’ for some temporary time.  But remember to focus again soon on the Team(s). Remember that the real power of scrum is in the Teams.

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss

Halifax: Public Impediment List

As some of you know, I am a strong proponent of aggressively attacking the impediments. And I think it starts with a good public impediment list.

So, as examples, here are the impediments identified by the class in Halifax.

  1. Team is working on too many things
  2. No prioritized backlog
  3. Uninvolved PO
  4. Keeping everyone in the loop (not)
  5. Complexity
  6. Lack of management attentiveness
  7. Acting on retrospective improvements
  8. PO not involved
  9. Lack of understanding
  10. Silo workers
  11. Lack of impediment list
  12. Lack of retrospective
  13. Increasing Tech Debt
  14. Not having vision from PO
  15. Managing people instead of work
  16. Lack of team spirit
  17. Managing interference
  18. Unmotivated
  19. Bottom down planning
  20. Too much useless chatter (from Mgmt, I think)
  21. Lack of early feedback
  22. No ending [to] project
  23. Not following process
  24. Conflicts (too much)
  25. Keeping Top 20 impediments
  26. Distributed team
  27. Lack of process
  28. Lack of management
  29. Communication
  30. Too many cooks
  31. Product knowledge gap
  32. Scope creep
  33. Not defining DOD
  34. Lack Buy-in
  35. Lack of process for Development Tasks
  36. Technology group (IT) support infrastructure
  37. Testing Time
  38. Bug fixing time
  39. Not having all Scrum activities
  40. Management available
  41. Lack of communication
  42. Poor planning
  43. No estimates (no velocity)

 

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss

Peter Drucker on Knowledge Worker Productivity

In the Winter of 1999, Peter Drucker had published an article on Knowledge Worker Productivity: The biggest challengeHere is access to the article.

Here is the second sentence: “The most important contribution management needs to make in the 21st century is similarly to increase the productivity of knowledge work and knowledge workers.”

Here is a quote from some key ideas in the article:

Six major factors determine knowledge-worker productivity.
▪ Knowledge-worker productivity demands that we ask the question: “What is the task?”

▪ It demands that we impose the responsibility for their productivity on the individual knowledge workers themselves. Knowledge Workers have to manage themselves. They have to have autonomy.
▪ Continuing innovation has to be part of the work, the task and the responsibility of knowledge workers.
▪ Knowledge work requires continuous learning on the part of the knowledge worker, but equally continuous teaching on the part of the knowledge worker.
▪ Productivity of the knowledge worker is not—at least not primarily—a matter of the quantity of output. Quality is at least as important.
▪ Finally, knowledge-worker productivity requires that the knowledge worker is both seen and treated as an “asset” rather than a ”cost.” It requires that knowledge workers want to work for the organization in preference to all other opportunities.

Very interesting ideas.

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss

Culture & Agile & Change at the NYC Scrum Users Group

We had a great discussion.  The group was great, very active participation. Thanks especially to Rob and Mary.  And to many old and new friends.

Here is the slideshare: http://www.slideshare.net/jhlittle/changing-culture-v6-nyc

We talked mainly about Fearless Change.  This is the work of Mary Lynn Manns and Linda Rising.  And they are soon to publish a second version of their book: Fearless Change (see Amazon, for example).

Here is the Appendix to the book, updated: AppendixFebruary2011
Wonderful list of the Patterns.

Here is an article that roughly summarizes the book: Leading Fearless Change

And here is the URL to more information: http://www.fearlesschangepatterns.com/

We also talked about Open Agile Adoption.  My one sentence summary: inviting everyone to participate in the change. Or even to openly complain that they are bothered.

The second sentence: Use Open Space to enable them to self-organize into participants in the change. (If you don’t know Open Space, then google Open Space Technology.  You need to know about it.)

Related to my ‘Little’s Second Law”: “People are remarkably good at doing what they want to do.”

See the slideshare above for more.  And also see: http://newtechusa.net/open-agile-adoption/

Dan Mezick has the Open Agile Adoption Handbook coming out ‘real soon’.

There is of course much more to the ‘agile culture change’.  Many more wise guides. But these are two great places and 3 great people to start with.  Do not be overly influenced by the characteristics of the people.  The people have their ‘positive’ and their ‘negative’ aspects, depending on who you are.  Give their ideas a ‘fair’ chance, and try to put your positive or your negative biases aside.  For example, I personally find Mary Lynn Manns a completely likeable person, but that does not make her ideas ‘correct’. (Still, I think the ideas are wonderfully simple and useful. And the action is: we must DO them more.)

 

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss

What to tell the Executives?

It often turns out that they are not as dumb as you think.  So, first, be patient and be hopeful.  Too many of us start the conversation feeling helpless and defeated.  Do not; they will understand eventually.  (I am of course speaking to ‘an agile guy’, whom I am imagining as not a Manager or Executive, and not too familiar with what their world is like.)

To a Manager or Executive who is approaching Agile-Scrum for the first time: Welcome! It is actually going to be great for you, much better! ….

Make sure someone takes the time to explain it to you. And, please, accept that it will be harder to really understand than you expect.  It is simple, but hard. Is it ok if I use ‘love’ as a metaphor?  In some ways, very very simple.  But how do you explain it to your 18 year old daughter?  Ah, as you see, not so simple anymore. … OK, you might prefer a tennis metaphor or a golf metaphor. Key: It’s a big change.  Give yourself time to fully work through it.  And accept that you will mis-understand a lot at first.  For the first 2 years.  It’s not your fault, it’s not Scrum’s fault.  It’s just hard.

“Some people, if they don’t already know it, you can’t explain it to them.”  (I am talking now, again, to the agile advocate.)  So, find what they already know, and build on that.  And they always know something ‘agile’ already. (And they have also been indoctrinated in the opposite of agile for 10 years.)

So, I have to do a session with Executives next week. Roughly 30 in the room, including the CEO. What should we say to them?

Here is what I have decided to say today.  (I may learn by tomorrow.)  I am focusing on these 8 key ideas or issues:

  1. We have knowledge workers. As soon as we recognize that they are knowledge workers, it changes things.
  2. Minimize WIP.  Simple version: Only one project per Team.  Forget keeping all these other projects ‘in-flight’.
  3. A Team learns. Have a Team, and appreciate the Team as a learning unit. Help them be a great Team.
  4. Self-organization.  Allow them, within some basic constraints, to self-manage and self-direct.
  5. “Random carbon units”.  Accept the uniqueness of each person. They are no longer ‘resources’ (plug-replaceable things).  Treat them like real people, with all the good and bad that means.
  6. Subtle control. Use it, and do not use ‘power’ control.  Includes ‘control by love’ as Takeuchi and Nonaka say.
  7. “Failure is good”.  Failure where we learn and improve leads to real innovation.  Embrace it.
  8. “The bad news does not get better with age”.  “We build quality in from the beginning.” Which leads to “You have to slow down to go fast.”  Which is very obvious if you understand, but an enigma within a paradox if you do not.

To be honest, it is probably 3 too many for the ‘first’ time.  People can only absorb a little at a time.  Step by step.

Comments please!  Or send me an email.

Here is the slideshare: http://www.slideshare.net/jhlittle

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss

Public Impediments – Toronto March 2014

Here are the issues this group thought were important.  Many are ‘issues’ in a waterfall model.  Not necessarily in priority order. Not necessarily impediments in an Agile model.  Some are vague here (stated in few words), but I think they knew what they really meant.

  1. Management apathy
  2. Unclear goals
  3. Too much process
  4. Changing requirements
  5. Insufficient people
  6. Work overloaded
  7. Large team
  8. Redundant skillset
  9. Internal compertition
  10. Single out individuals
  11. Late request
  12. Project cancelled
  13. Newly formed team
  14. Distributed
  15. More layers (different teams)
  16. Too many scope creeps
  17. Not enough executive engagement
  18. Not good leadership
  19. Delays from vendor
  20. Not enough knowledge in team to solve issues
  21. Tasks not properly assigned to team members
  22. Didn’t allocate enough time for unknowns
  23. Team was told what / when
  24. Management and Execs painting a different picture
  25. Blame / “steamrolling”
  26. Forced to “report” waterfall way
  27. No clear product owner
twittergoogle_plusredditlinkedinmail
twitterlinkedinrss

Public Impediments – Charlotte March 2014

The group came up with these impediments.

  1. People issues
  2. Distractions (multitasking)
  3. Lack of resources
  4. Arbitrary long time estimates
  5. Lack of feedback
  6. Black box projects
  7. Dishonesty
  8. Management constraints
  9. Team too big or too small
  10. No clear roles
  11. No funding
  12. Unrealistic expectations, time or $
  13. Team improperly formed
  14. Too many impediments (main cause of failure)
  15. Inexperience (wrong skills)
  16. EGO
  17. Poor listening
  18. Unchesiveness
  19. (lack of) localization support
  20. No direction
  21. Stubborn people not aligned with Team
  22. Budgeting not clear
  23. Shareholders having diverse interests
  24. Lack leadership
  25. Teams not talking to associated teams
  26. Lack of resources dedicated to Team
  27. People turnover
  28. Performance not measured – no data
  29. Real product owner is not identified
  30. No clear process / product owner
  31. Cross-purposed stakeholders
  32. Lack of stakeholder buy-in / support
  33. Upstream / downstream dependencies

We hope this list helps your team get more creative about the impediments.

We are a strong advocate of a public impediment list.

 

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss

Definition of Ready

Gabriel asked:
Hi Joe,
Can you recommend few good sources for “Definition of Ready” ?

***

I like Jeff Sutherland’s stuff.

Did you see this?
http://scrum.jeffsutherland.com/2009/07/ready-dynamic-model-of-scrum.html

It includes an article.  Read that.

As he taught me, the DOR is flexible team by team.  Each team must decide on the details of a DOR, based on the needs of the team members, the PO, the type of product, etc.

And from their experience (what works, what doesn’t).

One key thing: eliminate anything the Team  (Doers) do not use.  Do not over-document.
See also Jeff’s blog on the Enabling Specification. (I also have some blog posts on this topic.)

And see my earlier post on getting to Ready.
Regards, Joe

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss