A 3-pipe problem

Sherlock Holmes was a master of deductive reasoning and problem solving, rarely was a problem beyond his capability. However, every once in a while he encountered problems that required a greater level of consideration, it would stretch his mind to it’s limits and required him not to be disturbed for an extended period, he described these as 3-pipe problems, he would need the time it took for him to smoke three pipes.

IMG_0640

I am no Holmes but I have the joy of a 3-pipe problem to immerse myself in. I have been asked to lead an endeavour to create, build and run a virtual office comprising of cross-functional teams that create software. The challenge is to grow an office but maintain agility, retain our company culture, and have the teams happy and engaged. Oh and be profitable too.

Where I have seen remote work successful in the past has been where there were clear tasks assigned and collaboration was a minor element of the work. My observations of many remote workplaces is that they focus on individual contributions, collaboration is asynchronous and there is a heavy overhead of management assigning tasks.

What I am envisioning is a workplace where the team is self organised, and whilst there is likely an increased element of asynchronous working it will be alongside effective collaboration. I see my role as identifying healthy boundaries that enable collaboration and creativity.

36509555 - remote work or global wi-fi internet connection

Communication

Naturally communication is key, just as it is in brick and mortar offices, but when we are face to face we have a lifetime of skills to rely on. Instinctive awareness of body language, sensing mood and tone, not to mention touch – hand shakes and physical contact create bonds we don’t fully understand.

Remote teams communicating effectively is far more complex than simply joining a webex. I see the ability to communicate and collaborate as the number 1 challenge of this role.

Why this?

As an agile coach I strongly support the Agile manifesto (alongside Lean, ToC, and Lean Startup) and the manifesto favours individuals and interactions over processes and tools. It also advocates face to face communication. And yet I am taking on a role that is putting barriers between people and pretty soon I’ll be talking about how processes tools are vital for enhancing individuals in their interactions.

So why take on a job that seemingly flies in the face of this? The answer is twofold, First I believe the manifesto is a mindset for guiding teams in improving their way of working to get better at delivering software. I believe we can adhere to that mindset in this environment, I don’t see a conflict. Secondly I think that the focus and scope of the manifesto didn’t consider the larger picture and the changing state of the workers needs. Face to face is better – no argument from me, but it comes at a cost. We need to weigh up what is lost and what is gained from remote working and decide if what we gain is worth the sacrifice and I think with the right attitude, training and tools the desired outcome of effective collaboration can still be achieved and achieved in a way that is better for many team members.

What is more, I think this will be one of the most challenging coaching roles I have faced. Just like teams, coaching is far more effective face to face. The coaching may take on a different dynamic but I still very much see this as a coaching role.

Processes and Tools.

I warned you! To have effective communication and collaboration in a virtual workplace processes and tools are vital ,and are a prerequisite to the individuals and their interactions. But I don’t see a conflict here, in face to face communication there are processes and tools, we just don’t feel the need to mention them as they are natural to us.

Don’t shout, don’t mumble, don’t interrupt, pay attention, look at the speaker, be respectful. Lots of processes and a lot of non-verbal communication. And just watch for hand gestures or pens on post-it’s or whiteboards these are all tools, we hardly consider them that way and we certainly wouldn’t object to any of those processes or tools, they are necessary for our interactions.

In a virtual world the need is the same but the tools are different, tone of voice and body language are harder to decipher, so we need to be more attentive and more explicit. pen and paper are replaced with online collaboration tools, shared screens, electronic gestures and Slack messages to clarify misunderstandings.

IMG_0639

The scope of the task is daunting but I so excited about this. My employer is already a leader in Agile software delivery, this is the chance to demonstrate that we can be agile about flexible work environments without sacrificing what has made us successful: collaboration and self-organization.

This blog will continue to be Agile focused but I’ll also share some of the experiments as we discover what works for us.

Advertisements

Rewarding voluntary overtime.

I was chatting to a friend recently, he is a manager of an IT department and I used to manage a software department before I became a Agile Coach so we tend to talk a lot about management techniques and especially how a lot of the successful traditional techniques map to an agile work environment.

It was performance review time and the topic of conversation got around to a frustrating belief by some staff that working long hours without being asked is something that should have an implied reward. That working long hours is in itself a reason to be praised.

clock

Warning signs

I can’t speak for all managers, but for the two of us I can say that we consider it to be the opposite, when someone works late on a regular basis without being asked, we see that as a bad thing, it is a red-flag. Certainly not to be commended and very likely a sign of deeper problems.

