Why managers should crave Agile

One idea in the Agile community is that with Agile, we do not need any managers anymore.

For those of us who have or have had Dilbert managers, this is a happy thought.

But actually, of course, a silly thought, if we have any good managers in our company today.  And 'good' means not only morally sound, decent, reasonable, and fairly logical, but also well-trained.  It is my view that most managers in the US have not been trained well.

So, we need good managers if Agile or Scrum is to be successful, or more successful.  And it is generally true that the Agile/Scrum community still does not devote enough attention to what 'good management' would be with agile or scrum.

But first, again, we must address the issue of why any manager would want agile or scrum.

Who is good at explaining this?...please raise your hands! (Usually few if any hands go up.  Sadly.)

So, here quickly are some reasons managers should crave agile.

1. It gives more to the customers.

The customers get more product, higher value product, higher quality, and sooner. And at lower cost.

All managers should care about the customers, and should consider this a big win.

2. It finally gives us a handle on whether we are making any progress.

Before, the people were working hard.  But how would a manager ever know if any real forward progress was happening or not?  The basic answer was: no clue.

Well, not quite.  If you had a really good group that you knew and trusted, and they had succeeded with the previous work, and they were a small group and the effort was fairly small, and the new work was pretty darn similar, and if the first release was fairly soon, then you started to believe them when they said they had made some good progress.  But notice how many conditions I had to add.  Lots.

With Scrum, with the definition of done, and with velocity, we can get a real sense of how much progress we are making toward a release.  That sense of progress is quite real.  It is subject to two things, at least in terms of hitting the original date: (a) that relatively few 'new' features will be identified that 'must' go in the next release, and (b) the team has a strong DOD and are not hiding things.

3. Agile and Scrum do not require you to micro-manage.

Is there a single manager who truly enjoys micro-managing?  Surely some appear to.  I think all reasonable managers hate it.

4. Agile and Scrum provide substantial help in motivating the Team.

Getting a team motivated is hard.  In fact, I think the experts say that you cannot really motivate anyone.  You can, as a manager, do only two things: (a) remove de-motivators, and (b) explain why someone might want to be motivated.  But you cannot make someone be motivated.  That is essentially a choice or arises based on an interior value system.

How does agile and Scrum help?  Well, in many ways. The Team has a clear mission that important people think is important.  The Team is building the highest BV stuff first (as a general rule), and that is visible.  The Team is in it together, and the sense of camaraderie engenders fun and a sense of commitment to each other. The Team only commits to one sprint at a time; this is much less forbidding.  The Team sees in the Sprint Review each Sprint, immediate feedback.  And mostly forward progress.  This fills their sense of hope about the release.  And the Team devotes some time each Sprint to getting better (eg, the Retrospective).

5. You only have to manage the Team.

To a large degree, the Team manages itself.

This does not mean you have nothing to do.  Far from it.  But it does simplify the 'noise and confusion' that so many managers feel.  No longer do you have to manage 8 people (or 8 x 8 people).  Now you can manage just 1 team (or 8 teams).  A far simpler thing to manage.

Because this is simpler, you are able to focus more, and should achieve more success.

Now, it is true that managing a team is somewhat different than managing individuals.  And it requires different techniques and approaches.

6. Better cycles of control

Every sprint you have a new 'cycle of control.'  And this is far better than in the old way.  In the old way, people would show you 'stuff' that was hard to evaluate, and say 'look at how much I or we have done.'  And you had to struggle to assess it.

Now, at the beginning of the Sprint, the Team promises 8 small stories (features), and at the end of 2 weeks (or whatever the sprint length is), they have to show the working product.  And get feedback from people who can represent the customer well (I call them business stakeholders, and they might even include some real customers).

So, what is happening (or not happening), or what is progress (or lack of progress) is much much more transparent.

It is just this simple: It is far easier to manage if you can see what you are talking about.

