Be careful with self-directed and self-selected teams

I believe too much power to the teams is risky in large scale agile implementations. Some of the reasons I have describe in When to use SAFe (Scaled Agile Framework).

Another aspect that concerns me is the level of self-organization.  I think too much self-organization or team autonomy might be risky.

Essentially there are three different aspects to consider; self-directed, self-selected and self-organizing. When most organizations talk about self-organization they usually mean that the team decides who in the team is going to do what and when and teams are responsible and accountable for their own work and results. The self-organizing team “commits” to a plan with the Product Owner and then it is up to them how to solve it – and initiate a new discussion when they can’t solve it. Self-selected means that the individuals in the organization choose themselves which team they will work in. Self-directed means no on else can direct the team in any sense, this usually means fewer managers or that managers no longer are leaders in the organization.

Larman and Vodde have taken self-selection and self-direction pretty far in their LeSS framework. Larman shares a story of self-selected teams in “How to form teams in large scale Scrum“.

I have some experience and thoughts around this. In one organization we had two pure feature teams. We were growing and we were not sure that three feature teams were the right way to go. So we drafted four different options that made sense and I facilitated a meeting with the teams were we looked into pros and cons with different options and also tried to figure out if there were any other ways to scale. Then the teams majority voted on their favorite option and it was decided to try it out and evaluate. It was a structure based on Requirements Areas rather than pure feature teams. On a side not, one of the options was more dynamic teams that would have made it easier (possibly) to always work on the highest priority things. This was suggested by management, but was completely killed by the teams:-) So far all is well, I am convinced this was the best choice, both for the teams and for the business. What I am saying here is that I believe self-designed (to add yet another term) can work fine most of the time.

How about self-selected then, isn’t that great? It’s just like in school when picking teams for football. I think it is empowering and refreshing – and if you are lucky it will work out great. Here’s what worries me:

  • As a manager I have on several occasions had colleagues who have wished to work with something I knew they were going to be bad at.  They have still been happy doing what they have been really good at, but if they had been given the total freedom to choose they would have chosen the thing they were not good at (and with limited potential to become good at) – which would have been painful for them, the team and for the business of the organization. And if it is major change in direction (as it has been on some occasions) you probably need to give it a year before arriving at this conclusion. As a manager you can usually handle this with coaching and helping your colleagues find their true strengths and be happy with this. Or they can try it out with limited consequences and might arrive at the right conclusion themselves. Anyway, I believe it can be handled better in one-on-one than in team sessions. And over multiple talks, rather than a rushed event.
  • On multiple occasions I have been working in organizations where some of the products would not have gotten any volunteers if everyone could choose completely by themselves. Those products are usually old, built on boring and old technology, sometimes with technical debt. And most of the time those are the products that are paying the salaries. I can think of several companies where we would have gone out of business fast if too few had selected to be on those teams. This is very common I believe. Those teams NEED to have people on them. And I believe it is better to handle this in piece and quiet in one-on-ones rather than under time pressure in a big room with all your colleagues. Of course with enthusiastic volunteers to the largest extent possible, but occasionally using other ways to convince people (I am not referring to bullying).

In general I think self-selected teams might work well if the context is right, but I advice thinking through possible scenarios and implications carefully before deciding to put this in the hands of the team. It is also very hard to go back once you have given this power to the teams. It is like taking a perk away, but it is a much, much bigger thing. Most of the time I believe the risks are higher than the potential upside.

I am also concerned with putting hiring/firing decisions within the teams as Larman and some other agile coaches are suggesting. Hiring might work out ok in some circumstances, but firing just feels wrong. It is a really major decision, it has to be worked skillfully by someone who is trained at it (or at least can get guidance). In the end it is always going to be one person who is having the talk, so why not let the manager handle that? I have a hard time picturing a team walking up to a colleague that they have worked very close with and standing in a ring and firing him/her. Larman is probably only referring to firing from the team, but that should be the same, you can’t do that as a group, it’s not healthy.

