Why don’t developers water the plants?

Bike-shedding, Bystanders and Boredom:

I have a theory that in the context of self-organizing teams in a business environment, there are zones of diminishing responsibility and thus the effectiveness of self organization as the tasks get further from the perceived core purpose of the team or individual.

That is to say that a self-organizing software development team may have little difficulty organizing how to create a feature in their product, but may struggle to water the plants or empty the bins in their Team area.

Background

We as an organization have embraced Spontaneous Order (self-organizing teams) and have adopted a variety of Holocracy, the result is a pretty large organization (Approximately 400+ people) with almost no management outside of the core leadership team of four. The results are fascinating to observe, in some cases wildly successful and in other cases not so much.

Teams are created for a defined purpose, most often this is a defined project from a client, the composition of the team is decided by one of the leadership team based on personal knowledge of the skills of the prospective team members. This is obviously a limitation of scale and requires an exceptional level of knowledge of the available people. Clearly it is not self-organization in the context of team creation but this is the extent of outside influence for most teams (unless they have problems). The teams are expected to self-organize to deliver on their defined purpose.

Defined Purpose

For the most part they do very well and are able to deliver high quality software, interact effectively with clients and have a reputation for being the best in the custom App development business. Although there are a few internal difficulties, such as a tendency for excessive bike-shedding* early in projects, and for a few individuals, especially the stronger personalities to shape the teams to enable them to do the work they like relying on the others to do the rest.

Similarly strong personalities can limit a notion of continual improvement, that is to say that strong personalities can instill pressure to stick with what worked previously rather than being open to improvement.

Those are problems that could be explored further but for today my interest is in observing how wider organizational responsibilities or team responsibilities that are perceived as distant from the defined purpose get lost, ignored or simply take far longer than they should to get done.

*Bike-shedding (or Parkinson’s law of triviality)

Way back in 1957 Parkinson observed that members of an organization give excess weight to trivial issues, spending a disproportionate amount of time discussing issues that everyone has an opinion on (in his example it was the the building of a bike shed), this discussion was at the expense of more important issues that were outside the domain of expertise of the entire group. In other words people contribute because they ‘can’ not because they ‘should’.

In my observations this is a MAJOR problem for self-organizing teams, the choice of electronic Kanban board is my favourite pet hate on this, the amount of time spent deciding on which tool to use or which columns to include, or future discussions about whether to add or remove a column is astonishing, these same teams will spend hours on these topics but will then declare a story writing activity unproductive if the quantity of stories written in an hour is below an arbitrary number, regardless of whether the discussion was effective in identifying details valuable to getting a feature right. Please note I am not suggesting that the decisions about tools or workflow are not important, just that it should be proportionate.

To remedy this self-organization may need a helping hand, a facilitator to keep the group focused, or to redirect in the face of bike-shedding.

Structure vs Empowerment

I often hear people talk about not wanting a framework imposed on them (e.g. Scrum) or “wanting to find their own way”. But in my observations many do find themselves with a workflow that would be described as Scrum to an outside observer. The concern I have with this is balancing the freedom to find your own path – allowing teams choose their path, balanced with the waste involved in teams repeatedly churning for weeks on end or longer until they find the path which is ultimately very similar to what would have been prescribed in the first place. Is it wrong to build on past experience by suggesting a proposed framework structure? Is it empowering to allow teams to repeatedly re-invent the wheel? I am oft told that it is empowering for them, but I wonder if they would feel the same way if they were paying the bills?

This applies to other parts of the organization too, it is all very well when entering a restaurant to be offered no menu and told to order anything you want. But when faced with that how many would feel imprisoned by too many unclear options, how many would rather have a menu and feel empowered to stretch it a little asking for tweaks or combinations, in other words having boundaries that can be pushed.

Observations of children playing show that if a play area has a fence they utilize the whole area, but when the play area has no fence the children cluster close to the center with each other. In our subconscious we are more daunted by the lack of boundaries, but when we have them and feel safe and empowered we will push at them.

In retail, studies show that customers faced with 6 choices are 15 times more likely to make a purchase than those with 24 choices, too many choices confuse and frustrate us and so we regress to safety which is to NOT make a decision. The same is true in our business life, we become overwhelmed with choice, constraining options is empowering not limiting.

The three layers of self-organization responsibilities

The teams will generally have activities and responsibilities fall into three camps, either trivial issues get blown up in to long and largely pointless debates that drag on, more complex issues get glossed over leading to problems later and finally there are certain responsibilities that get overlooked or dismissed as unimportant or out of scope of the team.

Primary Tasks

These are tasks that are clearly and directly related to your role on a team and directly related to achieving your team’s goals and objectives. In the case of a developer this may be writing code for specific user stories. Please bear in mind that a named role such as Developer or Quality Advocate or even Product Owner may imply certain responsibilities are theirs rather than the team as a whole (I am observing this not endorsing this)

Secondary Tasks

These are the tasks that the team are responsible for but may not be perceived as core for the individual, again in the developer’s case this could include organising meetings, testing or writing stories or deploying or… well you get the idea.

Tertiary Tasks

These are tasks that need doing and are essential to the function of an organisation but are outside the explicit responsibility of the team such as: emptying bins, washing dishes, watering plants. Or less trivially ordering stationery, updating company web pages, ordering IT equipment and so on.

Exceptions: There seem to be two exceptions to these layers, the first is if a task in any of the layers is perceived by the individual as interesting or rewarding in some way, in which case the layers can be overcome, the other is when someone of authority (including peer pressure) explicitly assigns responsibility to an individual or small group which elevates the task to a Primary task.

Bystander Syndrome

Bystander syndrome is a phenomenon of anthropology where the more people are responsible for something the less responsible the individual feels. Sadly this syndrome is the reason that self-organization so often fails. Why in small teams or small companies things work well but as they grow this attitude slowly creeps in until one day there is a pile of dirty dishes in the sink, un-emptied bins, and someone has stolen my chair because their’s is broken and it was quicker to take mine than order a new one*. (*imaginary scenario – honest)

These minor annoyances are the start of the breakdown in your corporate society and the warning signs that self-organization has reached it’s limit. To keep things running new roles will need to be created to make people explicitly responsible for these Tertiary tasks. In short you will no longer be self-organizing someone will need to lend a discrete hand, to enable self-organization to continue where it really matters.

Summary

Essentially these are growing pains, the result is what can be best described as a failing of human nature. The tasks that get the most effort and attention are those that fall in the sweet spot of being close to the core purpose of the team, are trivial so that everyone has an opinion, and are interesting or appealing or have clear ownership. The tasks that get ignored and overlooked are those that whilst important or necessary in the grand scheme do not map directly to the core purpose of the individual, are uninteresting, or have no clear owner. For these self-organization wont save you, a helping hand (or a gentle prod) is needed.

Providing self-organizing teams and people with boundaries and structure and for our leadership to have an understanding and acceptance that we thrive best when we know our boundaries makes for a safe environment to grow. We will push at those boundaries mercilessly if we feel safe. But don’t be surprised if the plants don’t get watered unless you assign the job explicitly!

It is all in the follow through…

Accountability of others

Holding another person accountable can be a scary thing, even just saying that sounds a big deal. And whilst it is a big deal, it doesn’t need to be scary. Feedback is a skill, and it one that you get much better at the more you practice.

