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.

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.

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.

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.

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.

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.

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.

Mindset or method?

Straw poll:

Should we teach practices and methods in the belief that an Agile mindset will evolve from the good practices?

Should we teach an Agile Mindset in the hope that with an Agile Mindset good practices will emerge?

I know of a few Scrum Masters and a few Agile Coaches in each camp, and some that feel very strongly on this topic. And of course the choice lies at the heart of most Agile Transformations and the outcome will therefore be far reaching.

Method over Mindset

Around 10 or 11 years ago I was introduced to a new way of managing projects and a new software tool for doing it. I was trained in how to use the software, but not in the theory behind the tool.

We are what we repeatedly do. Excellence, then is not an act but a habit.

– Aristotle

The tool was amazing, it really blew my mind. As a Project Management tool/method it made more sense than anything I had used previously and I loved it, I happily used the tool and got good results. But despite having the tool I never learned the theory and didn’t even know where to look to find out more. No lack of interest or enthusiasm but I was content to use the methods and it helped in my current situation but I was never able to make the leap to more than a method despite my enthusiasm.

It is a little beside the point but the tool was Critical Chain for Project Management and before I was introduced to Agile I thought this was the best option out there for Waterfall projects (probably still is). Sadly despite it being so great, it was still based on the assumption that the end state was known at the start of the project, which for me is the ultimate failure of Waterfall thinking, and my primary reason for moving to Agile.

Only much later did I discover the theory behind the tool was The Theory of Constraints and the 5 focusing steps, IF only I had been shown that and I feel my enlightenment would have come much sooner. But a method without understanding the theory leaves you unable to adapt and improve, I was limited to the context in which I was shown.

What is more I had a co-worker that struggled with the concept of slack and wanted to follow the method apart from that one aspect – the lack of understanding left him unable to differentiate between a necessary aspect of the method and an arbitrary one, and ultimately for him the tool didn’t work because he rejected the necessity for slack.

A lack of understanding of the theory leaves you unable to differentiate between a necessary aspect of a method and an arbitrary one.

– John Yorke

Method over Mindset, the Return on Investment

Another consideration is that teaching theory takes considerably longer and has a much lower conversion rate. That is to say that I could teach the Scrum framework fairly quickly – a matter of days, and be pretty confident that the instructions are clear and ‘could’ be followed effectively. To take that same group and to teach them the theory to the point of understanding the why behind each of the practices could take weeks or months, and likely longer before they are fully understood. It is also possible that some will never grasp the theory but are still perfectly capable of being good team players.

Continuous improvement is better than delayed perfection

– Mark Twain

Many organizations are interested in the short-term results rather than long-term understanding and so there is a desire to do the least for the most impact. So we see the evolution of phrases like ‘Scrum-but’ as a means to discourage deviation from the defined framework. Our goal becomes to repeat, rather than understand.

Mindset over Method

If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea!

– Antoine de Saint-Exupéry

The flip side of this is the desire to teach/show the impact of having an Agile Mindset and then having the individuals identify a solution using that knowledge.

Clearly this is a much greater challenge, even those with an Agile Mindset will initially lack any practical applications to draw upon, even the most Agile of mindsets is limited to what they have experienced or read about, and contriving a new bespoke process to your environment may ultimately be the most desirable solution. However, it is impeded by the ability to share that vision and understanding with others, and limited by your understanding, ability and creativity. And frankly do we really think that we are able to come up with a better framework than Kanban or Scrum on our first pass at an Agile Transformation?

A middle ground?

As you have probably guessed I am not a fan of either approach. I believe that most people will not become Agile overnight and even the most eager of minds will take time to absorb and understand the implications and possibilities of Agile.

I further believe that teaching Scrum as a closed framework that must not ever be deviated from is not the solution. Instead I would compare it to learning any new skill, we teach good practices and when you have mastered them you are ready to move on, we may teach a variety of good practices so you have some comprehension of the possibilities available, that way you do not limit your thinking so just one solution.

But we learn to master the basics, and we learn to question ‘why?’ when we feel we have mastered the basics and we understand why, only then we are in a position to start to evolve.

Applying Lean and XP and Kanban to the Scrum framework can let you grow in understanding within a safe set of guidelines. And when you understand the mindset enough to comprehend the limitations then maybe you are ready to craft your own solution.

If you can’t explain it to a six year old, you don’t understand it yourself.

― Albert Einstein

Why I recommend Scrum

Personally I love Scrum as a foundation for a transformation to Agile for those undertaking software development projects, not because I believe it is better than Kanban or other tools, but because to succeed with Kanban you need a level of self-discipline and understanding that is often absent for those new to Agile, and it becomes far to easy to gold plate or run long.