Extreme agile autonomy is a nice idea in theory, but I am afraid it wont work out in practice in many cases.  Maybe 10 years from now I will be like that guy that predicted the worlds computer market to 5 machines:-)

Agile Management

When to use SAFe (Scaled Agile Framework)

There is a huge debate in the agile community around the SAFe framework.
A lot of agilists seem to pretty much hate it.

Ken Schwaber for example: unSAFe at any speed. Ken’s main criticism seems to be that consultants and creators will make money from it through training and consulting. Completely unlike Scrum obviously.

And David Andersson, Kanban-the anti safe for almost decade already. Main criticism seems to be that it is not Kanban (the new silver bullet) and that the implementation approach is big bang.

The SAFe criticism I find most relevant and that I am commenting on in this post is:

  • SAFe uses centralized control
  • Implementation is big-bang push
  • SAFe is big and prescriptive
  • SAFe uses big batches
  • Lack of clear connection to customers and end-users

Before moving on, first a disclaimer. I have not been to any of the classes, I have only read the book and studied the website. I have not used the full framework, I have only worked with clients where we have used inspiration from it. And I have an experience where we ended up with something a bit similar to SAFe before it existed, because we needed to scale the decision making.

And before commenting on the criticism I will discuss when NOT to use SAFe and when it might be useful.

When to avoid SAFe

Scaled Agile Framework is, as you can figure out from the name, a framework to Scale agile. If you have no need to scale what you are doing, you won’t benefit from it – instead you will create a lot of waste, limit your capability to deliver value and limit your flexibility. If all you need is Scrum/Kanban, XP and Scrum of Scrums than you are well advised you stay far away from SAFe. If you are not yet doing Scrum/Kanban, XP and Scrum of Scrums it is probably better to start with that and add more complexity if/when needed.
If you have limited business and technical dependencies and coordination needs (or if we you can achieve that) you are likely much better off scaling in a way more similar to Spotify’s approach. It is a far more agile approach with decentralized decision making. At the center of the value creation we have Squads: “ideally each Squad is fully autonomous with direct contact with their stakeholders and no blocking dependencies to other Squads. Basically a mini-startup”. This is combined with: “Spotify technology is highly service oriented. We have over 100 distinct systems, and each can be maintained and deployed separately”.
At Spotify no customer is ever ordering a set of features across a number of products that needs coordinating with all other customer orders.
If it is possible to achieve this in your organization please forget you ever heard about SAFe!

When to use SAFe

If you have significant business and/or technological dependencies or coordination needs you might benefit from SAFe.  The organization does not even need to be big for this to be the case, see scaling-agile-in-small-organizations.

In a previous assignment the client had 20 teams delivering into the same product line (using configurations to deliver a family of products). They had a multitude of clients world wide and most of the time clients purchased the whole solution with some new improvements – usually based on work from most of the 20 teams.  If someone can explain to me how to make that work with fully autonomous teams and decentralized decision making I am extremely interested in listening! Please leave a comment. Or if someone can come up with a structure that is completely different from SAFe I am also all ears. Since we couldn’t figure it out they used SAFe as one of the inspirations for the set-up.

At my current assignment the situation is similar, we have 20 teams delivering into the same product portfolio. Clients are purchasing solutions which might be built from several of the products in the portfolio. The set-up here is also inspired by SAFe.

In both these cases I believe there is a continuous and large need for coordination and prioritizing across the teams – and I believe a SAFe similar approach makes sense.

Could the teams do this themselves in these situations, without a hierarchy of decision making? Maybe, if all had access to the same information and shared the same view on vision, strategy, cost of delay (which in reality are changing quite often), risks, opportunities, competition in different marketplaces, future market trends and so on. And had personal relationships with major client decision makers (one phone call can significantly change the cost of delay in 30 minutes). For the complete family of products and on all levels. Personally I have a hard time seeing this happen across 100′s of people across dozens of products or product areas that are connected into client solutions.

Comments on criticism

SAFe uses centralized control