And, in addition, the cycle of review is a nice period, such as every 2 weeks.  All the hourly and daily ups and downs go away, and you see what the team can do together in a relatively short cycle, such as 2 weeks.  And that cycle is also not very long.  And allows you to to make mid-course corrections usually numerous times over an initiative (which might include one or more releases).

7. Impediments

In Scrum, the Team identifies for you its biggest impediments.  So, with that very hard part of the work, you get clear help.  It is not perfect, but it gives them responsibility and gets them engaged.  And it changes the dynamic between workers and managers.

Also, the Team quickly understands the 'social contract'.  You and the SM and the firm will help them always with the top impediment, but always despite the next 19 of the top 20 impediments, they are still expected to get serious work done.  They can complain and bitch and moan (as people always do), but some clear rules have been set.  And, generally, because the SM and you are helping with the impediments, and that is more visible, they waste less time just complaining.  And spend more time on useful work.

In some sense, most of your work now is fixing the top impediments.

8. Happiness

In general, Scrum work is more successful and the people doing it enjoy it more. (This assumes several things, but especially that they are really doing Scrum, rather than something they just call Scrum, and that they are doing it somewhat professionally.)

Once the Team jells, and you see them having more fun, and you see them being more successful, it starts a virtuous cycle. And it is fun to be part of it.  If someone has explained your new job as a manager with an Agile team.

***

To be fair, I have only explained why someone should want to be a manager with agile/scrum.  And that was the purpose of this blog post.  I have not explained how to do that job (although I did give a few hints).  A subject for another blog post.

Your comments are welcome.

EPMO for a Smaller Company

In Waterfall we might need something else, but in Agile, what do we want from an Enterprise Project Management Office (EPMO)?  If we have a relatively small company (total employees near 1,000, innovation group near 100).  (Obviously, if the company were 300,000 people, it would be a different game.)

Let me discuss this in 7 sections, as follows:

• Premises
• Goals
• Two types of work
• EPMO's role
• Information to provide
• Actions
• Concluding comments

1. Premises

In Agile, we tend to want to keep 'management' light, and an EPMO to many people does not sound light.

In the Scrum community, we are trying to move away from 'projects' and more toward thinking mainly of teams and of releases and of products.  So, we think "Team x is working on product Y and expects the next release Z to be coming out in another 5 weeks." This way of thinking typically has several implications:

• We think of customers and business value first.
• We want to release more frequently.
• The old ideas of 'project success' are meaningless.
• We expect almost all products to have a continuing series of releases.
• We look to one Team (or one scaled group) to deliver the releases for one product.  It is a real team, with a real mission, and hence, highly motivated.  And, usually, because of that, more successful.

Again, there is a sense that 'project success' (as we usually used to think of it) is meaningless.  Changing scope - so what?  Moving deadlines (as long as we are usually getting quicker releases) -- so what?  Conformance to a original schedule per se -- so what?  The only thing that matters is business success: and that happens via releases of 'product' to customers.  And the people that are clearly responsible for delivering a release are formed into a Team (or a scaled group of Teams).

2. Goals

What are we trying to accomplish through an EPMO?

The main thing is that the ET (Executive Team) knows about the efforts underway, and is able to re-evaluate them and help them.  By re-evaluate we mean they can stop them or maybe add something to them (if appropriate).  If an effort (team) is in trouble, then the ET could look into fixing the key problem or problems (in Scrum, we call these impediments).

Now, imagine you have 5 Scrum teams working.  Clearly the amount of reporting to the ET is relatively light.

So, the ET needs barely enough information to know about and act on things like the following:

1. Identify whether the initiative is going well, fairly well or not so well.
2. Review the relative benefits, costs and timelines of each release.
3. Identify and perhaps address any of the 5 top impediments. (The ET may or may not decide to help with these, for a variety of reasons).
4. See the timeline for the next release or two.  And whether that is sooner or later than previously stated.
5. Review and address any major adjustments in the scope of the release(s).  (Minor changes are outside the interest of the ET.)
6. Review and address any other major concerns (eg, budget issues, risks, future events, etc.)
7. Review and address any recommendations for action (leave it alone, fix an impediment, stop the work, etc.).  It is possible that different people might have different suggestions about this.  And the ET may need to resolve them.