In theory feedback in the context of accountability should be the easiest kind. Your work colleague or partner has made a commitment to you or to the team and in doing so they are implicitly inviting you to give them feedback if they stray from this commitment. Learning to give that feedback constructively and supportively comes with practice, and frequency. If you are giving feedback regularly it is easier to give and easier to receive, eventually it will become a normal and natural interaction on a team.

If they took an action item to do something by the end of the week a polite enquiry on their progress, may serve as a reminder that the task is important and that they have committed to it. There is no need for judgement or pressure and certainly no need to micro-manage. An offer to help or an enquiry if there are any impediments you should be aware of, or can assist with, should be sufficient to reassert the importance of the task and a reminder of the commitment made.

In most cases if someone has taken responsibility and committed to something, they will be happy to be held accountable, especially if you have established trust on the team and have decided as a group this is something important, a good team player understands that group decisions impact all of us and are in all our interests to get it done, so understand and expect you to have an interest in getting it done.

Holding yourself accountable

Holding yourself accountable is much harder, after all if we could see we were slipping we’d do something about it. Which is why it is so important to explicitly ask others to help you with this or to find techniques to help you stay focused on what is important.

Accountability techniques

There are a couple of very easy techniques for creating opportunities for holding each other accountable. If done right these should lead to more frequent feedback, if they become a constraint and feedback becomes limited to these opportunities then try something new.

A regular stand-up meeting

Get together with your team on a regular basis, a lot of teams find once a day is a good cadence, review priorities, objectives and actions, by sharing what you are working on and where you need help you are inviting input from others, if an action item is being neglected this is an opportunity to ask why or to remind others of the importance of it. Be careful this does not become reporting to someone, this is about sharing information and looking for opportunities to assist each other.

Make your work visible

Something like a Kanban board or a todo list is fantastic for sharing with your team mates what you are working on, you and they can immediately see if an action is not being given priority and can see why or what is. If Kanban is used then priorities of work are clear and your policies are explicit, everyone is clear just by looking, what is going on. The key to maximising the value of this is by ensuring it is used correctly, all tasks are on the board and you follow the rules, ambiguity can ruin this technique.

If combined with a stand-up it can enhance the effectiveness of both techniques. Also whilst Kanban boards are great for team working, they also work well for an individual, many people find a personal Kanban board is a great way of keeping focused on what is important and avoids getting distracted by less important interruptions. and having it visible in a public space too will aid you holding yourself accountable to it.

Always review previous actions

At the start of a team meeting it is important to review the previous action items, and to not lose sight of any that remain outstanding. First the team should be focused on the most important issues, and actions should be the team’s collective view on how best to proceed. If as a team you don’t care enough to want to know how those actions turned out, you have to question your buy-in to those desicions or if your team is actually focused on the right priorities.

Was the purpose achieved?

Remember the reason for the Action item. I would also suggest that an action is the result of a discussion about resolving a problem, satisfying a need, or is progress towards a goal.
Taking some time not only to review whether the action was taken, but also to review whether it achieved it’s purpose would be valuable. It is quite common for an action to not have the expected results, and in that case the underlying issue still needs addressing.

Summary

Accountability should become routine, and we can all benefit from being held accountable. If it doesn’t become easier or routine then perhaps there are other underlying problems either with trust on the team or a lack of genuine commitment to decisions.

Are you ready for the fallout?

There is an old saying – An Agile Transformation is easy, you only have to change two things: Everything you say, and everything you do.

But actually, as obvious as that joke was, it is also wrong. You only need to change one thing, you need to change the way you think.

Project or Product

It is my premise that when we talk about Agile Transformation what we mean is transforming our thinking from considering our deliveries in terms of ‘Projects‘ to thinking in terms of ‘Products‘. And transforming from measuring people in terms of their effort, to measuring them in terms of their collective contribution to a shared goal (the value they add).

Project : an individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim.

Product: an article that is created or refined to satisfy a need.

As we have all discovered, software product development is complex, both in the development itself where we face a host of unpredictable variables, complications and unknowns. But, more significantly, it is very difficult to know what you want until you see it and consequently there are an abundance of quality software products that do not effectively fulfil the need that triggered their commission.

We have learned that reviewing progress regularly with stakeholders and modifying based on that feedback is far more likely to result in a successful product.

In most cases is is a fallacy to believe that for a complex and bespoke software solution you can know your end state before you begin, regardless of how well you analyse. And no matter how good at planning you are if you don’t know the end state your plan is flawed, and as you cannot predict the unknown even the best plans are unreliable.

We have come to realise that bespoke software delivery is far more akin to product design and development than it is to project delivery.

Management is doing things right; leadership is doing the right things.

Peter Drucker.

Agile Transformation is about moving from Management to Leadership

Peter Drucker is an inspiration here, traditionally we put so much effort into getting things right, to be more efficient, or to do this, by that deadline. That we forgot to ask if what we were doing was bringing value. We put all our emphasis on measuring and monitoring effort, or efficiency, rather than assessing if we are achieving our goal.

If you are considering an Agile Transformation it is likely that you have discovered that efforts to ‘manage‘ projects is leading to the wrong results and the focus needs to move from a focus on effort to a focus on value. To set a direction and ‘lead‘ the way in product development. Try to stop measuring output and to start measuring outcomes.

Impact on Project Managers and Business Analysts

But this is a major cultural change for many companies and not an easy one. It is a complete shift in perspective, moving from planning the delivery of a project to collaborating on the creation of a product.

It is particularly difficult for Project Managers.

For project management to be effective the end state needs to be [largely] known, and for the steps to get there to be familiar and [largely] predictable. With a known end state and predictable building steps, a Project Manager can effectively work towards that aim.

But bespoke software is far more complex and is generally dealing with many unpredictable variables, the biggest variable being the end state. In the majority of cases the end state is not known at the outset and emerges in the course of the product being developed. The true end state needed to fulfil a need or want can very often be significantly larger or smaller than initially anticipated. The ability and flexibility to pivot based on emerging information is crucial for delivering value and the product being a success.

Business Analysts similarly must adapt, project planning generally relies on a knowing as much as possible at the time of planning, and so there is heavy reliance on the Business Analyst. Product Development is again a mindshift for a Business Analyst, there is no longer a need for detail up front, in fact in most cases it is a waste due to the likely and frequent change of direction and priority as we learn so much as the product emerges.

Business analysis in an agile software product development means an early assessment generally at a high level is all that is needed, with detailed analysis happening much closer to when the work is done, at this point much more is know about what is actually needed and so we are not wasting time analysing something that will not be done.

An Agile Mindset

Agile is a mindset far more than anything else, and when you start to look into it, there is nothing new, nothing original, and you will be surprised to find that whilst the word Agile has been used a lot by the software industry in the last 20 years or so, the practices and behaviours are just the good practices and behaviours of general management going back a century and possibly even a millennium or two.

‘Agile’ as we have come to know it whether we mean Scrum, Kanban, Lean, Lean Start-up, or any of the many other Agile frameworks is, in most cases a collection of historic good practices and guidelines identified by successful leaders and businesses in the past, they have been collected under one umbrella polished up a bit and marketed – very successfully – which is likely why you are reading this. I say this to discourage the notion that ‘Agile’ is new and untested, there are certainly some misinterpretations and misapplications but the underlying principles are sound and based on a lot of experience.

Just as an observation, if you looked back at the early days of the Ford motor company as an example from over 100 years ago, and you assessed them against modern standards of agile my guess is that they would hold up very well.