As I have argued above on when to use SAFe (and when to stay away), I consider the need for some level of centralized control the main reason for using SAFe. Even though I consider myself an agilist I don’t consider some level of centralized control as the evil anti-thesis of agile. I consider it a necessity in many organizations. Yes, it will make us less agile, but there is a trade-off between agility and a holistic system view and sometimes the system view wins. “Optimize the whole” as we say in lean speak. The goal is to deliver as much value from the system as possible – it is not to be as agile as possible. I think some agilists have mixed this up.

If all decisions in a large interconnected system are localized we are guaranteed to sub-optimize. For a fully self-organizing system built from a network of self-organizing teams to work we have to assume that all relevant information for decision making is available at team level. You could argue that at the level above the teams it should be a team of Product Owners that are self-organizing the Program Backlog into the right order. In fact, it is pretty much the core of the set-up we have used in one of the examples I’ve mentioned. But I would argue that that is not enough in many cases. First of all – these Product Owners does not have the PO team as their first team. Their first team is the Scrum Team. Secondly, when it comes to hard priorities they are bound to have some bias towards their own teams and product. And third, in reality they can’t be everywhere at the same time. In large scale agile Product Managers are often flying all over the world meeting clients, negotiating contracts, working with marketing on setting up campaigns etc and it is impossible to both do that and be available to answer detailed questions about a small User Story for the team. Which is why they have split these roles and split the decision making in SAFe.

It makes sense to give up a bit flexibility and speed in decision making to make sure we are building the most valuable things. I think it is dangerous to only use the agile parts of our brains when thinking about large scale agile. We also need to use our knowledge and understanding of lean, systems thinking – and maybe even more importantly common sense.

In my experience the key to make centralized decision making work in an agile context is  is to have clear levels. For example, if using SAFe you end up with Product Managers who are not working closely with the teams and in collaboration with real end-users that still try to decide over every single User Story in the team backlog you will likely get into trouble. As long as the decision makers clearly stay within their level of insight and don’t try to control details they are not the one who are most familiar with it can work well. This is however a challenge, and something to keep a close eye on.

So far I have talked mainly about business control. Technical control and coordination I believe can be managed through self-organization – although it is challenging. I have experience working with three teams without an architect or overall technical decision body and that is fairly easy. But with dozens of teams and hundreds of people it is of course quite a bit of a challenge. You might not be capable to do this at the start, when the teams are not yet teams, and the organization is not yet advanced in facilitating self-organized decision meetings. But this might be a goal even if you start out the way described in SAFe.

Yet another aspect of control is around the teams and the level of self-organization they have. Essentially there are three different aspects to consider; self-directed, self-selected and self-organizing. When most organizations talk about self-organization they usually mean that the team decides who in the team is going to do what and when and teams are responsible and accountable for their own work and results. The self-organizing team “commits” to a plan with the Product Owner and then it is up to them how to solve it – and initiate a new discussion when they can’t solve it. Self-selected means that the individuals in the organization choose themselves which team they will work in. Self-directed means no on else can direct the team in any sense, this usually means fewer managers or that managers no longer are leaders in the organization.

Larman and Vodde have taken self-selection and self-direction pretty far in their LeSS framework. Larman shares a story of self-selected teams in “How to form teams in large scale Scrum“. The empowerment of these teams and the motivation you get is very powerful. I do however have some concerns and some experiences. I believe there are  risks with taking the self-organization too far. I share some of those thoughts and experiences in “Be careful with self-directed and self-selected teams“. I think that we may not know the whole story yet either, because these are fairly new experiments. I think sometimes it will work out fine and sometimes not.

Implementation is big-bang push

This seems to be David Anderson’s main concern. I agree that there are risks with doing this, but at the same time I assume that David is a lean expert and therefore very familiar with Kaikaku (radical change). Kaikaku is quite the opposite of the Kanban method which is all about Kaizen (continuous improvement). But sometimes there truly is need for radical change and if SAFe is a good fit to what your company needs right now it might be worth the risk implementing it in six months rather than starting with Kanban and wait five years for something similar to emerge. I have consistently positive experiences from use of Kanban, but system wide improvements have in general been quite slow.