Scrum adds some safety nets and feedback loops that counter many of the usual “human nature” problems that arise from teams new to self-organization. Self-organization is a skill we need to learn and develop like any other. Scrum is so simple to learn, and easy to follow (if you are willing) and once you understand the Agile mindset it is a great framework for evolving into a great Agile team. But like any tool if used inappropriately you can make a mess. But any change requires a good guide.

That being said for support or reactive work Kanban is ideal as the discipline generally comes from outside. It is never a one size fits all.

Method without mindset can only take you so far

Teaching the mechanics without teaching the theory is only half the task and whilst it is sufficient for many consultants to get paid, what they leave behind is a culture unable to improve, and without improvement entropy will set in. I believe both some guidance on the mindset and instruction in some methods are both necessary for a successful Agile Transformation, along with a healthy amount of enthusiasm and patience from those leading the transformation.

Henry Ford – Master of flow

I have recently been presenting a talk on WiP limits and as part of my research I spent some time looking into the history of Henry Ford as he was one of the most influential pioneers of what today we would call Lean or Kanban. He was the pioneer of almost all of our current thinking in industry, and I think was a thought leader in how Agile Software Development is now done.

Theory of Constraints in action

What really struck me however, was how he exemplified the thinking processes behind the Theory of Constraints in all his actions. Everything I read drew me back to that thought.

Ford reduced the average time to produce a car from over 12.5 hours to just 93 minutes.

Ford and his team (I won’t get into the debate as to who had the ideas) created a production line and improved upon it, first by making it a moving production line to keep the focus on flow. Initially simply a winch and rope to pull the vehicle and conveyor belts to deliver parts to the workers. This simple change alone saved hours, previously the workers had dragged their tools along the line of static vehicles as they were assembled.

At one stage the production line for the Model T took 12.5 hours but over the next 5 years Ford reviewed every procedure and managed to cut the production time to just 93 minutes, he cut 11 hours of waste out of an already efficient and profitable system.

Ford cut nearly 90% waste out of an already efficient and profitable system.

Was it a big deal?

Was it really that big of a deal? Yes! In 1914 Ford produced more cars than everyone else, not just more cars than his competitors but MORE cars than all of his competitors in the world combined.

He also produced more with far less, Ford employed 13,000 employees, his competitors combined had 66,000 employees, so the productivity of his employees was 5 times the rest of the industry average. That fact alone makes you sit up and take notice.

In 1914, Ford’s 13,000 workers built around 300,000 cars — more than his nearly 300 competitors managed to build with 66,350 employees.

Continual Improvement

It seemed like no improvement was good enough and Ford was continually pushing for the next improvement, 5 years of asking What’s next. Identifying every bottleneck and then the next bottleneck, his obsession for improving flow must have been relentless.

Fighting against local optimization

But Ford was not understood by his peers who’s focus was on Local Optimization, and even his own sales team who couldn’t understand his desire to simplify the design or reduce the price, they wanted options and variety. Ford wanted a car that was affordable to everyone.

Over the years Ford reduced the price of the Model T from $850 (approx. $22,000 in current terms) to just $265 which was less than 3 months wages for his workers.

The price of the Model T reduced from $850 to just $265 as a result of improvements.

His vision was to have a car available to everyone, but especially farmers, and the Model T was designed to be an effective Farm tool, and could easily convert to farm equipment.

I will build a car for the great multitude. It will be large enough for the family, but small enough for the individual to run and care for. It will be constructed of the best materials, by the best men to be hired, after the simplest designs that modern engineering can devise. But it will be so low in price that no man making a good salary will be unable to own one — and enjoy with his family the blessing of hours of pleasure in God’s great open spaces.

Henry Ford

People Problems

One of the biggest issues that Ford faced was with his workforce, factory workers were unreliable and his new method of simple repetitive tasks and his desire for rapid growth meant he had high turnover and lower quality workers.

The manual processes Ford devised for assembling the Model T were not complicated but benefitted from training and consistency, so the lack of reliability and consistency of workers was an issue for him.

His solution was to double the average pay of factory workers, Ford offered $5 per day, he reduced the working day to 8 hours and the working week to 5 days, he also offered a form of tenure (on his terms) to all employees.

Ford quipped that it was the best cost saving decision he ever made, with a massive reduction in turnover the cost of training plummeted and productivity soared, and what was really a marketing bonanza his workers could afford his cars.

Blunder or Crime?

This decision was national news. But much of the press despised him helping the poor, seeing it as a social policy rather than a sound business decision. The press too seemingly had no comprehension of the Theory of Constraints or system level thinking.

They believed he was hurting business, with one major paper calling him a ‘class traitor’, and commenting that he shouldn’t bring “biblical or spiritual principles into a field where they do not belong.” going further suggesting that paying factory workers that much “was a blunder, if not a crime … against organized society“. That is pretty harsh for a man just wanting to pay people a little more so he could build cars.