I used to pride myself on being a good manager, I felt I was fair and sought to do what was best for my employees and the business, sometimes it was a fine line and often not easy. But one of my strongest principles was to be fair. I would never assign someone more work than I felt they could handle (that is not to say I didn’t seek to challenge them), I would generally discuss in advance what they felt was fair and I would always say very clearly that they should come back to me if they had problems, and I would review on a regular basis – usually at least weekly.

As an Agile Coach I have obviously changed my behaviour a lot and learned so much along the way but generally speaking it could be said that the roles are reversed, the team decide what they feel they can commit to and they review with each other on a regular basis (at the daily stand-up) and can ask if they need help, they should assign themselves small chunks of work and no more than can be reasonably achieved.

Salary man working overtime Overload. Cartoon Illustration.

Have I assigned too much?

In either of these scenarios there should be no scope for voluntary, unpaid, overtime.  In the case of assigned work: if you cannot get it done in the allotted time then it is a failure of my management – either I have incorrectly assessed the amount of work or I have misjudged the individuals capability to do it, and unless I have opportunity to be aware of that I cannot correct my behaviour and the cycle will repeat.

The same is true in Agile, whichever chosen framework you use the model is built on empirical evidence, if your forecasts are off you learn and adjust next time. Working overtime hides problems and perpetuates failing cycles, it also causes an imbalance in the team, it makes pair programming difficult and sends mixed messages to others. Very simply as a team manager or a self-organizing Team you cannot fix a problem you don’t know about.  Overtime is analogous to cards not on the board, it is hiding work, this is very damaging to a self-organising team.

Rewarding bad behaviour

So should you reward someone for working late, for their dedication and loyalty? or should they be reprimanded for their lack of transparency, or their inefficiency of working? Are they displaying a lack of courage in not challenging an unrealistic expectation? Are they stretching work to appear more busy? Should we reward their failure to communicate an excessive workload, or for failing to ask for help with their lack of knowledge/training/understanding to achieve the objective at hand?

As a manager if I ask you to work overtime I would do so with a very heavy heart, I know that it is not good for you, I know it is not good for the business and any gain is short-term and short-lived. It will only be in exceptional circumstances, where there is justification or benefit in working overtime.

As a member of a self-organizing team you should set those same standards for yourself: You should know that it is not good for you or the team, You should know it is not good for the business and any gain is short-lived.

So if you do voluntary overtime which conflicts with our team plans or expectations please don’t expect to be rewarded for it. That may sound harsh but I value communication far more than I value you giving extra time, especially if by doing so it is hiding problems elsewhere that we could and should be addressing.

overtime

Clarification

This is not a call to work to rule, this is a request to understand the difference between being a team player and expecting recognition and reward for setting yourself up as a martyr. By doing so, try to understand that you are working against the interests of the team, this is not behaviour we should be rewarding.

Sometimes it is necessary to work overtime but this should be a deliberate team decision with a clear objective. It should be open and transparent and should not be one person acting alone.

*Note when I saw reward, this is everything from a positive comment from leadership to financial reward. Sometimes leadership even acknowledging this behaviour is seen as a reward, the belief that your actions were noticed is quite an incentive for some.

Explaining Herbie…

I have been asked by a friend to write an article explaining the concepts of Herbie from the book “The Goal” in a more accessible way. The book itself is amazing but in my opinion the language used in the 5-focusing steps has tried too hard to be scientific and precise that it makes it harder to understand. My annotations simplify the terms but likely lose some of the precision of the wording, I offer this as an introduction to the topic but encourage reading the book to get the full impact, I cannot do it justice here.

DHO_0coVwAEzcDl

Herbie is a character from the book “The Goal” he was used in the story as a metaphor for a system constraint and the impact it has on your delivery. I’d highly encourage you to read the book but hopefully it is not essential to be able to follow the explanation, the purpose of the metaphor was to make the thought processes relate-able, hopefully this helps.

TOC 5 Steps

The 5 focusing steps

  1. Identify the system constraint
  2. Exploit the constraint
    (Make the best use of what you currently have)
  3. Subordinate everything to the constraint
    (Make decisions based on the constraint, the system should run at the pace of the constraint)
  4. Elevate the constraint
    (Make improvements to the constraint)
  5. Repeat the steps

Step 1: Identify the constraint

We need to figure out which part of the system is holding us back the most – limiting our ability.  We should know that only an improvement at the constraint makes a difference.

Herbie: In the example of Herbie, he was observed as holding everyone back he was slow and the rest of the group had to regularly stop to wait for him to catch up or were racing ahead.  In the case of Herbie the constraint was evident through observation.

