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).

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

Productan 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?

five-dysfunctions-pyramid

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.

Childrens-4

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.

 

 

 

dysfunctions

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.

perception

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.

 

dysfunctions

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.

 

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.

maxresdefault

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…

dance

 

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.

trust-stones_480-300x200

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

dysfunctions

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.

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.

slide1

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.

slide2

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.

slide3

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.

now-vs-later

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

badleader

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.

david-brent

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

turn-ship

 

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.

leadership
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_off_all_things-305021

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

  1. Coaching on Agile Methods
  2. Coaching teams that have identified a need for support in certain areas
  3. Helping teams identify areas where they need support
  4. 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.

 

 

 

 

 

 

 

The effect of Bystander Syndrome on an Agile team

For those unfamiliar with the term, Bystander Syndrome is a condition where responsibility is diffused as a group becomes larger.

From Wikipedia:

The bystander effect, or bystander apathy, is a social psychological phenomenon that refers to cases in which individuals do not offer any means of help to a victim when other people are present. The probability of help is inversely related to the number of bystanders. In other words, the greater the number of bystanders, the less likely it is that any one of them will help. Several variables help to explain why the bystander effect occurs. These variables include: ambiguity, cohesiveness and diffusion of responsibility.

The larger the team the lower the sense of responsibility.

I have noticed a similar trend with self-organizing Agile teams, as the team becomes larger the individuals on the team appear to show signs of becoming less accountable and have less of a sense of responsibility for issues on the team.  Dull or unpleasant tasks get ignored and deferred, whole team action items get ignored with the defense that they expected someone else to take it.    With self-organizing teams there is no single person that is accountable for this and the accountability is so diffused that there is no sense of responsibility. Accountability is reduced proportionally to the size of the team.

But even when there are just two in the team there can be issues. I am sure every other married couple is perfect and this doesn’t apply to you, but there are many occasions where my wife and I each assume another will do a job, only to discover that neither of us has done it.  “Did you pay the gas bill?”  Some jobs have a tendency to fall between our fields of responsibility and get missed. As a result of this we now have a whiteboard in the kitchen and on a daily basis I can see the jobs I have been avoiding and hoping someone else will do.

img_0121

My observations

Behavior changes depending on the circumstances and how clear the expectation of responsibility is. For example:  If there was a system where the team needs to go and look at a queue of service issues they would be far less likely to look and take up the task, than if the issue was emailed to the entire team.  And the larger the team, the less likely any one individual was to look.

What is particularly noticeable was when a single person was specifically named in an email and asked to look, the response rate would be much higher, and if someone came in person to ask a particular person the rate would be higher still.   In essence the harder it becomes to avoid acceptance of responsibility the more responsibility we seem to accept. But it all seems to be subconscious. I would hazard a guess that the team were not overtly aware that they were dodging responsibility. In most cases each individually felt what they were doing was the most important task for them.

I am not a psychologist and these are just observations of a few teams in action, but much to my disappointment it appears to conflict with my notion that self-organized teams are the ideal.

Where no leader is assigned a hero emerges (or a martyr).

An exception to bystander syndrome seems to be an emergent hero, someone who sees the lack of responsibility and begins to fill the void. Often one member of the team would end up taking the defacto responsibility upon themselves, even though it should be a shared responsibility, this sometimes results in a variation of siloing. The consequence of this is that a hidden dependency occurs, and as there is no formal responsibility when that person is on leave the task gets forgotten or ignored. This may also result in negative behaviors such as informal internal hierarchies or power plays.

This situation also builds resentment, if the self anointed person is making decisions for the team the others may resent this “decision making without authority”, if the tasks are dull or menial then the self anointed martyr may resent feeling obliged to pick up the slack. Neither outcome is healthy and may require an outside impartial person to see and help overcome the resulting dysfunctions.

The value of visualizing your work

In Scrum we ‘forecast’ the work at the start of the Sprint and the tasks are added to the ToDo column on the board, with KanBan we have a prioritized backlog of ready items to take and we take the items from the ready queue (ideally in order).  In both cases similar behaviours occur. Some team members have a greater sense of responsibility than others and so unpleasant work is not evenly distributed, the enthusiasts or martyrs take undesirable jobs. And if any work doesn’t get put on the board the team feels free to ignore it entirely.  Which is why it is so crucial to create cards for all work needing to done by the team and clearly prioritize them, and why the use of a board becomes so valuable for self-organizing teams. It is a way to visualize our work, and by doing so we visualize and reinforce our responsibility.  The board is pretty hard to ignore. In many respects the board become the boss. It tells you what to do, what is most important and which things need help.

 img_0218

Action Items from meetings

Ever noticed how in a meeting the whole room can agree that something needs to be done but when asked who will do it, the whole room goes silent. We suddenly become bystanders hoping that it is someone else’s problem, that someone else will volunteer. But as a self-organising team we are all equally responsible aren’t we?