Bear in mind that every ET is plagued by long discussions that often do not lead to any action.  Any EPMO activity needs to address this problem with 'committees.'  Hence, lots of information that is 'just to be discussed' is contrary to what we want.

Outcomes:

• A member of the ET may ask to get involved more.
• A member of the ET may see that his/her department may need to get involved in the future (this should have normally been identified and addressed outside any ET meeting, but the ET meeting is also a place where this might be identified).
• Address impediments.  There are many types of impediments.  One might be: Some chickens are not helping the team of pigs enough, or might cause the release to be delayed.
• Fix certain people issues.  eg, Direct that someone be added to or taken away from the Team.
• Approve or decline additional budget (or decide to cancel existing budget, ie, stop the work).
• Direct other significant course corrections. (A catch-all for special situations. We have already mentioned most significant 'course changes.')

Note: In general, we do not recommend any changes in team composition.  This is usually harmful and usually reduces team productivity.  But sometimes a set of people can be dysfunctional or can be seriously lacking in a skill set, and so some changes must be made.  We would expect these to be infrequent, and really more in the nature of 'fixing impediments'.

As implied earlier, each Team will be fixing its own impediments, to the degree it can, and should not be reliant on the ET to fix all the impediments.  Although, still, the ET can often help with some impediments.

One of the higher issues for the ET is balancing the relative priorities of one initiative against another.  And these can change from time to time, for many reasons.  Often the real issue is two efforts are contending for the same people (people that the Team wants as pigs or people that a Team wants as chickens.)  This must be resolved.

Also, note: Even a project going well could be stopped, if it has a lower ROI than a new project that those same people might work on. (Obviously, this decision would not be made lightly, and is more involved than I will discuss here.)

Key point: We need the right information to be given to the ET to enable these outcomes.

3. Two types of work

We need to divide work into 2 types: real initiatives and 'other things we are working on.'

The real problem in life is that we try to do 15 things 'at the same time', we end up doing tons of task-switching, and nothing gets finished.

So, the EPMO should only concern itself with 'real initiatives'.  If some departments want to or need to do some other minor work, that is for that department to track.  Or maybe someone else to track.  But it is not an initiative that the EPMO should track (or the ET should review).

In accordance with Lean and other sets of ideas, we strongly urge you to minimize WIP. This means, only have as many initiatives going as you have 'teams of pigs' to do them.  This will go a long way toward helping to assure that the most important business value is delivered first, and delivered more quickly.  Putting additional work in process only means that the most important things will not get done as quickly as possible, and that people will be doing (more) task-switching, which reduces their morale, their focus, and their effectiveness overall.

There may also be other kinds of work that needs to be reported to the ET.  But this work is more in the nature of BAU (business as usual), and, again, is not something that the EPMO should facilitate.

4. EPMO's Role

What is the EPMO's role?

It is only to help clarify the key information to gather, communicate those information needs, and get the information to the ET on a periodic basis.

So, for example, the EPMO should not 'own' people (well, except barely enough to manage the information flow -- if you only have 5 or 10 Scrum teams, that is maybe one person). The EPMO does not do 'real work'...it does not 'do' the projects.  One of the reasons to have an independent EPMO is that is does not have any skin in the game, and hence is more likely to be an impartial transmitter of information.

The EPMO must work with both parties (the Teams and the ET) to establish and revise the guidelines for the flow of information to the ET.  This will be an evolving discussion of what is the correct, most useful information, given the cost of gathering the information.

Why?  Because the information flow must balance the needs of the ET against the needs of the Teams.  The Teams want (and the ET wants for the Teams) minimal overhead in producing the information.  Invariably it is not really minimal. Similarly, most Teams do not see the bigger picture, and do not appreciate what information the ET needs to make appropriate decisions.  So, there is always ongoing discussion of the most effective way to get the most useful information to the ET.