Agile Transformation should not be your objective

Agile Transformation is often presented as the objective, when in reality it should be a strategy to reach a goal. Taking some time understanding what your goal really is, will make any transformation far more likely to succeed.

Are your customers dissatisfied?
Are your products missing the mark?
Do you(or your clients) feel you are not getting value for money?
Are you slow to market?
If you are creating software products for internal teams are they not having the impact you expected?
Are people circumventing your tools?
Is your ROI on software development too low?
Are you losing key development staff?
Is there a lack of transparency in the software development process.

These are just a few of the many reasons a company may want to undergo an Agile Transformation, they are all global business issues, and that is a key point: Agile Transformation is not an initiative just of the software department, it is a change for the entire business. It is a major cultural change that will impact your business from top to bottom. From the way you sell your products, to the way you hire staff, and particularly to the way you measure success.

Unless commitment is made, there are only promises and hopes

This is the third post on the theme, the five dysfunctions of a team.

The first two are available here:

With a natural or assigned Maverick on our team and a level of vulnerability and trust we reach the point where actual decisions can be made. Up until now we could consider the efforts to build the team to be the foundation, but now we have to put it in to practice.

This is also the point when it starts to hurt, this is where it really tests whether you truly have trust and are truly open to input and discussion and healthy conflict. Many teams say they have built trust, and many teams seem to have open discussion and healthy conflict, but this is where you test that.

Can you make a decision and follow through on it?

Consensus

Please do not confuse decision making with getting consensus. The goal of a team is not to please everyone on the team, it is to get things done, to make decisions that help us – for the team reach our team goals. If we waste time trying to please everyone we end up either paralyzed, or with a watered down decision that accommodates everyone but satisfies no one.

“Consensus is horrible. I mean, if everyone really agrees on something and consensus comes about quickly and naturally, well that’s terrific. But that isn’t how it usually works, and so consensus becomes an attempt to please everyone.”

Patrick Lencioni

The funny thing is that most of us do not want consensus, nor do we always want to be agreed with. Most of us are not unhappy when a decision is made just because we disagree with it, but we are very unhappy when our opinions and concerns are avoided; ignored; overlooked; or given only lip-service.

I want to feel valued

If I feel that my input is valued; listened to; if my concerns are discussed fairly and sensibly but the decision is made to proceed despite my concerns, then I can still buy in to that decision and crucially I can support it.

But if the decision gets made without me, or my input is so obviously not going to be given a fair hearing, then two things happen, first it won’t get my support, or my support will be shallow and half-hearted. Second, why would I speak up next time? We will just regress to a lack of healthy conflict.

It should be simple, if someone is on the team then their opinion counts, otherwise they should not be on the team. If you cannot accept that, then perhaps you should not be on the team. Being a part of a team has an implicit commitment to value each other.

Unless commitment is made, there are only promises and hopes… but no plans.

Turn decisions in to plans

Getting to a decision is not enough, you need to turn those decisions in to plans and you need to turn those plans in to actions.

Plans are only good intentions unless they immediately degenerate into hard work.

Failing to commit to a decision is as bad as not making a decision – possibly worse. We should be clear what the decision is, and who and how it will be implemented.

Failing to follow through on a decision renders all the time and effort spent discussing and debating the right choice, null and void, it becomes waste. A waste of time and energy and will undermine a team as surely as the inability to have the conversation.

Be decisive and be clear

Whenever possible any decisions should be associated with a specific action, a date for it to be completed and a clear understanding of who will do it.

If we make the extra effort to identify who will perform the action and when it creates a foundation for the best chance of success, there is a clear and measurable outcome. Everyone knows what to expect and when. This is crucial for being able to hold each other accountable.

Wishy washy action items, that are for everyone with no expected date will generally get ignored, but something specific combined with the certainty that you will be held accountable and it will be followed up will likely mean it gets done.

Pointless conversations

If you find you get to the end of a discussion with sufficient healthy debate and the result is to take no action on a frequent basis, then this is cause for pause. Could you avoid wasted conversations by injecting a Go/No go break a few minutes in to a discussion and ask the team: “If we reach a decision are we empowered to act?” or “If we reach a decsion would we be willing to act?” if your answer is No to either of these, then save yourself some time and heart-ache, if there can be no action then the conversation is moot.

That is not to say all conversations must result in action, but all conversations should have that potential or they are waste.

If I had to recommend one book that would help your team become the best Agile Software Development team, it would be The Five Dysfunctions of a Team by Patrick Lencioni, the book does not even mention agility. But in my opinion the vast majority of questions I’m asked or problems I see can be traced back to something covered in this book.

Every team needs a maverick

Have you ever been on a team where the boss presents a new idea and looks around the team for a response and there is this one guy that breaks the silence by saying “What are you drinking boss? That idea is a bunch of crap” well maybe he was a little more polite but still the message was clear. Everyone else holds their breath waiting to see what happens.

Desire for harmony

For most people the desire to be liked and accepted leads us to have an overwhelming urge to conform with a leader (or the group majority) to maintain harmony, regardless of what we might think. Sadly most people also have a very strong subconscious desire to be agreed with, especially leaders. When people agree it affirms their leadership and those that challenge are perceived as challenging them personally – rather than the idea itself.

This all combines to create another horrible dysfunctional team, one where there is an absence of conflict. Well, apart from that one person stupid enough to speak their mind, and they’ll likely be fired soon, then we can all get back to agreeing with each other.
Now I am making light of it, but a leader that is able to understand conflict as healthy is rare, and one that can, in practice swallow pride and engage in healthy debate is rarer still.

The invisible threat

The problem though is that even with that rarest of leaders there is an invisible threat, the leader himself knows that he values conflict, that to be truly successful ideas need to be freely expressed and freely challenged, but everyone else can see the threat that is invisible to the leader, they know he still holds the power even if it is not overt, that invisible threat still causes teams to hold back and to create a false sense of harmony.

You may think that I am overstating the point but just think back over your career and how often does the yes-man or yes-woman get promoted over the more capable but outspoken. How many leaders surround themselves with people that will affirm their decisions rather than pushing for more. It is natural and normal to like those that agree with us far more than those that push us. But get over it! That behavior is limiting your team.

Solution

My solution to this problem is for every team to have an maverick, someone that is Not afraid, someone who will break the harmony spell and get the conversation started, push ideas to be better, force plans to stand up to scrutiny, to trigger others into sharing their opinions. If you are lucky you have one already. Turns out every team I’m on has one 🙂 but if your team doesn’t already have one (or more than one) then take turns, at the start of a meeting roll a dice, select one person to be devil’s advocate and it is their role to challenge ideas look for flaws or weaknesses, this will push the team to be better and can do so from the safety of an assigned role.

Devil’s Advocate:

The term a devil’s advocate describes someone who, takes a position he or she does not necessarily agree with (or simply an alternative position), for the sake of debate or to explore the thought further through discussion.

Try playing Devil’s advocate:

If you sense that some of the team are not buying in to a proposal but are not speaking up, make a challenging statement
If it is your proposal, invite disagreement by questioning your own proposal, by saying maybe I am wrong, or I think I missed something
Be clear on your motives, you must genuinely want healthy debate. If you invite disagreement but brush it off then it can further encourage artificial harmony

There is a difference between healthy debate and someone that is just obtuse, and conflict alone will not get you to results. But an maverick that is also a genuine team player is invaluable on a team. I’m not talking about jackasses here, but people who are not afraid to speak their mind, for whom honesty is more important than acceptance.