Ford had the last laugh though, employee turnover declined radically, and profits doubled to $60 million in 1916 two years after the policy was introduced from $30 million in 1914.

Any customer can have a car painted any color that he wants, so long as it is black.

Henry Ford

Was the Model T only available in Black?

This for me is the most interesting story of all. Some say it is simply a myth, as the Model T was available in many colors over the years, others say it was a metaphor for his policy of being lean, others that it was a metaphor for his dominance in the field and how he could dictate what the customer wants.

Ford himself claims he made the statement in 1909, and yet he didn’t limit production to Black until 1914, and oddly in 1909 you couldn’t get the vehicle in black, it was not one of the 6 color options available. So the quote does have an enigma quality about it.

However, In 1914 Ford restricted the option to only Black and it remained that way for 14 years before expanding to 14 color options shortly before the Model T was replaced with the Model A.

Cost saving?

I have read that the decision to limit to black was a cost saving exercise, with a suggestion that the unit cost of black paint was less than the color options but I have been unable to validate that claim and frankly I find that very hard to accept. Unit cost considerations have not played a part in any of his other major decisions – the wage decision being a clear example of how flow was far more important to him than unit cost. Cost savings were a consideration at a system level only and certainly not a factor if it impacted on flow.

It is all about flow

From what I can deduce from applying lean thinking myself to the situation, Ford would have switched to black even if the unit cost had been significantly higher. Japan Black paint was completely different to the other paint methods and had two distinct qualities that would have appealed to Ford, the first was that it touch dried very quickly and secondly it baked hard in 48 hours, compared to 14 days for the other colors.

Increase flow and reduce Cycle-time

Because the paint could dry quicker it would improve flow and so a production line was able to complete a car every 3 minutes (with 3 minutes effectively being the slowest process on the line).

Reduce Inventory and reduce Lead-Time

For Ford, being able to ship cars from his factory 12 days sooner than previously was massive, he could reduce WiP, but more significantly it enabled him to reduce his inventory of finished goods by 85%. in 1914 at any given time he would be sitting on over $5 million (retail value) of stock, by switching to Japan Black he was able to ship more and more-sooner. That decision would have been an instant injection of over $4 million dollars (that is over $100 million dollars in 2017 terms). And by 1923 if he had still been offering colors that inventory cost to him would have been over $30 million ($750 million – 2017 value). Not to mention the space needed to store 80,000+ vehicles while the paint dried.

Using only black paint was a $750,000,000 Decision

In essence the decision to ONLY offer the Model T in black was a decision worth far in excess of $750 Million in todays terms, and yet very few people understood the ramifications of that decision and many opposed it or ridiculed it, and many still don’t understand it, even with the results being self-evident.

What is Productivity?

Business is a lot of numbers, and I don’t want to bore you with figures but the improvements that Ford made to flow and cycle-time and lead-time all went straight to the bottom line, by focussing on flow rather than local optimization, and by focusing on the throughput of the whole system rather than on keeping one worker busy, Ford was able to get his workers to be 5x more productive than the competition by doing less work.

Thinking is the hardest work there is, which is probably the reason why so few engage in it.

Henry Ford

Ford showed the correlation between effort and productivity is a myth, and it is about working smarter not harder. He passed his efficiencies on to the customer, as his productivity went up the price of the Model T came down. Eventually to just $260 in 1925 which is a mere $3600 in 2017 terms. A car truly affordable to the masses.

System Thinker

Ford seemed to understand Systems Thinking and the Theory of Constraints long before either were recognized, and he did so to a level that few of us will ever be able to comprehend and in the face of public and private pressure against this way of thinking and he was often vocally opposed for his decisions.

Ford changed not just his own organization but his actions changed an industry and likely even the economy of a country. He balanced profitability with altruism, although some of his values and politics were questionable and some of the rules he imposed on his workers would be unthinkable today. But for me he is the pioneer of Lean, Kanban, and the pioneer of the Theory of Constraints, everything since then seems to be built on his shoulders.

Unless commitment is made, there are only promises and hopes

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

The first two are available here:

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

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

Can you make a decision and follow through on it?

Consensus

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

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

Patrick Lencioni

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

I want to feel valued

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

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

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

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

Turn decisions in to plans

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

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

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

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

Be decisive and be clear

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

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

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

Pointless conversations

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

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

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

Team leadership in Agile teams

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

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

My experience

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

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

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

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

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

David Marquet

oh Captain, my Captain

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

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

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

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

Agile principle No 5.

We want conflict and debate

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

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

Agile principle No 11.

Merging the what and the how

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

We want balance

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

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

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

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

Problems with the shared leadership model

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

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

Conclusion

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

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

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

Why I came to adopt an Agile mindset.

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

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