This is a point of internal conflict for me, if an action item does not have an owner it often doesn’t get done, so it is normal practice to assign an owner. We make someone accountable before we leave the room, but by doing so we immediately absolve everyone else of responsibility. We create a silo, maybe it is just for that action item, but it is still a single point of failure. The creation of unnecessary silos is something that I don’t like on principle, but at the same time I am well aware that silos are the best way to get something done. When responsibility is clear the task is far more likely to get done.

My ideal would be to defer the decision on who will do a task until the task is started. When Fred – the team martyr – volunteers to take every action item, because the rest of the team suddenly find something fascinating on their phones or on the ceiling when it comes time to ask for a volunteer, we create a situation where he becomes a bottleneck,  others could do the task, but feel they are unable to because it has been assigned. If the task does not make it to the board we may not even realize he is a bottleneck.

But deferring deciding who brings us back to a situation of a task falling through the gap. My preference is to assign a task for someone to create a card to put on the board for any action item. (I’m always looking for a better way.) It feels like the right sort of compromise, someone takes responsibility for getting the card to the board, so we can be confident it will get there, and once on the board and prioritized the teams understand the need to pull tasks in priority order. Leaving the decision of who will do it until the last responsible moment.

Team size

Independently and for reasons other than diffusion of responsibility, Parkinson (as in Parkinson’s Law), concluded mathematically that groups larger than 20 were ineffective and that the optimal max size for an effective group was 8 or less, which by happy coincidence is pretty close to the Scrum guide of a max of 9.

He was studying governments and leadership groups but the same principles apply to any group asked to make independent decisions and has shared responsibility and accountability.  He found that the communication overhead of larger groups made decision making hard. He also noticed a tendency for the groups to focus time and energy on topics the whole team could understand. Which resulted in a bias towards triviality, the less complicated the topic the more you could become involved.

Smaller groups were generally more effective and better able to make decisions.

What exactly does a manager do?

Most of us have had managers at some point, and in business they are widely accepted as a necessary overhead.  Mostly management is about organisation and communication. A manager is a single point for communicating downwards, they are a focal point for communicating upwards. They can be a decision maker, they can set priorities, they can remind us of responsibilities. They can remove obstacles. They can guide and support and resolve disagreements. Often they also do administration, and reporting. Set goals and ensure you are working on the right thing, are getting the training and support needed, and perhaps even ensuring you are happy in your work. Not much of that requires authority, it is mostly support.

For some of us we have been lucky. Occasionally I have had a boss that I have hardly noticed, he has given me space to do many of these responsibilities myself, only being there when absolutely needed. A boss can do this when he is confident that he can trust you, and that you are able to perform the role independently.

So if sometimes bosses can do this, why not all the time? Is the need for a manager a reflection that the team cannot function without her, or is it because she doesn’t trust the team?  My guess is that sometimes it is one; sometimes the other and sometimes a bit of both.

How does it help us?

This is all very interesting but how does it help us?  I think  there are a few things we can learn. The first is that we are asking people to be both independent self-starters and great team players in the same breath. I am not sure those of us that have been in this space for a while can remember how tough these two skills are to learn and how often at first they feel like they conflict with each other.

Most people grow up with parents setting boundaries and stepping in when needed, or teachers setting clear guidelines.  Most jobs have someone checking to ensure you are clear what you need to do and to ensure you are following through on your responsibilities. So taking that away with no support mechanism is risky. Even people used to making suggestions still expect someone else to decide. And worst of all most people grow up believing that making mistakes is a bad thing. You cannot expect people to unlearn these behaviours over night simply because we believe self-organised teams are great.

Ask someone if they would rather not have a boss and they will jump at the chance, that is until they realize that not having a boss means accepting all their boss’s responsibilities.

What we can learn from this?

  1. If you can avoid it do not have teams greater that 8 people.  Communication and decision making are significantly improved. Bystander syndrome is reduced and responsibility increased.
  2. Ask yourself – do you really need a Manager, or a Team Lead or a Project Manager for this team?  What role do they provide that the team alone cannot?  If the reason is a question of trust or the skill level of the team, what can be done to resolve that? If a team ‘needs’ someone to manage them, I’d suggest this is a sign of other deeper issues.
  3. Self-organizing teams require new and different skills, these are learnt skills and will take time to master. Provide support and guidance and let the team learn them. Be on the look out for emergent leaders or martyrs and help the team become aware of them too.
  4. Visualizing work is one of the most powerful ways I have encountered for reinforcing awareness and acceptance of responsibilities. A kanban board is far more effective than any status report or project plan.
  5. Mistakes are powerful learning tools. Help the team learn to fail safely. Hold regular retrospectives and celebrate the mistakes, find new and better ways to work as a team.

My final thought is that there are many things a team can do on their own, I believe that with the right support, training and experience a team can function almost independently. Certainly without the need for middle management or project management. But that doesn’t mean it will be easy, or that you can simply pull the manager and step back.

Scrum introduces a Scrum Master as a transitional role to guide the team towards independence, and Agile Coaches may do the same in other environments but more likely in a less structured manner, but in both cases the goal is to create independent self-organised and continually improving teams.

 

 