Also, assuming the Teams are respected (is there any other choice?), then a member of each Team should attend the ET meeting, to assure the 'backward' flow of information from the ET to each Team.  The EPMO might take minutes of significant Team decisions made by the ET, but the flow of that information should normally be assured by attendance of a Team member.

Here we must digress and speak quickly of the eternal self-aggrandizement of any bureaucratic function. It is the nature of any bureaucracy to seem to want to become larger and make itself more important than it is.  And, in addition to the extra costs, this slows down and demoralizes the real productivity engines, the Teams.  This must be watched for.  Especially since EPMO's tend to be staffed by very bright and very articulate people, who want to feel (more) important.

5. Information to provide

What information should the Teams provide?

Notice that I did not say 'what information should the EMPO provide?'  This is because virtually all the real information comes from the Teams.  Each Team understands the meaning and the context of the information.

Certainly the EPMO can contribute a little by helping the Teams understand the information and why it is wanted, and help them in collecting it with the least effort.  The EPMO might have also a small role in making the information more 'transparent' (more accurate).

In Scrum, we stress the need for transparency.  So, much of the best information can be obtained at the main Scrum meetings (the Sprint Planning Meeting, the Daily Scrums, the Sprint Review, and the Retrospective).  If there is ever a question about whether the information given to the ET is accurate, then someone going to some of these meetings will identify whether it is (or isn't) accurate.

We obviously prefer that normal Scrum artifacts be used as much as possible.  Or other artifacts that the Team has developed for itself for its own needs.  And that these artifacts are only minimally revised (perhaps summarized) and given to the ET.

Here are some ideas about information that might be given:

1. Current Ranking of the initiative by the ET. (Is it effort number 1, or number 14?).  The Ranking was (is) based on ROI in the ET's opinion.
2. Green, yellow, red indicator for the overall initiative (in the opinion of the PO). How well is it going, overall?
3. Last release date and Next release date.  (If changed, then also the prior estimated release date.)
4. Release burndown chart
5. Velocity of team over the last 5 sprints (and sprint length)
6. Two sentences by PO on significant scope changes in the current release (adds, subtracts, etc).
7. Two sentences by PO summarizing other substantive changes in last month (a catch-all)
8. Access to Sprint burndown charts (maybe useful in discussion). (Perhaps via your Agile tool, such as Jira, Rally, Version One, etc.)
9. Expected ratio of BV to cost for the next release. (This is hard for most companies, and may take some time to implement.)
10. Happiness indicator for the Team.
11. Full Team average vote (1-5 scale) on the next release (how good do you expect it to be, considering scope, date, quality, budget, etc.).
12. Top 5 impediments
13. Two sentences by the SM about action in the last month on impediments.
14. Key risks (if anything substantial)
15. Recommendations of Team (or requests for help)
16. Recommendations of any other parties
17. Any special information for this specific initiative

These are suggestions. Different people and organizations will use others.  These should be evolving.

Usually the main criterion for including or excluding information is this question: "Will this information materially affect a key decision by the ET?"  It the information is just 'nice to have', it is probably to costly versus benefit.

It is not useful to delay implementation of an EPMO pending some committee or other set of persons deciding on the perfect set of information to provide.  In these matters 'waiting for perfection' is ill-advised, and learning from practice is strongly advised.

6. Actions

The ET will often take an action or actions during the meeting on a specific initiative.  We would normally expect these to be mainly action on assistance with impediments.  In any case, the EPMO person and the ET and the Team involved should track any actions agreed on.

Over time, there may also be discussions of and decisions on what information should come to the ET. More specifically...

• what information should no longer be provided
• what information should be provided for every initiative
• what information a specific initiative should provide.

7. Concluding comments

Finally, let us return to the initial notion.  The ET and management does not deliver customer satisfaction.  That is done, in Scrum at least, by the real Teams.  So, the role of the ET and of the EPMO is rather limited, and in the scheme of things, relatively unimportant.

This is not to say that the 'team is on its own' with no help.  And the ET can help a team, or, more accurately, direct that someone should help a team. And some real work may happen at the hands of real managers working directly with a team.  So, not all real work will be done by the Team itself.

As a consequence, let us be modest about the usefulness of too much investment in the EPMO and the value of what comes out of ET meetings.  It is useful, and we must do it, but the benefits are modest.

There is a different thing that some senior people provide that is crucial.  We often call this 'leadership.'  The leaders help articulate a vision and a mission that draws out the best in people, the best in the Teams.  It inspires them and gives them a sense of purpose.  This function of leadership is essential, and, when done well, extraordinarily important.

Some of the key values must be:

• Enable the Team to be motivated
• Get out of their way
• Do not overburden them with 'muda' (Lean term for waste)
• Help the Team

***

These are my current thoughts, expressed quickly.  Your comments are welcome.

Impediments - Charlotte

These are the impediment the group identified today.

1. Culture, company politics
2. Missed requirements
3. Team motivation
4. Competing priorities
5. Lack of mgmt support
6. Insufficient expertise
7. Not enough senior support
8. Budget constraints
9. Lack of funding
10. Undefined requirements
11. Poor planning
12. Missed stakeholders
13. Poor training
14. Resources not allowed to focus
15. Requirement clarity
16. Lack of planning
17. Change controls (lack of)
18. Team not on the same page
19. Skill set
20. Lack of resources
21. Planning
22. No fun
23. Sponsorship
24. Not clear communication
25. Scope not right sized
26. Compressed testing
27. Lack of teamwork
28. Budget
29. Lack of management
30. Lack of testing
31. Documentation not defined
32. Non-agile team member
33. Unproductive meetings
34. Too many meetings
35. No collaboration, no feedback
36. Unreasonable expectations
37. Market changes
38. Over confidence
39. Changes identified but not communicated
40. Late change requests
41. Incorrect requirements
42. Compressed timeline
43. Disagreement on "process"
44. Incorrect estimates
45. Poor communicating team members
46. Unclear acceptance criteria
47. Unclear vision of customer

As stated many other places on this blog, we hope these lists encourage you and your team and your company to aggressive identify and aggressvely attack the impediments, one at a time.  And make life better for yourself, your team and the customers.

Impediment List: Toronto

We just completed a CSM course in Toronto.

Here are the impediments they identified, although some are phrased in a positive way (but implying the lack of the positive).

This list, as with others here, supports the idea of a public impediment list.  Of course, the real issue is 'fixing impediments regularly and aggressively."  But we find that that starts with a good prioritized list of impediments.  And we attack them one impediment at a time.

Here's their list (not in order):

1. Small teams (<5 7.="" a="" amp="" and="" are="" better="" closer="" first="" for="" i="" is="" li="" notion="" person="" right="" scrum="" size="" small="" team="" teams="" that="" the="" them="" think="" this="" timelines="" to="" too="" will="" with="" work="">
2. Making time to meet
3. Changing requirements
4. Task breakdown (poor)
5. Being in the office at the same time (not)
6. Compressed timeline
7. Admitting we need agile or a Proj Mgmt solution
8. Tight timelines
9. Technical challenges
10. Lack of people with diverse and required skills
11. Waterfall/Agile hybrid
12. Lack of people for given schedule
13. Delays (outside the team that mean the team will 'fail')
14. Lack of flexibility
15. Poor communication
16. Too much planning, not enough execution
17. Old fashioned tech
18. Lack of people
19. Over budget
20. Lack of proper planning
21. Lack of approach
22. Lack customer feedback
23. Incorrect requirements delivered
24. Lack feedback
25. Lack of detail in scope or requirements
26. Lack skills
27. Too ambitious feature list
28. High level design
29. Lack of collaboration between teams
30. Poor scheduling
31. Too complex
32. Inadequate testing
33. Lack of leadership