Once trust has been established the next step is to build on that trust with healthy conflict where ideas can be shared without fear, where opinions are heard and considered.

Is it safe to dance?

Have you ever found yourself alone listening to music and you take a look around wondering if it is safe to dance? Safe because your dancing is so bad it is unfit for other eyes, in fact it is so bad you are not sure you should look. Perhaps your car is a little safer, it is a capsule of invulnerability, so when you are alone you can sing at the top of your voice and no one can see, or not until you stop at the lights and notice the person in the car next to you looking at you.

Feeling safe enough to be vulnerable is not easy even when you are alone, but it gets progressively harder when there are other people around. Now I’d never sing or dance in front of others, but the other day I found myself at lunch with four of my closest friends at work – if asked I would say I trusted the four of them a lot, I consider them really great friends, so I felt able to be a little bit vulnerable and I told a slightly inappropriate joke.This may not seem a big deal but I immediately became embarrassed I glowed red and went quiet for a while, I found vulnerability is tough even among such good friends.

Vulnerability is tough even among close friends

We all want to be liked and accepted, to be included in a group, and so it can be hard to be vulnerable, and yet the irony is that taking the step to show vulnerability may well be the step needed to make those friendships and your team stronger.

Trust in a team

In a team environment it is so important that you can feel enough trust with ALL of your team mates that you can truly feel able to say things like:

I need help
I don’t understand
I disagree
I made a mistake
I find those tasks difficult
Show me how to do that again
I feel uncomfortable when you do that
I wanted to do the task you took
I am unhappy with this decision

But if I struggle to trust even my best friends, how can I possibly trust co-workers that I know much less, after all the same rules apply. I want to be liked and accepted, I definitely don’t want to look stupid or uncooperative, I don’t want to discourage others or waste time, I have a burning need to feel valued and part of the team. I need to show my worth to my boss, etc.

Is it safe to dance?

Essentially when you are part of a team you are asking yourself “is it safe to dance?”
If you keep that in mind it gets easier, what would make it safe to dance for you. For me it would take a lot!

I’d need others to dance first, probably all the others, but certainly the leaders, the people the others respect. I’d need to see that some were as bad as me, I’d need to see that no one was laughing at them (only laughing with them) and that everyone was encouraging and supportive, then and only then might I feel able to be vulnerable and join in, and frankly it would take a few repeats before I would truly feel comfortable.

We can dance if we want to, we can leave your friends behind
Cause your friends don’t dance and if they don’t dance
Well they’re no friends of mine…

How does that relate to work?

You may think that dancing is not like working in a team and that the humiliation of dancing is far worse that simply doing your day job, but I think this is one of the reasons teams suffer from an absence of trust so often. We dismiss both the importance and underestimate the difficulty of building trust in a team.

In a team environment you are sharing your ideas which are deeply personal, your knowledge and judgment which may be closely associated with your sense of self. Doing something wrong could affect your job, maybe even your career. Sure you may not look and feel like a buffoon but the stakes are much higher. And even if you get past the work related barriers you still have to contend with our inherent desire to be socially accepted, to be liked and valued.

So how do you build trust on a team?

Actually this is not that complicated it is not really any different to building friendships.

Spend time to get to know each other, take a few minutes during meetings to get to know each other, this is not waste, a few minutes spent building relationships could well be the most productive aspect of the meeting in the long term.
Chat over coffee and as you work – about personal stuff
Have lunch together as a team – this works best if the whole team is together.
Play games! One of the best ways to build relationships is to play a game something simple like a card game is great, it is inclusive and leveling, the most junior member of a team can challenge the most senior in the safe confines of the rules of a game this makes it much easier to discuss work ideas on a level playing field later.
Time, trust and relationships take time, do not underestimate it.

For all of these it works best if everyone is there to avoid creating pockets of trust which could undermine the team later.

The last one was time, and warrants an extra note. Building relationships is a slow process you can’t simply flick a switch, allow teams the time and space to grow the relationships will build and grow stronger and stronger, and once the team is stable changes can be made so long as a core remains to keep the identity and trust that has formed.

Trust takes time

You cannot uncover better ways to deliver software without first uncovering better ways to work as a team. And the basis for an effective team is Trust.

Building trust should be your top priority, spend the time, make the time, it is an investment in the future of the team. Without trust anything else you do will suffer.

Without trust anything else you do will suffer.

Take the time to build trust on your team, make it safe to dance.

It is not how big it is…

A question I have been asked a number of times is how do we “Scale Agile”? There has been so much discussion of scaling frameworks such as LeSS, and SaFe, or Nexus or D.A.D. or even the Spotify model, that we have become conditioned to assume that these are the solution to any scaling or indeed any ‘Agile’ problem.

But as with so many situations and so many problems, deciding on a solution before fully considering the question at hand, leads to an outcome that is likely the wrong one and potentially unexpected and undesirable results.

What are you scaling?

Most of the Scaling frameworks deal with organizing and communicating between multiple teams all of which are working on a single product. But that is not always the case, there is no ‘Normal’ and every organisation is different, some will have many teams and just one product, and some will have many teams and many products, and then there are the multitude of variations in between.

Many teams, Many products

But if the scaling agile frameworks cover the situation of many teams and one product what of the remaining situations? My instinctive response is to wonder whether this is actually an agile scaling question at all. It feels more a question of organisation scaling rather than agile scaling. That may feel like I am splitting hairs but I wonder if we are jumping to finding a solution to a problem that is neither new nor necessarily agile specific.

If our organisation is simply growing and we have more teams working on more products and there is little or no dependencies between the various teams then there is no scaling in the sense that these frameworks relate to. The agile frameworks provide a structure for shared communication and consistency of purpose, and there is an overhead for ensuring a common vision and a consistency of direction. All very important when there is strong dependencies and interactions between the teams.

But if you are able to organize your teams with autonomy of purpose, and are able to minimize the coupling and dependencies then are you really scaling or are you simply growing? The organisation that are multiple teams working on one product are genuinely candidates for scaling and so I will purposefully ignore them for the purposes of this post.

More teams does not mean you need a bureaucratic layer

The difference is that we don’t need huge amounts of overhead or a layer of bureaucracy, if we simply have a larger number of autonomous teams, then we are able to maintain a flat structure but simply grow and duplicate. Naturally there are elements of the organisation that will need to ‘scale’ to deal with the growing number of teams and people but this is not agile scaling of the teams themselves.

What about dependencies between teams

In some cases there will be teams that have dependencies on another team, but it may be possible to organize your products such that whilst dependencies occur, the dependent team becomes a (very important) stakeholder in the other product, and so there may be a case for prioritizing stories that support the dependency. However, there is not a tight coupling between these teams, they can still each be run almost entirely independently of each other.

Now this proposal is not entirely without overhead especially when there are teams that are inter-dependent. Identifying the boundaries between products may require some thought and effort. Coordinating the dependencies and ensuring they are given the appropriate priority will require some additional communication.

What about scaling on a small scale?

So that covers many teams and one product and many teams and many products, but what about a few teams and one product? This is actually the situation I consider most difficult.

But these problems are likely not enough of a problem to warrant the large overhead of structure that a scaling framework imposes. Once again this seems to be more of a question of organisation than scaling, sure there is an element of scaling, but not so much that we need a heavyweight solution.