download2

Reality:  There are different ways to identify a system constraint sometimes observation and experience is sufficient, or metrics can help.  The simplest way is to look at your work is it piling up somewhere? Do you have a lot of stories in Dev Done, or waiting on PO approval or needing wire-frames? Piles of work are a sign of a constraint.

Another common constraint are blockers, if you are consistently waiting on another team, another person or another resource this is a sign of a constraint, we may use blocker clustering or other root-cause technique to see if there is a common theme to delays.

The third most common technique is to review cycle-time for stories, look for stories that are taking longer than others see if there is a pattern, common aspects, this could be a constraint that may be improved.

Step 2: Exploit the constraint (Optimize)

Before we consider adding capacity, we should make the best use of the capacity we already have. We ‘Exploit’ in this sense means doing everything possible to use the constraint to its fullest capacity. This is also the easiest and generally cheapest improvement you can make to your system.

Herbie: In order to maximise the performance of Herbie, the contents of his backpack were shared out so he could concentrate on the most important task of walking.  Making the others slower (less efficient) by carrying his stuff was unimportant as Herbie sets the pace for the entire group.

We could also have ensured that he got his lunch first so could start sooner, and others could have covered his chores so he was more rested – our goal is to get the best out of Herbie on his most important task – walking.

Reality: In our systems we need to identify what the most important task is, typically this is getting a story to done and the software in the hands of the user.  So when you identify your constraint look for anything they are doing that is not helping to move stories or for anything they are doing that someone else could do. Are they filling in paperwork that someone else could do? does this task really require their expertise? Could you make them a coffee so they could focus. (This is not encouragement to over-work, breaks socialising and generally a healthy working environment always takes priority).

 

WheresHerbie

Step 3: Subordinate the non-constraints

The job of all non-constraints is to subordinate their decisions to the constraint’s needs.

That sounds extreme wording but essentially it means that no mater how fast you go, if you are dependent on someone slower you are wasting your efforts, so work at the pace of the constraint, you have reserves so you can catch-up if necessary.  Use the time saved to help optimize the rest of the system.

We do this as step 3 because it is more disruptive and more costly than step 2.

Herbie: In the story Herbie was put at the front and the rest of the group were told not to overtake him. When Herbie was able to go faster there was no one in front to delay him so we got the best from him and as the others were able to go faster overall they were able to make up any delays. The goal was only achieved when everyone was done so there is no benefit in getting ahead.

Reality: Don’t let work pile up, if we limit Work in progress we focus on flow rather than utilization, put effort where it has most impact on the whole system.  In the case of dependencies on 3rd parties, could you give them advance notice so they are better prepared and can respond sooner. If you are dependent on a 3rd party could you see if there is a time/day they can respond more quickly, could you tailor your process to be more convenient for them? Tailor your process to maximise the effectiveness of the constraint, and this is the tough bit – even if that means making the process worse for others.

Tailor your process to maximise the effectiveness of the constraint,  even if that means making the process worse for others.

Step 4: Elevate the constraint

Only once we’ve completed the previous steps does it make sense to add more constraint capacity, and thereby increase system performance. Because adding capacity is tremendously expensive in terms of time and money, we do it as a last resort, not a first step.

Herbie: In the case of Herbie, we could get him doing fitness training so he is quicker, or buy him a bicycle.

Reality:  This is typically where you spend money, hire more people, get better/more equipment. Invest in training or education. Remember improvements here improve your entire system so the investment must be calculated based on system income not local costs. Maybe you ship parts by air, maybe you fly in an expensive expert, maybe you lose money on this aspect of a project so that the project as a whole makes more money. Keep the focus on the gain to the entire system and not get distracted by the cost at one stage.

Step 5: Return to step 1

The inevitable result of the first four steps, and the reason this is a “continuous” improvement method, is that the constraint will inevitably move somewhere else.

This step insists that you start back at the beginning, and don’t let inertia become the constraint.

 

choosing-a-doctor

A second example of the steps being applied…

 

Identify

Access to overworked Doctors in an emergency – constraint is a shortage of Doctors:

Exploit: Make the best use of what you currently have

  • Ensure Doctor is not doing any activity that someone else could do. All admin work is removed, prep work done by nurses or other staff.
  • Vacations/time off is deferred,
  • Doctors may work overtime so long as it doesn’t risk the patient or cause the Doctor to quit