Sometimes the risk of waiting is much higher than the risk of radical change. Word of advice is to consider carefully before doing a big bang push – it is guaranteed to create turmoil in the organization and take time away from the value you are delivering right now. And try really hard for a way to customize SAFe so it fits your organization and implement it in smaller pieces. I would advice against doing a full SAFe implementation in one batch.

SAFe is big and prescriptive

Based on our experiences with RUP we have learned that it is very hard to scale down from a big prescriptive process (it is scary to remove something from the process when your knowledge and experience is limited). It is easier to scale up than down – but that turns out to be quite hard as well and that is the reason SAFe exists. I consider this a major risk for ambitious SAFe implementations. Advice is to be very careful, take what you need and always look for other options as well. For example, I have experience with four different patterns for successfully scaling the Product Owner role, but SAFe offers only one pattern. It is the same with most things in SAFe, it offers one pattern when there are several other known and trusted patterns in the community. Different patterns fit different contexts. The good thing with this is of course that it makes it far easier to communicate and implement – which is probably the biggest strength with SAFe.

A piece of advice is to consider carefully if all your teams need to be included in your one-size-fits-all SAFe implementation. Even if you have coordination needs across many of the teams and products there might well be teams and products that could be allowed more agility and speed and be left outside of the centralized control. These teams could work more like lean start-ups, autonomous teams with continuous flow. Don’t smother these teams and products with SAFe!

SAFe uses big batches

In lean and agile we are generally moving towards continuous flow of value. But SAFe is built on batches on Sprint and PSI level. Personally I believe this is a good stepping stone towards increased coordination and control over the whole system in many contexts. But for the long-term you should aim towards more continuous delivery. And in the future you don’t necessarily have to connect your delivery cadence with your planning cadence when the organization becomes more advanced in agile (for example in Continuous Integration and automated testing) and ways of working.

Lack of clear connection to customers and end-users

I find SAFe quite silent on how to make sure we create the most value in the system. Looking at the division of responsibilities between Product Manager and Product Owner you get the impression that only the Product Manager is meeting customers. I think it is really hard to successfully prioritize and elaborate User Stories without some direct access to customers and end-users. Validated learning (term from Lean Start-up although the idea isn’t new) isn’t mentioned at all as far as I can see, but it is something I consider extremely important. In software development we have a history of 45 % of the features we develop that are never used. Measurements of actual usage after release are an instrumental part in finding out what is really valuable and truly easy to use. In my experience it is far from always the same thing users (a few representatives) and customers thought before the release. And that is just a small part of what we will find out when we start  measuring the usage of our products in a systematic way. Other things might be for example:

  • 90 % of the customers starting a purchase leave before finishing
  • It takes in average 12 minutes to finalize a rest order – we expected it would take 2
  • Half of our users jump several times between the settings configuration page and the user manual when changing a setting
  • After launch of “improved” image modifier usage has decreased with 40 %

Personally I believe we need access to customers, end-users and access to information on actual real usage of the system on all levels. Product Owners should probably have the most intense end-user contact and some customer (purchase decision maker) contact. Product Managers should have the most intense customer contact and some end-user contact. The rest of the team should at least occasionally get direct feedback and information from end-users. My advice is to study Lean Start-up, it’s good!

Some good parts

The overview picture – It gives a good overview and is  fairly easy to explain. If you have ever been asked “so how do we scale up and coordinate the work of all the Scrum teams then?” you have probably ended up with something similar to this picture (when the right answer clearly has not been – you don’t, you use autonomous teams working as lean start-ups).

The website – It has a lot of good content and advice which can be helpful.

The decision levels – I think the three different levels; Portfolio with Epics, Program with Features and Team with Stories are useful in many situations.

The product focus – This is a major thing that might not be instantly visible. But with SAFe comes a shift from projects to products which is hugely beneficial for many reasons. I have worked with several clients were projects have been one of biggest impediments to an agile transformation (short lived teams, date focus, lack of long term investments in competence development, technical improvements and so on). Only use projects if it truly is a project (temporary organization, unique product). The project format is usually very wasteful for continuous development of a product that already exists – and it is an effective blocker to agile transformation.