For this situation we may be able to make it work with something as simple as a few shared meetings (Scrum of Scrums) combined planning or refining session and a structured approach to delivery. Organisation, and dare I say it, the true sense of management – not throwing around orders, but coordinating, enabling communication, promoting transparency and creating a clear direction.

The Product Owner may also be able to think about stories in a context that works well with a multi team view. It may be that it is a single large product but could we divide by feature areas, or logical vertical slices of work. Yes there may be situations where there is overlap but it may be that we are able to write stories or share stories between the teams that intentionally minimize conflict. There are some elements that will require special consideration, such as UX which must be considered across the entire product and should be consistent, but that is not true for all stories.

But please do not underestimate the overhead of multiple teams – even just two, it is significant and can cripple the product delivery if not implemented well. You may need to lose some of the freedom of small teams, a shared definition of done, possible a common cadence, common deployment environments etc. And there is a greater need for trust in an environment that is less conducive to trust. It is not possible to be involved in all decisions in a multi team setup. There will be compromises and conflicts. So much so that in many situations you would be far better to consider extending the timescale and managing with one team.

Summary

The first (many teams and 1 product) is well documented in the various Scaling Frameworks, I am not suggesting implementing them will be easy but they are well documented and there are many experts.
The second – many teams, many products – is a question of organisation rather than scaling, so should be no harder than you have found it so far, it is repeating the same albeit with a few complications at an organisational level.
But the last group fall in to a gap between the two extremes. If I have say two or three or even 4 or 5 teams working on one product, I will still have the usual communication difficulties, the need for consistency of direction becomes ever more important and we have a situation where teams can be highly dependent on each other.

It may sound like I am discouraging using the Scaled Frameworks, and I suppose in a sense I am, but not because I disagree with their use, but because they all carry with them quite significant overhead of effort and cost and in a lot of situations there is no benefit and may even be a severe detriment. If you can solve the problem with a little bit of organisation, rather than adding layers of overhead and bureaucracy, surely that is better?

Naturally every situation is different, consider each independently, but please don’t assume because you have multiple teams you need a scaling framework.

Is learning an expense or an investment?

The capacity to learn is a gift;
The ability to learn is a skill;
The willingness to learn is a choice.

Brian Herbert

It is pretty safe to say that most learning involves some kind of cost, whether it be that you are slower as you learn or have to explicitly take time to learn something new. There is a time aspect, an effort aspect and sometimes even an overt outlay of cost for a training course a book or a subscription. But all are a cost to you or our employer. But the question is: Is that cost simply a necessary expense or is it a worthwhile investment for the future?
Is that cost simply a necessary expense or is it a worthwhile investment for the future?
This is a tough question and I am sure many employers and employees wrestle with on a regular basis. For the employer there are concerns that time spent learning is time that is not productive (or not as productive) the time could be better spent generating income. In the case of formal training or qualifications there may be an opportunity cost of the time spent AND the cost of the training which can be significant, and perhaps more concerning the employee becomes more employable and more valuable as a result so there may be a consequential increase in turnover or a necessity to pay the employee more as a result. In essence it is easy to become focused on the expenses and forget the benefits that come from a better trained and more fulfilled workforce.

As an individual/employee it often is expected that you do your learning on your own time, you are motivated for self-improvement and your employer may focus on the benefit the employee gains rather than the benefit to the employer. The difficulty with this is that learning time tends to be when you are least energetic, or at times when you are sacrificing other activities.

Short vs Long-term thinking

In the simplest form the choice may often come down to the type of work and whether an investment in people will benefit the organisation. My initial thinking is that if you expect to have a high turnover of staff or the type of work you do is low skill, then investment in people may be perceived as an expense rather than an investment but even then I wonder if an investment in learning may reduce turnover and increase skill. But in the field of software where the world changes almost daily, with new techniques and new approaches appearing regularly, then an investment in learning is not just beneficial it is almost essential just to keep up. To not invest in learning could be very detrimental to the long-term prospects of your organisation.

Choosing NOT to invest in learning could be very detrimental to the long-term prospects of your organisation.

In ‘software fields’ good people are hard to find, and even harder to keep. Many organizations now operate flat structures with little or no hierarchy, promotion in the conventional sense is no longer the main form of advancement. Individuals grow through learning new skills and becoming experienced in new techniques, and not simply hands-on learning and experience. We rely on intrinsic motivation – Autonomy, Mastery and Purpose, to keep employees engaged, happy and productive.

A key element to both Autonomy, Mastery and even Purpose is time for learning and reflection. People that are not supported in this are likely to be less fulfilled, less happy and more likely to look for work elsewhere. Entropy sets in, and in software that can be fast and devastating for both individuals and organizations, individuals with outdated skills can find it difficult to find work and become demoralized and trapped, organizations can find that motivated individuals want to be working on new technologies and embracing new techniques.

What is our goal?

An organisation is generally interested in making money and growing either in size or in effectiveness, understanding this we can attempt to visualize how individual learning can support that goal. Learning and personal development leads to a sense of Mastery, empowering the employees by giving freedom to use the time as they see fit provides autonomy, and sharing your company vision and how they can be a part of that provides the purpose. Employees that feel these motivations will be happier and will be far less likely to leave, turnover is hugely costly to an organisation especially when it is the better employees that are more likely to leave. The reduction in turnover alone may be enough to justify significant effort. But improving employees will use those new skills in their work, they will encourage others and it is highly likely that productivity and creativity will improve. In short providing opportunities for learning supports the goals of most organizations.

How much time should be assigned to learning?

At a previous company they set aside 2 hours a week for each employee to dedicate to personal development, this was in addition to any formal training. This is close to a 5% increase in overhead per employee, which is significant but set aside a reduction in turnover may be immediately beneficial. In practice however it was not always observed, pressures from projects would often squeeze this time as it was seen as secondary to business objectives. The frequency in which it was observed undermined the policy.

In environments where time is billed to clients it becomes even harder for a company to see the value of learning, it becomes un-billed time which is even more costly but that doesn’t reduce the importance or value in the learning time. I’d like to see organizations regularly set aside 1/2 a day each week for personal development, and provide the tools necessary to make this effective – pluralsight subscriptions, purchasing books for employees even if they are not directly relevant to their work – remember the goal is to motivate and create an environment for improvement. At 10% of employee cost this is a significant ask, but I would hope that if introduced in the right way with enthusiasm and support, employees will embrace the way you are valuing them and their personal development and this investment will pay dividends.

Our danger is not too few, but too many options … to be puzzled by innumerable alternatives.

Richard Livingstone

Can you have too much autonomy and too much choice?

One final observation is that when presented with boundless autonomy we generally become lost and confused. Most people will respond to this with confusion and more limited actions than when provided with a framework. Imagine a restaurant with no menu, you could order anything you like. Most people would be conservative in their responses, they will not challenge themselves or their boundaries instead choosing something they already have confidence in and confidence that it is easy for you to provide – some will challenge but most are cautious. Also most people don’t like this, they want a restaurant to have a menu. They may grumble that something isn’t on the menu, and may ask to switch X for Y on their order or for the cooking to be modified, but the framework of a menu provide scaffolding and enables choice, the lack of the scaffolding stifles it.

It is the provision of boundaries that enables us the pleasure of pushing them, and having some guidance of what our options are for learning enables us and empowers us far more than a blank slate. With some ideas of what is available we are able to ask for more or suggest alternatives.

Summary