Subordinate: Make decisions based on the constraint, the system should run at the pace of the constraint

  • Any non-urgent treatment is stopped until emergency is over.
  • Cases are prioritized so Doctors are only working on the most urgent cases.
  • Patients are only ‘prepped’ according to the capacity of the Doctors.
  • Patients are prepped in advance so that the Doctor is never waiting.
  • It may be quicker for a Doctor to move between patients rather than them coming to the Doctor.

Elevate: Make improvements to the constraint

Now we look to increase the number of Doctors or their effectiveness

  • transferring Doctors from other areas withing the organisation
  • recruiting more Doctors even at inflated rates or short term contracts,
  • any increase is an increase so we can hire someone that is semi-retired or part-time.
  • We may automate activities or buy tools to improve the efficiency and effectiveness of the doctor.
  • We could train Nurse to perform some of the Doctor’s activities

Repeat

We look and see whether the Doctors are still the constraint or whether there is a new constraint.

 

Summary:

There may be a little ambiguity with some of these improvements, e.g. A Doctor moving between patients may be considered elevating or subordinating, but it doesn’t matter it is an improvement, it is a thinking process and some changes don’t neatly fit into one category, don’t let that distract you from the thinking process itself.

 

9780815385134


The Goal by Eli Goldratt

This book uses a production plant as a metaphor for delivering value to your customers. The emphasis is on the manufacturing equivalent of delivering working software, doing it regularly, and that delivery is not about development, OR production OR deployment it is about everything – essentially encouraging Dev Ops.  It also has a lot to say about how the only Done that matters is to have it in your customers’ hands.

Read it!  This is hands down the best book on Agility I have ever read.  There are many others by this author all of which are great but this is my favourite.

Isn’t it obvious?

I occasionally get asked why and how I became an Agile Coach and whether it is a fulfilling role. When I began my career I certainly had no intention or expectation to be here, I was a software developer, I loved writing code and like most developers I wanted to create something that made a difference.

What followed was 15 years of… I want to say frustration but that is unfair because I generally loved my work and got to create some great software, but I always had this belief that there was a better way, a more effective way to get the job done, I dabbled in project management and team management believing I could do better than those I had worked for in the past.  My problem and I suspect it is a very common problem is that I spent a lot of effort trying to do my job better, to be more efficient, more effective, to deliver more etc. etc. It turns out that was wrong and I was wasting a lot of effort and not getting the results I expected.

deadly-assumptions

And then quite by accident (and for all the wrong reasons) I stumbled on to Scrum. I was running a software department and we were forever fire-fighting and I saw Scrum as a tool I could use to control the workflow and manage the demands on the team. It worked, and in the breathing room it created I was inspired to look deeper, beyond Scrum to Agile, and then Lean and Systems thinking and the Theory of Constraints and then I saw it. I felt like I had discovered the meaning of the universe, and once you see it you can’t un-see it, you see it everywhere, it feels like it is staring you in the face.

There is nothing more deceptive than an obvious fact. 
― Arthur Conan Doyle

c770ba6b2c578be3db267493229de2dc

Of course I hadn’t discovered anything, I had just opened my eyes and it was right there in front of me and it was so unbelievably obvious that it almost feels stupid writing this.

And it is this simple:

All we have to do is work on the thing that adds the most value and stop working on things that don’t add value.

Work on the thing that adds the most value and stop working on things that don’t add value.

So I said it was simple but it took me 15 years to start to understand it and nearly 10 years later I am still figuring it out, because whilst it is so simple that it should have been obvious all along, it is also remarkably difficult to do.

What is Value?

The primary problem is to understand what value is. figuring out your value stream in a system is key, and to be fair most businesses do this to some extent, but most individuals do not understand how they fit into the system they are in, nor do they understand how their local system fits into the big picture.

We cannot see the value we contribute to the system and when we don’t see what is most valuable, we do what we see as most valuable in our line of sight. Crazy as that sounds it is nearly always the wrong thing, optimizing for us nearly always optimizes against the larger system. The bigger the organisation the more this happens and the more inefficient it gets.

opportunity cost

  • the loss of potential gain from other alternatives when one alternative is chosen.

Another aspect is that so much value is obfuscated, it gets lost in opportunity cost which is invisible on balance sheets and yet is likely the biggest cost you pay when developing software. Or cash flow, leverage and return on investment, these are fundamental aspects of successful business but they are generally encapsulated and decoupled from the parts of the business that can impact them most – especially IT and software product development. Many projects get given budgets and time lines, which is a horrible way to run a business and it cripples cash flow, it also significantly limits investment opportunities and increases risk significantly.  But worst of all it delays delivering value.

Two Problems

