Agile Management

Many companies have  decided to keep the Project Manager role more or less intact while adding the new role of Scrum Master.

Is this good? Is this what the founders of Scrum intended?

In general I think the answer is no and I will elaborate a bit on why I think so. But first of all, let’s go back to the source. A lot of the discussions on this topic seems to come down to something like “Scrum is not mentioning the Project Manager – and we obviously need that role. So we just added the Scrum Master to what we had”. But I remember quite clearly that Jeff and Ken are saying that they named the Scrum Master role with a completely new name to make it very clear to everyone how different the role is from the traditional Project Manager role – not with the intention of keeping both roles! Some of the traditional Project Manager responsibilities goes to the Product Owner and a lot goes to the team. And some is scrapped. In this blog post, Agility and PMI, Ken says “In Scrum, we have removed the project manager”. Quite clear if you ask me.

Some of the reasons I think it can be challenging and bad to have both roles are:

• Overlap between the roles
• Conflict between the roles
• Communication and synchronization issues
• Waste
• Status

Of course we can still have one person playing both roles in which case the above is not applying.

Overlap

There must be some overlap when you have both a Project Manager and a Scrum Master. For example, if the project is risky (and they tend to be when we use Scrum) – who will facilitate a risk analysis workshop?

Some would answer that risk analysis is not mentioned in Scrum so either you don’t do it anymore – or it clearly goes to the Project Manager because they have that in their responsibilities and toolbox. Personally I think that Scrum is not telling you everything you need to know or do – it is just a very simple framework to help you get started. But if a risk analysis workshop is something that will be valuable for the team – then of course you can facilitate one as a Scrum Master.

Conflict

If the Scrum Master and the Project Manager is not agreeing on something who will decide? If the answer is the Project Manager you can forget Scrum and ideas of a self-organizing team.

Unfortunately there often tends to be conflict in organizations that has chosen this path – since the Project Managers might still be stuck in a much more traditional view of projects.

Communication and synchronization

Even if we have a happy couple of Project Manager and Scrum Master who are working well together – they will still have an issue with lots of communication and synchronization to deal with. Which is always introducing a risk of misunderstandings.

Waste

One of the ideas behind lean, agile and Scrum is to reduce waste. To make as large part as possible of the work to be value adding. It is very hard to see how adding yet another role can help accomplishing this. Especially since a large part  of the former work of Project Managers are taken over by the team, the Scrum Master or the Product Owner.

Status

In many organizations the Project Manager position is a high status role for senior persons. Sometimes they add the Scrum Master role seen as a less senior position. The situation that arise when a senior Project Manager is appointing a Scrum Master to do the “dirty work” because he or she don’t want to lower their status can never be healthy.

Arguments for needing the Project Manager is commonly that the Project Manager has broader responsibilities than the Scrum Master. Let’s look at some of the more frequently mentioned additional responsibilities:

• Procurement
• High-level plans
• Hiring / firing
• Contracts and budgets

Procurement

Ok, so we need to buy something within the project.

First of all – if the need to buy something is for the product – then the overall responsibility should go to the Product Manager if you ask me. Of course they will often delegate more technical stuff like for example a new server. But the purchasing decision should go to them. And they may well delegate the purchase to the team who can self-organize on who will do what part of the purchasing process.

If the purchase is needed for the project and not for the product the situation becomes more fuzzy. But in many cases the decision goes to a line manager.

High-level plans

A common argument is that the Scrum Master is only concerned with the current sprint (and possible preparing the next) so we need a Project Manager to look at the big picture.

I don’t agree with this, if there is a need to plan more than one sprint ahead of course we will do that. For example, if you have a release every three months and you need to have a good idea on what you will deliver the Scrum Master will facilitate release planning together with the team – in a very similar way to sprint planning.

Hiring / firing

I think (at least when it comes to Software development organizations in Sweden) it is rarely the case that the Project Manager role makes hiring / firing decisions. There is usually a line manager who has that responsibility.

So if this comes down to bringing on / off people on the team, the question is if a Scrum Master who knows the inside out of the current team with their strengths and weaknesses or a more outward facing Project Manager will be the best person to facilitate this?

Contracts and budget

Of course someone needs to work with this – and to make sure budgets are not overrun. But how we ideally want to form contracts and work with budgets are completely turned around from what traditional project managers are used to.