Make Time: In my opinion an organisation that is in the software field needs to make learning a pre-requisite, this is the most important task of the week. Learning time is very important, so set aside time for it, and make the time such that it doesn’t conflict with the team or other business activities, Maybe set aside Tuesday morning as personal development time and challenge anyone not using it. Teams where there are pressures or pairing may feel that this time impacts on their peers or their project this message needs to be challenged regularly. This is for the long-term health of the business which outweighs any temporary short-term pain.
Scaffolding: Create a framework where it will be used and is not just a hollow gesture, have a menu of options, and people who’s role is to support and guide, set development goals, provide subscriptions to online training, a budget for formal training, encourage in house peer training in this time. Encourage people to present their learning, acknowledge them for their efforts and especially for sharing it with colleagues.
Broaden Scope: Don’t limit this to technical skills, or to skills your organisation currently uses, this is about personal development, so team building, soft skills, and even time to reflect on learning or their career/interests all help with that.
Support: Some people will need more encouragement and support than others and so a group that is dedicated to professional and personal development could be invaluable to get the best out of this initiative. All of us can benefit from someone to help us identify our goals and a plan, and to encourage us stick to it.
Persist: Finally this will take time to become habit, starting the initiative is not enough, for a while it will require reminders and reinforcement to get the best from it, but if you are able to provide your team with the opportunity to grow as they want, I believe they will become far more engaged, enthusiastic and energetic.

Team leadership in Agile teams

Yesterday I had two people both of whom I have a lot of respect for, independently say that having a single person in charge of a team ‘works‘.

I was taken aback by this, partly the surprise that two people would say the same thing on the same day, but mostly because this goes against my experience and my opinions on good team leadership. This caused me to step back and reconsider my opinion and my reasons for it. For me there is a great pleasure in being challenged on my opinions especially ones that I was so sure of and so I have given it a lot of thought.

My experience

I have worked for other people directly or indirectly for more than 25 years, and I have managed teams myself, I have also coached quite a few teams – so was able to witness leadership from the sidelines. By a very quick count of those I can remember I would say that 70-80% of them were (in my personal opinion) poor leaders, there were a few that got the job done by force of will, or by leveraging authority, or by imposing death marches on the team. The organisation sometimes saw them as successful but the teams thought them dictators or bullies.

Many team leads simply were unwilling to see any perspective other than their own. Others who were clearly insecure at accepting other people’s ideas. But there were a few good or even great leaders that didn’t see management as a tool for control but as a scaffold for building the team and achieving things, if only these could be cloned.

So I am probably coloured by my experiences but the notion of one person in charge of the team fills me with dread. and whilst I wholeheartedly agree that the model of a single leader can work with the right person, that does not mean that it will work in most cases or that those qualities are the norm, and it certainly doesn’t mean it will work as a model in every case. What is more I think those great leaders would thrive in an environment where they didn’t have defined authority- but more on that later.

I can only imagine that just as I have been coloured by my experiences my colleagues have equally been coloured by theirs but they have had the good fortune to see better leaders than I have and I would like to (and will) discuss this further with them to see why they feel this is a good approach and whether my instinctive reaction and poor experiences are in contrast to theirs.

“Leadership should mean giving control rather than taking control and creating leaders rather than forging followers.”

David Marquet

oh Captain, my Captain

The military is often used as an example of one named leader, but there is a distinction in the military and that is they have needs that are very different to a software team. Those differences are a need for independence and a desire for expedience in decision making: Military units will often need to operate independently without contact with their parent structure. So it may be necessary for a local arbiter. In a business environment it is rare that a disagreement is so urgent that it could not be referred up if there was a dispute with an impasse. The other aspect of a military organisation is that life and death decisions need to be made very quickly and so there may not be the luxury of time to debate and reach consensus.

However, even in military structures there are examples of leaders who take the view that they are the Product Owners, they will say this is what I want to achieve, you tell me how… and then the suggestions are made and the leader simply endorses the team’s advice (Make it so..). Naturally there is an element of accountability but the trust that this demonstrates in the team is significant in empowering the team and growing them.

This notion is explored more deeply in this book: Turn this ship around

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile principle No 5.

We want conflict and debate

In software teams it is often the debate that produces the greatest thinking and ideas so stifling the debate is a negative. Having a single person making decisions stifles debate, it thwarts conversation, and it disempowers the team. If a team is overruled often enough they will stop making suggestions, if one person becomes so myopic in their opinions it can make the team feel powerless and excluded. Also where there is a defined leader they have a tendency to not be transparent, information is selectively shared (in both directions) and again lack of information impedes debate. In short I believe that having a defined leader is in conflict with the Agile principles.

The best architectures, requirements, and designs emerge from self-organizing teams.

Agile principle No 11.

Merging the what and the how

Having the same person responsible for both the what (vision) and the how (implementation) stifles innovation. Rather than the team determining the best architecture and the best solution it becomes driven by a single individual. Again this is at conflict with the Agile principles, and whilst you may say that a good leader wouldn’t let this happen, experience and evidence is to the contrary. Power corrupts and if someone has the responsibility and authority it becomes hard for them not to use it especially if they perceive the team is making a mistake, and if teams are prevented from making mistakes they will stop experimenting.

We want balance

And this is where my agenda is. Software development is a balance of content, quality, cost, value, consistency, team growth and a variety of other factors. It is rare or at least uncommon to have a single individual that is able to understand and balance those conflicting elements effectively on their own. More often a single individual prioritises one above the others, driving to a deadline, or gold plating a solution, or any other single aspect usually becomes prioritised at the expense of the rest.

I believe that a model where there is shared leadership and shared management between multiple roles solves many of these problems. Having someone focused on the what and others focused on the how and someone else focused on team improvement and consistency creates conflict (deliberately) but it also creates balance and it becomes a catalyst for debate.

We don’t want a single point of failure or a silo

If we make one person responsible for direction, implementation and team growth, we are putting all our eggs in one basket, if they are on leave or sick or move on then the impact can be significant. There can be so much knowledge tied up in one person they become indispensable.

Problems with the shared leadership model

First and foremost there is a cost. For small teams it may be difficult to find team members that have a natural affiliation to the balanced leadership model, with part time POs or coaches/scrum masters or where those roles are not named but the responsibilities are shared it can be tricky. But even then I would say that calling one person ‘Lead’ or ‘Manager’ or anything of that sort is destructive. And the notion of combining Coach, PO and implementation into just one named role can lead to dysfunction. In many respects I wonder if the cost of additional named roles is worth it just to prevent the dysfunction a single leader creates. Or if the team is too small to warrant the explicit roles then get rid of named roles entirely – if a team is that small naming a leader should also be unnecessary, they ought to be able to self-organise within those boundaries.

This may sound hypocritical, after all I have spent a good proportion of my career with leader or manager in my job title. But my experiences have been an internal conflict in that role. As a Software Development Manager you become the defacto Product Owner, Project Manager, architect and team coach. But there was always pressure from somewhere and normally that pressure was to the detriment of the team, when I challenged it, I did so a personal risk. Customer and senior management pressure to deliver, cuts costs and drive timelines meant that team growth became secondary, team welfare was deprioritised and making a safe place for teams to learn from mistakes was difficult to justify. Some of that is company culture but I believe much of that comes from the pressure of responsibility and bestowing leadership carries pressure and expectation (sometimes real, sometimes assumed). And speaking as someone that has experienced it, I’d rather share that responsibility.