The team focus – Long lived, cross-functional teams are at the core of SAFe. This is great!

Based on Scrum and XP – If you know what you’re doing, these work really well!

Focus on Code Quality - “You can’t scale crappy code


In conclusion I think SAFe is mostly good and it certainly fills a void when it comes to advice on how to make agile work at scale. In my opinion there are no better options available at moment if you have a large, complex organization with significant coordination needs. Apply with common sense, Inspect & Adapt and don’t consider it an ideal end-state and I believe you will benefit from it.

In the future when agile and lean knowledge has more spread and understanding I can imagine that SAFe might be replaced with mature pattern catalogs where we can pick and choose patterns depending on context and needs – but I don’t think we are quite there yet.

If you don’t need it – don’t use it.


Agile Management

Scaling agile in small organizations

The organization does not have to be huge to have a need for scaled agile decision making.

A while back (before SAFe existed) I was working in a small organization (30 people, 3 Scrum teams, 2 products). We were doing Scrum and XP and one of the founders was CEO and Product Owner for one of the products and the other founder was Product Owner for the other product. The Product Owners had the full mandate to decide over their product (of course after lot’s of discussions with customers, support staff, management, developers, the other Product Owner, sales etc). We did Scrum of Scrums a couple of times but realized we didn’t really need it, the teams were collaborating as needed without it.  All was peaceful in agile land.

Then it was decided to really push and gain market shares and increase the pace. Investors and a new CEO was brought in to help make this happen. After a while it turned out that neither the CEO nor the new investors were completely happy with “I am PO, I am making all product decisions. I will listen to you and consider your opinions, but in the end it is my call”. With the pure Scrum approach both CEO and investors became stakeholders rather than decision makers. We couldn’t really blame the PO, because this was how we had designed the role. After a while we worked out some new structures. We introduced a Program Backlog with Epics that was continuously prioritized in the management team. The PO could still decide what to do in each sprint as long as the order in which Epics were delivered was aligned with the Program Backlog (normally there were no dates in the Program Backlog- we avoided dates unless they were absolutely necessary). The board of directors (representing the owners) made decisions on which markets to enter and in what order (the markets had different needs so this had an impact on the Program Backlog) and other strategic decisions. For example if we were aiming for UK before Germany, how much we should invest to enter UK and so on. To me it makes sense that the people putting their money at risk and that are majority shareholders should have an opportunity to make decisions based on risk levels, size of opportunity and so on. Some markets were obviously far smaller risk and investment – usually together with less opportunity and less visibility in the world market.

Basically what we did was to introduce a decision structure were strategical product decisions were taken by the board of directors, tactical decisions in the management team (that included the Product Owners) and operational decisions by the Product Owners. This means we had centralized decision making on two of the levels, much like the SAFe framework. The board of directors worked in a similar way to Program Portfolio Management using Investment Themes. The management team worked in a similar way as the Product Management team with a Program Backlog. The roles were different, but this is one of my experiences that makes me comfortable with some centralized control rather than fully autonomous teams – when necessary.  As you saw in the introduction we didn’t use it in the beginning – and we didn’t need it. The need arose through a new context, rather than through size increase.

This meant that we moved away from the Scrum Product Owner should have complete and solitary ROI responsibility over the product. And I am completely fine with that – it made sense then and it still makes sense.

Agile Management

Scrum Master vs Project Manager

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.


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.


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.


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.


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


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.



Agile Management

Requirements – a bad habit

Jeff Patton has written an interesting post called Requirements considered harmful to spark a discussion on the use of the word “requirements” in the software industry.

He argues that the word “requirements” leads us to the wrong behavior. There is a long tradition where we think about requirements as something that has already been decided and now the developers should just implement it and everyone will be happy.

As you know – that is not how software development works in general.