So that is actually two problems, first is that we need to figure out what is valuable and then we have to communicate that to those doing the work.

In that sentence is the heart of being an Agile Coach, my role has become one of helping organisations understand their value stream, especially how software impacts and interacts with it, helping visualise that value and prioritise it and then to help communicate that to those that will create the software and deliver that value as quickly as possible.

  • Discover what our goal is – how do we deliver value? What outcome are we trying to achieve? 
  • Communicate that to everyone so we each know how we help to get towards the goal and how we avoid getting in the way.

 

Unfortunately the majority of the time is spent dealing with people that are just like I was, they are doing their very best to be as efficient and possible in their domain, simply because they cannot trace what they are doing to the value delivered.  So I spend much of my time doing my best to help them see that often what they are doing is at best not achieving anything useful and more often is actually damaging to the bigger picture.

Example

victoriaspongecomet

Let me give an example that a friend of mine shared recently:  My friend was baking some cakes for an event and needed to bake 10 cakes, but only had one oven. Her husband offered to help out and so she asked him to measure out the ingredients for the cakes in advance so that it would be quicker to get the next cake in the oven.

When she came to get the ingredients for the cake, they were not ready, her husband had optimised for himself and not for the goal.  He concluded it would be much more efficient for him to measure out 10 batches of flour then 10 of… etc.  after all he knew they would be needed later and it was quicker and far more efficient for him to do that than to do small batches and keep switching.

The result was that whilst he was being efficient for himself, the system grinds to a halt and must wait, his efficiency came at the cost of massive losses to value delivery (cakes baked).

Perhaps if he had understood the full picture, and how his contribution impacted the value stream he would have planned his work differently? He would have prepared one cake at a time even though it was less efficient for him. Together they would have reached the true goal more quickly.

But the funniest part of this story for me was that she was so frustrated,  she thought it was obvious, and he thought he was being efficient.  Those opposing view points are so common in this line of work.

When you see it, it is obvious but until you do it remains an enigma.

Why be a coach?

doc

Now imagine that confusion on an industrial scale, a whole organisation of people conscientiously working hard in the belief they are being efficient but still struggling to deliver software, delivering software that is not what is wanted, features that are not needed, struggling with integration and so on.  Then this loony guy comes in and says that you might actually contribute more by being less efficient.  – I’m the loony guy and I love it.

Agile is a mindset for getting better at delivering software and coaching is about helping you. But my goal is not to help you improve just a part of the system, the goal is to help you improve the system, and that starts by helping you and the whole organisation see the system. and learn how to communicate where we can add value.

Obviously there is a lot more to Agile than communication and value, but in my experience if you figure those out the rest falls in to place.

—————————————

There are a handful of books that I repeatedly recommend, all of which display true Agility and yet to be contrary not one is about ‘Agile’

The Advantage by Patrick Lencioni 

This talks about being clear in your goal and how to communicate it to your organisation, it is not quite as specific as I am hinting at in the article as we must delve deeper but it is an amazing book and the emphasis is on over-communication.

The Goal by Eli Goldratt

This book uses a production plant as a metaphor for delivering value to your customers. The emphasis is on the manufacturing equivalent of delivering working software, doing it regularly, and that delivery is not about development, OR production OR deployment it is about everything – essentially encouraging Dev Ops.  It also has a lot to say about the non-sense of Dev-Done and how the only Done that matters is to have it in your customers’ hands.

Read it!  This is hands down the best book on Agility I have ever read.  There are many others by this author all of which are great but this is my favourite.

The 5-Dysfunctions of a Team by Patrick Lencioni

I wholeheartedly subscribe to the Lencioni school of thought on many things (hence two books by him in this short list). On team building this is one of the best books out there, it describes the stages of team development, and you see this time and time again. Team dynamics are such a crucial part of agility and fundamental to success, this helps teams see those stages and is a great tool for helping teams bond.

 

A tale of two engineers.

There are two ships traveling a busy shipping route, each ship has a complex engine and the engineering team has a chief engineer. Both ships are a similar age and size.

The first ship has a very busy chief engineer running this way and that, fixing any and every problem that comes up, he knows every inch of the engine and many parts of it are custom made by him. He is dirty and oily and hard working, whenever there is a problem – and there are many problems – he is on hand to fix it. He is dedicated and hard working, he works long hours and is always ready and willing to get his hands dirty. Without him the ship couldn’t function.