Conclusion

So after sleeping on the issue I am even more convinced that a named leader – whether it be Team lead, tech lead, manager, senior or nerd wrangler, goes against the principles of Agile, I believe it undermines self organising teams and leads to dysfunction and imbalance. There absolutely are exceptions and there are some team leads that are effective, but I wonder if they would be just as effective or more so in a self-organising team structure. But there are more examples of ineffective team leads where the power corrupts and they dominate the team, stifle debate and innovation and disrupt or impede team growth.

In my very personal opinion the best leadership model is a balance of What, How and Team Improvement, and the more people those responsibilities are spread amongst the better. In practical terms I’d like to see a team with a PO to determine the What but a PO who actively engages with the team. A coach that is focused on the Team’s improvement and process improvement, and the rest of the team is responsible for the How. Within the team there is no need to identify a senior or a leader they can work out amongst themselves how best to make decisions and titles get in the way. This model may come with a cost and it may be difficult to get the balance right but in my experience this balance leads to the best results.

Ironically the examples of leaders that I have seen as being successful (as measured by both results and team morale) have voluntarily and noticeable made themselves servant leaders, stepping back and inviting the team in, choosing to give away authority and creating healthy debate and healthy conflict. So if that is how they lead effectively why not make that the model to start from?

Why I came to adopt an Agile mindset.

Ultimately it was because of seeing poor leaders disempower the team and abuse teams into death marches and drive poor design decisions that I came into Agile in the first place. I saw Agile as a method for empowering the teams and taking away abusive power from lone leaders. The stimulating of constructive conflict and healthy debate are so essential to the process that I object to any impediment to this on principle.

To my delight in most cases Agile has done that and so much more, in a creative environment like software the gains of self organised teams so massively outweigh the losses that result from a lack of a single clear leader that I am more confident in my opinion that the words ‘lead’ or ‘manager’ have no place in job titles on an agile team. I would love to trial and experiment to compare, but as much of this comes down to the personality of the people involved it is hard to do more than make subjective experience based assessments.

Just what is an Agile Coach?

An Agile Coach is a relatively new job title, one that has become popular over the last 10 years or so and is a role that causes a great deal of confusion: what do they do? and how do you know if they are doing a good job?

It is also a title that covers a great many responsibilities, sometimes Agile Coaches will coach teams, sometimes they will coach organisations. For the latter I prefer other terms and so for the purposes of this article I will assume that the role is one aimed at coaching development teams within an organisation.

What the role is not…

An Agile Coach is not a manager,

although many Agile Coaches will have had experience as managers or at least have had backgrounds similar to other business leaders. An Agile Coach will generally have a broad history of working with people, and understand how to manage people – and how not to. In organisations with Agile Coaches they will often reduce the demand for managers or in some cases eliminate the need for managers entirely. But not by taking on their responsibilities, but by showing and enabling the teams to fulfill many of the responsibilities for themselves. This is generally much tougher than managing directly, as they must do it without authority. Much of an Agile Coaches responsibility will be in building teams and encouraging good working practices and collaboration with colleagues.

An Agile Coach is not a Project Manager,

although again they may have a degree of knowledge and experience in this area. An Agile Coach will be there to work with teams to deliver software, but an Agile Coach is much more likely to ask “Why?” than they are to ask “When?” A coach is far more interested in whether a team understands a priority than they are in ensuring a team meets a deadline.

An Agile Coach is not a lead developer,

although they may have once been one, sometimes they may pair with people on a team, coding or testing or designing, but they are not there to be productive but to enable the team to become more effective. Sometimes through advice sometimes by example and most often by enabling safe failure, a Coach will likely let you fail and then ask questions to help you understand why you failed.

An Agile Coach is not a facilitator,

although they may facilitate meetings and events. A facilitator will often be neutral and unobtrusive. A Coach should know when to prod, poke, be provocative and even contrary or when to stay silent. I know coaches that will deliberately and consciously stay silent during a meeting, noting for themselves what their advice would be but just watching to see if the team reach the same outcome. Other times, suggesting a false path to see if the team challenges them. Other times they may guide a team to an outcome if they feel the team will benefit and will be able to make similar choices in the future. Most often I find myself sowing seeds of ideas in the hope it will trigger the team to come up with a solution for themselves.

An Agile Coach is not a trainer,

although they will help you learn. An Agile Coach may at times teach in the conventional sense, but more often they will enable you to create opportunities to learn, and when they do training or seminars it will likely be composed of learning opportunities more so than lecturing from the front. A Coach will generally try not to tell you how to do something nor even show you how. Normally they will ask questions that encourage you to figure it out for yourself. This is not of course the only way to coach and sometimes it is more effective to show and then ask why you did something a certain way. But it will be rare that a Coach will tell you how to do something without ensuring you understand why you are doing it. As you can imagine this can be an area of frustration at times.

What are they then?

An Agile Coach is Experienced

An Agile Coach is generally someone that has been there and done it. There are a whole host of learning material on Agile Practices; delivering software; and managing people and businesses. But there is no substitute for someone that has done those things first hand, and better yet had difficulties or failed at doing some of those things. You will likely find that an Agile Coach has years of experience of delivering software in general, often having done a variety of roles.

I believe the reason for this is that in most situations where a coach adds value it is not a solution that is sought, but and understanding of the problem. Someone that possesses nothing but canned solutions to questions, hasn’t had the benefit of the journey to understanding that the question asked is rarely the question that needs answering.

To get there requires the ability to see beyond the question, and in my opinion at least, this comes far more from experience than teaching. I find some of the best lessons are in the form of fables and analogies. Because they are able to stir our own experiences to enable us to better understand why we do something rather than being presented with a solution.

Experience is the teacher of all things

– Julius Caesar

An Agile Coach has plenty of soft skills

the chief of which is empathy, which comes from experience. The ability to understand the perspective of a developer or QA or the other members of the team comes a lot from experience, which is why so many coaches started their careers in software delivery teams. But the role also requires communicating with management and customers and other teams which requires great communication skills and yet again can benefit from having been in a management role, or project lead, etc. The role may involve 1-1 coaching, mediating conflicts, giving difficult but constructive feedback, building relationships with teams and encouraging them to build relationships among themselves. Negotiation, selling, planning, listening, advising provoking and challenging. A great coach excels with soft skills. A few coaches have an abundance, most of us are skilled in some areas but are still growing and learning to develop these skills.

An Agile Coach is responsible

but not accountable, they are responsible for guiding the teams in Agile Principles and Practices, but priority is given to understanding why, over learning how. But they are not accountable for the teams following Agile principles, the teams themselves are. The coach can show the way but does not force you on to the path.

An Agile Coach needs to be humble

On the best days a coach is a force magnifier, they are able to show a team or an individual how to improve, but the coach will rarely be able to say “look at what I achieved” instead they will sometimes be able to say “Look what I helped achieve” but more usually watch from the sidelines as credit is given to the team or the individual. If you are looking for glory this is not the job for you. You are often even held in a negative light when you shine the spotlight on problems that were previously unseen. A thick skin is essential.

An Agile Coach needs to be hungry

Being Agile means always wanting to improve, and to do that requires a desire for learning, through experience and through other forms of learning, books, conferences, discussion groups. An Agile Coach that isn’t learning and pushing themselves will likely very quickly become ineffective.

An Agile Coach is open to new ideas