The handling of this in a traditional way is often a key reason why projects can not become agile – it was prohibited already when budget and contracting was made.

To sum this post up, I believe that in general it is better to stick with the intention of getting rid of Project Manager as a role (Project Manager can of course switch to being Scrum Masters instead). And expand the responsibilities of the Scrum Master (if it is necessary to having everything written down).
Things may occasionally make this complicated. For example it is much easier to do for internal development than for a company working with external customers.

This post is mainly considering the fairly simple set-up when there is only one team. In a large project with multiple teams the Scrum of Scrum Master will often not be able to be Scrum Master in any of the teams. Then that person’s responsibilities are closer to a part of what a traditional Project Manager does. In that setting it could make sense to call that role Project Manager.

Another option could be to only call things projects when there is value in following an Agile Project Control Model. And in that case we would have far fewer projects – and only when things are really tricky. Then we could have Project Mangers lead those initiatives – usually with the help of multiple Scrum Teams and Scrum Masters. But there might be a danger in having a role that has some kind of self-interest in making things more difficult and complex than they might be just to  have work to do.

In teams that are still bit too specialized it can sometimes make sense to do something I call Soft Assign.

Soft Assign (as I have defined it in this context – it has other meanings as well) means that in the first part of Sprint Planning members of the team show what Backlog items they will be able to work efficiently on. For example by putting markers or initials on those items.

This help you re-prioritize a bit so that you can make the most efficient use of the team skills by making sure that everyone has enough items they can work efficiently on.

I completely agree with the ones of you who are now protesting, saying that this will prolong the time it takes to create a truly efficient team that works really well together.

However, I am a fairly pragmatic Agile Coach meaning that I firmly believe that sometimes short-term results are more important than agile doctrines.

Growing a strong cross-functional team with little dependency on key people for certain tasks or areas of the system is certainly a good long term goal.
But sometimes keeping a promised release date or making it possible to bring that new customer on board will be way more important than taking a small step towards that long term goal.

Soft Assign can help a team perform at it’s best short-term.

Just be careful so this does not become the standard way of working. If everything is super-urgent all the time – then you have an issue that needs to be resolved.

I recently met a fellow Agile Coach. He had invented an elaborate way of bidding on tasks in a sprint as a way of matching what people wanted to do with what got assigned. It was Excel based and could find an optimal solution (more or less I guess) based on an algorithm. It worked really well for them.

That sounded really interesting!

However, I prefer to not have all tasks allocated after Sprint Planning since it makes self-organization and team yell much harder.

But I like the basic idea that you should try to match peoples preferences to what they are actually working on. And doing standard self-assign in a stand-up meeting might not fully solve this. Maybe not even over time as you get to know each other better. Some people might be doing things they are very bored by out of duty to the team and never even say something about it. If you are not keeping the priority from the Product Backlog when you create your Sprint Backlog this might be less of an issue because then people won’t be questioned in the same way when they pick lower priority things because they like to do them. But on the other hand, then you increase risk of missing Sprint Goals or risk delivering less important stuff in a Sprint if you don’t manage to get it all done.

I really like the idea of explicitly discussing our preferences in the team (and keep priorities from Product Backlog) so that we can do our best to let people work on things they prefer.

Here is a simplistic way of getting at least some of that info out without spending too much time or interfering with other parts of the process.

Story Bidding

• In Sprint Planning each team member is allowed two votes
• One vote is positive, one vote is negative
• After the Sprint Backlog has been decided each team member mark their bids on stories.
• In daily meeting it can be acceptable by the team that you are picking something that is not the highest priority thing you are capable of doing

Your marks could for example be small colored stick notes where team member put their initials. For example green for preferred things and red for things you’d rather don’t do. In general I think it is better to put votes on stories rather than on tasks. If tasks are maximum size of 1-2 days you should be ok with that. Putting bids on stories rather than tasks might also decrease the risk that some people are unable to do tasks (that they could otherwise easily learn). This risk is also a reason for not having too many votes.

Be careful though so this doesn’t completely override the priorities in the Sprint or the Sprint Goal. And also be careful so you don’t end up with too few people with knowledge in certain areas – try sticking with Collective Code Ownership and other agile ideas.

Used in a balanced way with help of common sense I think this really helps the team enjoy the work without loosing sight of what is most important to the business.