The second chief engineer has spent his time not fixing things, if a part is unreliable he has replaced it, if a component is troublesome it is gone. If there is a problem he ensures one of his team fixes it (with guidance initially) and will encourage them to spread the knowledge so that after a while he rarely if ever gets his hands dirty. He is rarely dirty or oily and it is a very rare situation to see him fixing anything. On many voyages he can seemingly sit there with his feet up doing very little in maintaining the ship and can use his time on other productive activities. Frankly if he missed a voyage the ship would probably run just fine without him.

Now which in your opinion is the better chief engineer?  I know which one I would rather have on my team.

It is often said that the goal of a good Scrum Master is to make themselves redundant, I take exception to this a little I think as in the tale above it is possible to create a situation where you are not necessarily needed all the time. But I wonder how long a team would last as a top-performing team if the Scrum Master was taken away, perhaps in the short term no one would notice, but growing and shaping and coaching a team takes time and effort, but slipping back into bad habits can happen quickly. Creating a situation where the Scrum Master has time to do other things is a good thing and a reflection of success not a sign he is not needed. A Scrum Master that is essential to a team is one that has failed, in fact if ever you feel you have an employee you are overly dependent on you have a serious issue.

How many top athletes would say “I’ve reached me peak I no longer need my coach”? My guess is that if they feel they have reached their peak they will seek out a new coach that can push those limits further.

A good coach or Scrum Master guides the team to independence, and then pushes their limits further.  They may be more useful elsewhere but that is very different from becoming redundant.

Never talk about politics!

I grew up in the UK but I have lived in the USA for a little over 6 years in total, which equates to around a quarter of my working life, so whilst I still feel very British there is an element of the mid-Atlantic creeping in. That is to say I feel like I have grown a level of understanding for some of the quirks of American culture and am a little more sympathetic to the perception of the UK culture from the American side of the pond.

us-uk-flags-union-english-18622380

However being so overtly British I get to hear the same questions repeatedly and some of the misinformation is a little troubling at times.  Especially when it can be fact checked so easily.  Since this is my soapbox I’ll indulge a little before I get on to the topic at hand.

First the USA did not win the war of 1812 please take 5 minutes to read wikipedia.  Second, the UK NHS: I have been in the USA for 6 years and in that time I have worked for two employers both of whom tell me that the health insurance they provide is the best there is. My colleagues tell me it is better than anywhere else they have ever worked. I have no reason to doubt that this is great Health Insurance, and apparently it costs around $27,000 per year – mostly paid by my employer and that is in addition to the social security deductions which are approximately 8% of my paycheque.

In my experience the quality of service offered by the ‘best‘ Health Insurance is approximately identical in quality of healthcare to that received from the NHS. Yep you heard me, I find no discernible difference in quality of care.  There are certainly differences, I have to pay a co-pay to see my Doctor here in the US which is free in the UK.  Doctors in the USA want to push you to take every test under the sun so they can bill the insurance, where in the UK they assess if there is a need first. In the USA if there is a referral it is on you, whereas in the UK your doctor would follow-up. The Doctors’ surgeries here seem to be a bit more lavish and they need an army of staff to administer the insurance bureaucracy but as far as wait times, quality of medical treatment and accessibility of treatment I see no difference.

So I do get a little upset when I say people describing the UK medical system as having poor treatment and long wait times and something to generally be afraid of.  Think of it as having the best medical insurance you can buy, and then imagine that it is free to you, I can see why that is so incomprehensible when you are used to spending nearly $30,000 per year on that service. I am sorry to say it so bluntly, but the USA spends on average 4 times as much for what is very much an inferior system for most people.

Okay I’m off-my NHS soap box now.

Capitalism or Socialism concept

But the third and most troubling perception that I am regularly confronted with is the notion that the UK is a ‘Socialist‘ country and the USA is a ‘Capitalist‘ country.  This notion troubled me a lot and got me thinking, but first let’s clarify the definitions:

Socialism:   political and economic theory of social organization that advocates that the means of production, distribution, and exchange should be owned or regulated by the community as a whole.     

Capitalism:  an economic and political system in which a country’s trade and industry are controlled by private owners for profit, rather than by the state.

Essentially the extent to which you are a capitalist or socialist country is determined by the extent to which the government interferes with the free market, either through spending or through legislation.

Measuring Capitalism

Spending is pretty easy to assess as we can see what proportion of GDP comes from government spending and how much from ‘the free market’  However, legislation is much harder to measure and by definition any intervention in the market is ‘socialist’.  E.g. Defence, immigration, policing, taxation, tariffs, subsidies, etc.