Building on the foundations of Joy

I have recently finished reading the book Joy Inc. by Richard Sheridan which is the story of a small software company that has been successful, most notably as being a great place to work. The CEO had come from a an extremely successful start to his career, he had been promoted up the greasy pole to VP of software for an established firm and he had become wealthy in the process. By most conventional accounts he was a success, but he wasn’t happy.  He made a decision to change his work environment with a focus on creating a place that made him happy to come to work. This single minded goal eventually led to the forming of a software company – Menlo – with him as CEO where he could create a place of work that brought him ‘Joy’.

For those familiar with the work of Ayn Rand, I found a great many correlations between Richard Sheridan and Howard Roarke from ‘The Fountainhead’.  Rich Sheridan had a very single minded vision and he chose the path his company would take without compromising on his views. The book portrays how he set the direction and imposed his plan of how things should be done, resulting in a company that has adopted many of the XP practices described by Kent Beck.  The business has been successful and the workers are happy, Pair Programming, short iterations, innovative software solutions and a focus on quality.  The workplace includes dogs and babies and sound like a fun environment. In many respects at first appearance this is a model that we could learn a lot from.

Rich Sheridan has demonstrated the effectiveness of using Agile Practices and that success doesn’t require death marches and unrealistic expectations. Rich has shown one way it can be done, and there is a lot to admire in how he has achieved it. There is certainly a lot to learn and I think there are a great many aspects of what he has done at Menlo that could be used as the foundations of creating a great company.

I don’t build in order to have clients, I have clients in order to build…

Ayn Rand

However, much as I admire Rich and see him as a modern day Howard Roark, it is because of that comparison that I also have a number of reservations.  Rich himself refers to the book “Good to Great” and he acknowledges that he is not a Level 5 leader, this was an assessment I shared whilst reading the book. All his decisions were about creating Joy for himself, but there were dozens of examples in the book of absolutes, where his vision may not be compromised. I got the impression that he made all the decisions, he decided a process and it must be followed, if someone wanted something – such as the wonderful example of babies in the office – they asked him. The decision to allow babies in the office seems to be as much about wanting to be regarded as a great boss as anything else. That is not a bad thing but I am assessing this in terms of a model that can be replicated. 

Rich is uncompromising in his objectivism and Ayn Rand would be proud. Which is only half a compliment, I always admired Howard Roark, for a while he was an inspiration for me, but at some point I realised that taking input from others didn’t automatically mean you were compromising your principles or were weak, we can learn and adapt and improve but still stay faithful to our principles.

Recruitment and single person decision making

His recruitment policy is a great example of what I see as this type of blinkered thinking. Rich has introduced a recruitment policy designed to prevent making mistakes in hiring.  The problem is that his solution is to require two separate interview days, and then a 3-week trial, and after this they make a decision and the vast majority will be unsuccessful.  Anyone else see the flaws in this? 

To get hired you must give up 17 days for one interview. For most people with jobs that is not even close to being possible, and for an good candidate looking they will likely have multiple options open to them and this level of barriers to entry makes it highly unlikely that any good candidate would bother or be able to apply.  Therefore he is limiting his recruitment to the unemployed and graduates that are able to meet his interview requirements.  Now this pool will contain some good (if inexperienced) candidates, but the process has excluded so many other great candidates that I think it is an example of a process that has forgotten what the problem is that it is trying to solve. In this case I assume to hire great employees.

He clearly loves face to face communication and paper based systems and estimation using hours. Therefore everyone must comply, everyone must communicate face to face, they may only use paper based processes and must use hours for estimation. It is not that I am questioning whether the decisions are good or bad, clearly he is getting many right – he wouldn’t be successful otherwise, but it is a company built around a single individual. He is seemingly a strong CEO and charismatic leader, but that leads to an unsustainable business model, where does it leave Menlo when he moves on? What is his succession plan?

Using Agile practices doesn’t make you agile

Menlo use a variety of Agile practices, mostly from XP, but from the way the book describes it they are a set of rules fixed in stone, thou shalt do it this way…

The practices chosen are good practices, but I don’t think that Agile is about using best practices, I think it is about a mindset of improvement. Menlo had adopted a variety of practices that generally I support and endorse, but I didn’t get any sense that there was a culture of reflecting and improvement. Retrospectives did not seem to be part of the accepted practices at Menlo.  This for me was the saddest omission, without retrospectives Agile is weak and ultimately cannot survive in the long run. Menlo seem to have adopted 11 of the 12 principles, but it is the 12th that I value most.

I so wanted to enjoy this book, it is one I had looked forward to reading for a while, but in the end I was left feeling that Menlo was actually on the wrong path. Not that using XP was wrong, but if you have a culture that is not always seeking to improve it will eventually fail. 

I probably sound horribly hubristic, and I have not achieved the level of success Rich Sheridan has, so this may sound hollow.  But Rich, please introduce retrospectives into your culture before it is too late and be prepared to let your teams guide you to improve, you may me amazed to find they have some great ideas. If you do I think you may find a way to improve on the Joy you have already found.