Many teams start out with Scrum and over the years they remove stuff – and add WIP limits – and come closer and closer to Kanban.

Many teams start out with Kanban and over the time add things like Sprints and Retrospectives and come closer and closer to Scrum.

This is all fine and a sign that teams are adapting their way of working to their needs.

But teams that are starting out – what should they begin with?

One way of looking at it might be to say that if it is difficult (or wasteful) with:

• Dedicated resources – more or less full-time
• Work in Sprints that are more or less predictable
• Cross-functional teams
• Self-organizing teams

… then Kanban might be a better choice because it will be difficult for Scrum to work properly.

However, while this could be somewhat helpful, I don’t think it is the right way of thinking. You first need to ask yourself WHY these things are difficult.

For example:

WHY is it difficult to get dedicated resources on the team? Are people being spread out too thinly? Do we have too many things going on at the same time that are seriously hampering our flow? Are people too specialized and hence need to be on multiple teams? What is the true cost of task switching? Etc, etc. Similar questions concerning cross-functional teams.

WHY is it hard to work in sprints that are more or less predictable (remember that it is perfectly fine to allocate e.g. 25 % of the time in the sprint to urgent bug fixes and support – at least if you ask me)? Is it because the Product Owner changes his/her mind all the time? Could it be a better option to have a dedicated support team? Is it because we release too many bugs into production. Etc, etc.

WHY is it hard to get a self-organizing team? Is it because they have become so used to someone always telling them what to do that they have stopped thinking for themselves? Or because they have gotten punished when they have experimented and made a mistake? Etc etc.

I do recommend that you consider questions like this before making a choice between Scrum and Kanban.

But I believe there is a more fundamental question that should guide us in the choice with how we start-up. What you really need to consider is this:

• Is our main need improved communication or
• Is our main need improved flow

When your main need is communication you can benefit tremendously from all the additional team practices that are part of Scrum.

When your main need is flow the additional Scrum practices might be a waste of time.

But what if you are on a super-urgent project and it is extremely important to get things out really fast?
Then you need to ask yourself if you really will deliver the right things, in the right way, at the right level of quality if you communicate less (less built in team communication in Kanban than in Scrum).

Bare in mind that the root courses of troubled projects are almost always related to communication and cooperation. If you read reports on failed IT-projects you will see the same things over and over again. When I coach and train teams and we talk about reasons for challenges and failures I hear the same things over and over and over again. Things like for example:

• The requirements were poorly understood
• The stakeholders expectations were not aligned with each other or with reality
• Scope changes were poorly handled
• We had unrealistic plans (and we knew it)
• The plans were poorly communicated
• … and the list goes on

Now, you can make the choice even easier by saying “let’s use Scrum for projects and Kanban for  maintenance”. You probably wouldn’t get too far from the mark with this simplistic approach. But what is a project really in this day and time? What is maintenance? Where do we draw the line? And couldn’t it be the case that to some maintenance teams Scrum would be a great fit. And to some projects Kanban would be perfect?
I think so.

That’s why I stick with:

Communication   /   Flow
Scrum                     /    Kanban

As a starting point. Not black and white. Not cut in stone.

And remember that Inspect and Adapt and Continuous Improvement are equally fundamental to both methods!

Many agile teams have discovered Planning Poker, which is a well known and proven practice.

But there is an interesting alternative to Planning Poker that can work very well under certain conditions. I call it Table Sorting (don’t know the official name – and I am not the inventor).

Table Sorting works like this:

• Prepare items on paper (or similar).
• Put items on table so that they are all readable.
• Team stand around table so everyone can read and move items.
• Explain the mechanism behind Table Sorting.
• Everyone moves items to where they think they belong in a sorted order. This is done in silence.
• Put a token on items that are moving back and forth.
• When all items have stopped moving, discuss the items with a token on them and try to agree on where to put them – after more information has been exchanged (just like in Planning Poker).

After this exercise you should have a team agreement on the sorting. I have done this for sorting both on relative size and on relative business value and it has worked really good. You should of course by able to do team-based sorting on any parameter using this method.

Sometimes you also might want to add an additional step by sorting into groups (columns) and put a number on them. For example if you are using Story Points for relative size.