I really love the way we think about software requirements when we work with User Stories – and using the acronym INVEST as a guide. In this context the most interesting letter is the N which stands for Negotiable. That means that it is not a requirement in a traditional sense – it is still open for negotiation. And it is open for negotiation all the way until it has been developed – and approved by the Product Owner. A User Story is “a reminder to have a conversation”.

So if a software requirement really isn’t a requirement after all – maybe we ought to change what we call them to make this mindset change easier? Jeff is proposing “decision” as an alternative. I think this has the exact same problem as “requirement” – it makes it sound like the decision has already been made.

I am proposing “perceived need” instead. I think this might fit well with how we think and work with Agile Requirements – for example with the negotiations and conversations mentioned above. And with the commonly heard advice – “ask why five times”. Why do you perceive that you have a need for that? It should fit equally well for functional and non-functional needs.

Let me give you a couple of examples.

A salesperson asks for a new function to be able to sort orders. Lets say we store the request as:

“As a salesperson I want to sort orders on seller name”

If we view this as a requirement we can quickly add this to the user interface – and the person requesting it would most likely be happy with this. But then we haven’t explored the options. Lets see what happens when we add the rationale to the User Story:

“As a salesperson I want to sort orders on seller name so I can quickly find my own orders”

Maybe it turns out to be a much better solution to provide a view where you can see your own orders – or maybe not – this is why there should be a discussion.

Another example:

“As a user I need the system to be available 99,99 % of the time”

These kinds of “requirements” can often be very expensive. But when we start discussing this “perceived need” maybe we see that it is only one of the many parts of the system that has  a very critical uptime – which might make it much cheaper to implement. Or maybe when the customer understands how much it will cost with this uptime compared to 99,9 % he/she decides for the latter instead.

Most of the time there exists a multitude of optional solutions to the so called “requirements”. They all have different pros and cons and different costs and time to implement.

Maybe if we start calling them “perceived need” instead of requirements we will see more and more teams “negotiating” the so called “requirements”?

Let’s continue this discussion and see if we can get other suggestions for this!




Agile Requirements

Soft Assign in Sprint Planning

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.

Agile Management

Story Bidding

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.

Agile Management

Choosing Scrum or Kanban

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!

Agile Management

Planning Poker vs Table Sorting

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!

Agile Management

Agile documentation issues

Traditionally our main documentation issue has often been too much documentation – and being done when we have the least information (at the start of the project).

Some agile set-ups have started to have the opposite issue – not enough documentation.

There are mainly two different ways this can become a problem:

  1. insufficient of long-term documentation
  2. using too simplistic tools or models

Insufficient long-term documentation

Many agile teams think a lot on what documentation they need to support the development work. And sometimes they are very successful in reducing waste. But sometimes they forget the documentation needs for the entire product lifecycle.

This is rarely a problem in a strong team that is fairly static (same members). And by strong meaning that they use practices like Collective Code Ownership and are communicating well etc.

But if the team is not so strong, for example have very high dependencies on key persons or are not communicating well, lack of product documentation can be an issue.

It can also be an issue when the team is not static, if you for some reason need to move people between different products or you have hand-overs between different teams (yes, hand-overs are in general bad – but sometimes they can not be avoided).

The advice is to explicitly discuss both short-term and long-term needs when deciding on way of working and which documents, models and tools to use. But when doing this we should of course still keep in mind how much useless documentation we have produced in the past – and not make the same mistakes again.

Using too simplistic tools or models

Sometimes we get so enchanted by all wonderful agile things that we stop thinking about other options. Let’s say for example you are developing functionality in a complex system that is complex, involves interactions with several other systems, have a lot of different flows and rules. You’re trying to break things down into User Stories because that is the way you have been accustomed to work. But after a while you realize that you are having the same conversations over and over again and you realize that you are losing the big picture of the flow. Then you do a traditional Use Case and all of a sudden it feels so much easier to grasp (been in exactly this situation).

Sometime the simples thing that could possibly work is not the most efficient and I believe that some of the stuff we have done traditionally have a lot merit in certain situations – and we should not throw all the things we’ve learned over that last decade out the window just because agile is so hyped.

Agile Development, Agile Management, Agile Requirements