I think most people realize that pure socialism is fatally flawed and equally flawed is pure capitalism, so it is really a question of how little or how much government is needed and how much can the market provide on it’s own. We all have a reasonable expectation that infrastructure, defense, police, jails etc cannot be provided by the market and that the whole country benefits from education and healthcare for the poor as the benefits are far reaching to the economy but how much of the rest is open to debate.

Let’s take the USA, the US spends a staggering 35% of it’s GDP on socialist activities, that is more than a third, and is incredibly socialist in it’s government policies and legislation, just recently there have been some very high profile trade tariffs, a trade tariff is direct manipulation of the free market by the government – it is the very definition of socialism. Lobby groups regularly persuade the government to invest in particular parts of the country or legislate for the benefit of certain industries.  Both the UK and the USA bailed out banks and the USA bailed out the car industry and corn farmers.

By contrast the UK spends 41% of it’s GDP on socialist activities, and also heavily regulates the free-market with employment laws, they provide tax-breaks for entrepreneurs and subsidies for ‘green’ businesses to name a few, but notably didn’t bail out the car industry or steel industry or mining industry.

51c8d01b2deda.image

In my anecdotal experience and to be clear this is opinion based on only very limited education in Economics and Politics, neither the UK nor the USA has any claim on being capitalist countries,  both may claim to be slightly right of center but are both squarely ‘Mixed economies’ and have found a balance that is slightly further from Socialism than Capitalism but not by much. And whilst the UK spends more, my observance is that the USA regulates more and is far more interventionist in investing, bailing-out, propping up and otherwise supporting USA based industries.

TL:DR Summary: 

The UK and USA are broadly similar in terms of the degree to which they are Socialist or Capitalist in practical terms, but in my observation the UK is more willing to intervene for the benefit of the people – especially the poorer and the USA is more likely to intervene for the benefit of business.

What has this to do with Agile?

So what does that have to do with Agile?  Well it strikes me that there are a great many parallels.  If we equate Socialism – a planning heavy form of governance, where plans are made by a few experts:- with ‘Waterfall’  and  Capitalism – a responsive form of governance where the market leads and the many respond independently of governance:- with Agile,  then maybe you can see where I am headed.

download (2)

In small scale both Waterfall and Agile succeed, but as we scale both suffer in different ways.  In Waterfall as in Socialism the planners become further removed from the market they are serving and are less responsive to particular needs and more and more out of touch.  a great deal of overhead is needed to align the vision from the top and unsurprisingly they are often so far removed they get it wrong, corruption sets in and effectiveness (the true productivity) plummets.

By contrast in Agile as in Capitalism works very well in small scale but as we grow the decision makers are not able to see the big picture and whilst they are responsive to what they can see, they fail to see the larger system and optimize for themselves rather than the larger organization and problems set in with misalignment. There are some aspects of a business that simply don’t work by being responsive and need to be planned and organized.

Governance

So where does that leave us?  Well at heart I am both a capitalist and an Agilist so I am biased, but the way I see it as we scale with Agile and in business in general we discover that we need governance, some degree of consistency, infrastructure and support and most of all a clear direction.  But I believe we should keep that governance as small as practical and only govern that which we cannot govern ourselves.

In the case of big government I believe that includes socialised healthcare because normal market forces do not apply when it comes to our health and so the market cannot effectively provide what we need, I also believe that we should invest heavily in socialised education as better educated workers make everyone wealthier.

When it comes to Agile teams I don’t think the teams should do the hiring or decide pay and they don’t generally want or need to be bothered with administration or infrastructure, I feel that is governance that they should be spared, similarly I think ‘health care’ such as vacation, benefits, and support (HR) is governance. Start-ups will need to deal with all of this but at scale we shouldn’t have to.  Nothing controversial so far, but where we may start to see differences of opinion is the level of governance needed for teams.

In my opinion we achieve the best results from small teams, that are given clear direction and are empowered and enabled, that means direction not a director, so team leaders, project managers or any other similar role is bad for teams, it is unnecessary governance and is in my opinion fundamentally anti-agile.

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

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

That doesn’t mean we don’t need managers or leaders, but we don’t need them involved in the work.  In Scrum we empower Product Owners to set direction and priorities but they stay out of the HOW, we empower Scrum Masters to coach us on process and guide us on improving flow, we even empower them to remove impediments on our behalf but we do not empower them to tell us HOW to do the job.  In my opinion Project Managers (when they are deemed necessary) should respond to information provided by the team and not the other way round, they are a consumer of information only! They should convey no authority.

12625104-no-managers