Table Sorting is much faster than Planning Poker since there is less discussion and many items are moving simultaneously. That is both the strength and the weakness of the method. When there is good common knowledge and agreement in the team the discussions might not be needed – and you focus the discussions on the items where you really need them. But you always risk missing out on a discussion that was needed if you use Table Sorting.

So my advice is to try out Table Sorting if have a lot of items that need sorting and you are fairly sure the risk of missing important discussions is small.

If you have new members on the team or if knowledge is not well spread among all team members you should be really careful using the method. It might result in a few people who have the most knowledge that are the ones who are active and some people will be more or less excluded from the teamwork. Not good!

Is the concept of projects dead in agile? Does it matter?

In Scrum they say that each sprint can be seen as a project – but that’s not what we normally mean with a project.

Personally I don’t really care if we call our development efforts project or not. As long as we make use of “traditional” project management practices like for example Risk Management, Stakeholder Analysis, Communication Management and looking further ahead than one sprint – when it adds value (not otherwise).

A more interesting topic is the use of Control Models in agile settings (which is often related to if you define the work as a project or not – because projects are often mandated to use the Project Control Model).

Can traditional Project Control Models (stage-gate, phase-gate or whatever you prefer to call it) work in agile settings?

The short answer is yes, but they have to be used in the right way. They are frequently a source of lots of discussions and can also frequently cause a lot of trouble for organizations transitioning to agile.

First of all, control models need to be adapted to iterative and agile ways of working. This means you will ask for different kind of results at the different gates. This can usually make sense, especially when you consider what the underlying purpose is with the different gates. Lets take an example with a couple of gates:

• Verify business feasibility – will normally require no change.
• Verify technical solution and feasibility – will more often demand that you have verified by setting up or coding parts of the solution, but in many projects this might not be necessary to take the right decision.
• Scaling up and final development – here the major risks should normally be under control. Traditionally this was taken care of by writing lots of documents. Experience has shown that this is usually not the best way of mitigating risks so in all but really simple projects you have to build parts of the application to be allowed to pass this gate in an agile and iterative setting.

Interesting to notice is that, according to me, agile ways of working is actually a much more natural way of fulfilling the purpose of the gates. Do you believe writing comprehensive design documents of the entire solution is a better way of reducing severe technical risk than developing code – if you have to choose between the two? The same example goes for user experience.

Let’s take a step back now and discuss the purpose of a control model. The major purpose is to control the projects to be able to manage risks and make it possible to stop projects in an early phase if the are not under good control. It sounds like this makes sense in an agile setting as well.

In Scrum each sprint can be seen as a mini-project. But this is not what we traditionally mean with a project. Many companies have projects that run for many months or even years.

Is agile the end of this? I say no and I believe there is significant risk in not accepting the need for Project Control Models in agile environments.

Why? Let’s examine this need by looking at the practices of Project Control and Portfolio Management used by many large organizations. Portfolio Management Models normally get their information by being fed with data from the Project Control Model.

The purpose with using Project Control Models and Portfolio Management Models is:

• To be able to quit or redirect projects that are not performing as expected
• To compare and prioritize versus other projects
• To control the risk of the projects

It is not (or should not be) to control the people doing the work (whom we don’t trust).

So when there is a significant need to control the development of a project by people other than the Product Owner it could make sense to use a Control Model.

Now, I am talking about other decision than prioritizing of the Product Backlog – that can well be handled by the Product Owner – at least if you consider these Product Owner issues.

I am talking about decisions like:

• Project cancellation – it might be tough for a Product Owner to terminate a project developing his only product (might potentially make him redundant).
• Resource reallocation, moving a lot of resources to another project – same as above

Of course you can make decisions without using Project Control Models – but sometimes they can support in situations like these. If you have a common view on the maturity level of the project and a way to compare business cases and risks it can help a lot.

The following are examples of projects that will often likely benefit from a control model. Assuming we are talking about projects with significant complexity and risk and within an organization with many ongoing projects:

• New product development
• Bought product implementation in organization
• Complete rewrite of existing application

So using a Project Control Model might be helpful in agile settings. It supports us in making good decisions on a level above the individual project. Scrum support us really well in working with and prioritizing a single backlog – but Scrum does not really help us with decisions on the level above that.

That being said, using Project Control models are probably just adding waste a lot more often then they add value. If your project and organization is not fitting to the description above you should carefully consider if you are not better of without it.