Agile is not a methodology, it is a desire and determination to find better ways to develop software and help others do it. An Agile coach should not be wedded to a framework, be it Scrum or Kanban or XP or any of the others, they are tools to reach an end. When we limit our scope to only one framework we cease to be an Agile Coach. We should be aware of the options and be open to new ideas. That doesn’t mean we don’t favour some over others, but we should have an acceptance that they are merely a tool to do a job. Each may have areas they are better suited, and perhaps with sufficient understanding it may be possible to combine ideas or cherry pick elements from other methods.

The benefits of an Agile Coach

An Agile Coach’s expertise is much broader than Agile methods, whilst at it’s core the impact can extend from teaching the basics of the various Agile methods through to expertise in the various roles in an agile organisation – such as Product Owner, or implementing XP practices, coaching organizations on Agile transformations or simply process improvement. But most Agile Coaches have expertise that goes much further and may well be skilled at coaching interpersonal issues, team building, management techniques, personal development, conflict resolution and most of what would be considered ‘management’ skills.

I would broadly break down the benefits of an Agile Coach in to four areas

Coaching on Agile Methods
Coaching teams that have identified a need for support in certain areas
Helping teams identify areas where they need support
Helping organizations identify ways they can improve teams at a macro level

The first two the teams are likely consciously aware of and so are able to identify the need and make the request. The latter two by their nature are likely areas that the teams are not aware they have an issue, or feel it is something they cannot change (in isolation or at all)

The four stages of competence:

Unconscious Incompetence: If you are unaware you lack a skill or are unaware of a deficiency you cannot ask for help. A coach should be able to observe and identify where you may have areas for improvement, it is common for us to be unaware of our bad habits or blinkered thinking, we get stuck down rabbit holes, sometimes this can be on an individual level and sometimes teams can be the same way. It generally takes someone from the outside to see the problem and help move it from unconscious incompetence to a conscious incompetence, once we are aware of a problem we can choose to do something about it.

Conscious Incompetence: If you are aware of a problem, you can take steps to improve. Sometimes you can do this on your own but sometimes it makes sense to ask for help, asking for a coach to help guide you, they may have past experience or suggestions or techniques to help. With effort you can generally move from conscious incompetence to conscious competence

Conscious Competence: At this stage – with some effort you have the skill or have obviated the defect, but it still requires effort. Now it is really a question of practicing the skill until you become proficient (unconsciously competent), the value of a coach here is not in the evolution of the skill or the breaking of a bad habit, it is in the observance of new bad habits forming and stopping them early.

Unconsciously Competent: As you improve one skill area and become unconsciously competent – you have a mastered a skill, you may discover more skills you lack, and the cycle repeats.

How to measure or for that matter manage an Agile Coach?

There are generally considered to be a number of situations where it is very difficult to measure and therefore difficult to manage someone:

Where the person’s expertise is broader or deeper than that of the person measuring them – essentially how can you assess performance if you cannot judge if it is good or bad and to what extent it is good or bad.
Where the person’s contribution is intangible.
Where the contribution is situational and variable, there is no yardstick. (Such as creative or innovative work.)

An Agile Coach falls into all of these categories.

There is no easy objective way to measure performance as there are no KPIs. The coach’s goal is to improve a team or an organisation, if the organisation/team improves – was that because of the coach or for other reasons? There is no objective way to tell.

At some point it becomes a question of trust, and subjective assessment.

If you have a problem and ask for help, a good Agile Coach will give you a solution, but a great Agile Coach will show you how to solve the problem for yourself.

Summary

Not all Agile Coaches are the same, and not all will possess all of the skills above. Each one will have different strengths and weaknesses and a lot will come down to how they interact with the team they are with. Like any profession there are some Coaches that are better than others. But in my view any team should be able to improve with the right coach, but not every coach is right for every team.

If you believe that you cannot improve with coaching (and some teams do claim this), then you are probably right, a mind so closed to the possibility of learning, or that someone else may see something you can’t, then maybe you cannot grow and you may be incapable of improvement. But consider that even the best sportsmen, and artists have coaches, the most successful business execs often have outside mentors. The limiting factor is not the coach it is your willingness to grow.

I’d also add that some coaches are better with teams at different stages of Agile maturity or the different stages of a team development, that does make one better than the other. I’ve seen some extremely experienced agile coaches that are so advanced in their understanding of Agile methods that they find it difficult to relate to teams that are at the start of the agile journey, they try to push the teams to new concepts before they are ready, rather than guiding them to their own growth.

In the same way not all Agile methods are right for all teams or organizations, understanding the strengths of your teams and the strengths of you coaches and finding a match may be the key to success. Some teams may require more time with them than others too, this is not necessarily a reflection on the ability of the team or the coach but on the skills being improved and the type of coaching that is happening. Sometimes a change of coach can stir things up and open new growth opportunities.

Overall I’d suggest that a coach is more guide than leader and asking one for advice is not a sign of weakness, it is a sign of strength. none of us know everything and the willingness to ask for help to learn is a crucial step to growth.

Bike-shedding, Bystanders and Boredom:

Background

Defined Purpose

*Bike-shedding (or Parkinson’s law of triviality)

Structure vs Empowerment

The three layers of self-organization responsibilities

Primary Tasks

Secondary Tasks

Tertiary Tasks

Bystander Syndrome

Summary

Accountability of others

Holding yourself accountable

Accountability techniques

A regular stand-up meeting

Make your work visible

Always review previous actions

Was the purpose achieved?

Summary

Related reading

Project or Product

Management is doing things right; leadership is doing the right things.

Agile Transformation is about moving from Management to Leadership

Impact on Project Managers and Business Analysts

It is particularly difficult for Project Managers.

An Agile Mindset

Agile Transformation should not be your objective

Can you make a decision and follow through on it?

Consensus

I want to feel valued

Unless commitment is made, there are only promises and hopes… but no plans.

Turn decisions in to plans

Plans are only good intentions unless they immediately degenerate into hard work.

Be decisive and be clear

Pointless conversations

Desire for harmony

The invisible threat

Solution

Try playing Devil’s advocate:

Vulnerability is tough even among close friends

Trust in a team

Is it safe to dance?

How does that relate to work?

So how do you build trust on a team?

Trust takes time

Without trust anything else you do will suffer.

What are you scaling?

Many teams, Many products

More teams does not mean you need a bureaucratic layer

What about dependencies between teams

What about scaling on a small scale?

Summary

The capacity to learn is a gift; The ability to learn is a skill; The willingness to learn is a choice.

Short vs Long-term thinking

Choosing NOT to invest in learning could be very detrimental to the long-term prospects of your organisation.

What is our goal?

How much time should be assigned to learning?

Our danger is not too few, but too many options … to be puzzled by innumerable alternatives.

Can you have too much autonomy and too much choice?

Summary

My experience

oh Captain, my Captain

We want conflict and debate

Merging the what and the how

We want balance

We don’t want a single point of failure or a silo

Problems with the shared leadership model

Conclusion

Why I came to adopt an Agile mindset.

What the role is not…

An Agile Coach is not a manager,

An Agile Coach is not a Project Manager,

An Agile Coach is not a lead developer,

An Agile Coach is not a facilitator,

An Agile Coach is not a trainer,

What are they then?

An Agile Coach is Experienced

Experience is the teacher of all things

An Agile Coach has plenty of soft skills

An Agile Coach is responsible

The capacity to learn is a gift;
The ability to learn is a skill;
The willingness to learn is a choice.