Where we need managers is NOT for doing the work, a suitably cross-functional team should be able to do that without an anointed leader.  What we need managers for is the ability to create those cross functional teams, and do this by listening to what is needed, hiring and enabling the forming of those teams.  We need leadership to provide clarity of direction, clarity of culture and clarity of values. We need managers to help us by enabling us grow as individuals in our individual careers in parallel to our goals for the team. We need managers for ensuring that we as an organisation are planning for the future so we can focus on delivering in the present.

If you feel you need a manager to manage the team doing the work then in my opinion you have failed elsewhere, it is a sticking plaster to a bigger problem, all you are doing by instilling team leaders/Project managers or team managers on a delivery team is masking a bigger problem elsewhere, possibly in hiring, training, education or communication.

The prime role of leadership is ensuring clarity, they have the big picture, making sure their employees see it too should be their number one goal, any other governance in the day to day job is an unnecessary overhead and a smell that there are problems elsewhere. The corruption inherent in larger systems needs to be cut out at the source not covered up with a layer of management. If you are hiring the wrong people then fix your hiring process, don’t hire people to manage problem staff. If you are struggling with consistency or maintaining values then it is an issue for education and clarity, putting a manager on as team is not the solution: enforcing values is not the same as instilling values.

90ee2b65615c3fda2b2c4190697c34d4

In Agile, like Capitalism, we want government to be as small as possible and only get involved in things that we either can’t do ourselves or are necessary but unrelated to our day to day work. Unnecessary bureaucracy and governance are well, unnecessary.

Give them the environment and support they need, and trust them to get the job done.

Hire the right people and let us do our job, educate don’t regulate, enable don’t enforce,  but most of all trust us, don’t try to control us. Set a direction, then get out of our way.

 

 

Feedback is not a passive activity

In Lean manufacturing setting up feedback loops is considered a critical part of the operation, so much so there is a term for this – Andon – a system to notify management, maintenance, and other workers of a quality or process problem.

download (1)

The principle is that it gives the worker the ability, and moreover the empowerment, to stop production when a defect is found, and immediately call for assistance.  Workers are encouraged to use this feedback mechanism freely. Common reasons for manual activation of the Andon are part shortage (dependency), defect created or found, stoppage, or the existence of a safety problem. Work is generally stopped until a solution has been found.

Loosely translated an Andon is a Paper Lantern – To shine a light on a problem.

andon

Sounds great in principle, any worker is empowered to give feedback to management if they have concerns over safety quality or even a weakness in a process, but for it to become culture it needs to be adopted in a no-blame manner and used frequently, lack of utilization of an Andon is a serious problem and is addressed in Lean.

If a feedback mechanism is not triggered regularly then the settings are considered too loose.  The threshold for triggering an Andon would continually be made tighter and tighter, quality is expected to be higher, time for a task is squeezed and so on until there is an increase in frequency of Andon being used.

The aim is to get a regular feedback of actionable information, too little and the feedback loop has failed, too much and you cannot see the problem so it needs tuning and adjusting slowly.

What does that mean to us in a non-manufacturing environment?

We have got pretty good at retrospectives and giving feedback locally, but feedback to management is largely absent.

devops

The difficulty in many organizations is that senior management hide behind an open door policy.  “Employees can talk to me any time, my door is always open”. It is very easy to pretend you are open to feedback but much harder to actually be open.

“Employees can talk to me at any time, my door is always open”

– the unapproachable manager

In many cases the open door is actually an invisible barricade: fear of retribution, fear of not being supported, fear of being ignored, fear of the messenger being shot.  In many cases the fear is justified,  but even when it isn’t, it doesn’t make the fear any less real to those with genuine feedback to share.

Creating Feedback Loops

Just like with Andon, this is feedback that should be sought and encouraged and your measure should be how frequently you are given constructive feedback from your employees, if you are challenged regularly and respond to it regularly then it is working, but if you are not getting regular feedback (from those outside your inner circle) then it is likely your “open door”  is not that open.

opendoor

Has someone in the last week given you critical feedback without being asked?

If on the occasions you do explicitly ask for feedback are you bombarded with hostile questions? Do the questions catch you by surprise? Do people seem dis-satisfied with your responses? Do you only ask for feedback when people quit? If yes then perhaps you are not asking for feedback often enough, or are not responding to the feedback you are getting.

Feedback is not passive

Feedback is generally not passive, you need to invite it, create forums where feedback is invited and expected, be open to the feedback and when you are not willing to change be prepared to explain yourself, and be prepared to repeat yourself.

It really comes down to whether you truly are a feedback culture, if you are you have to work for it.