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.

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.

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.

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.

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.

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.

Are you working too much?

Would it surprise you to learn that the person in your team or company that regularly works 60 hours a week (and makes sure everyone knows it) is very likely the least productive person on the team?

The person working 60 hours is likely the least productive person on the team.

And I don’t simply mean that productivity diminishes after 40 hours, I mean absolute total productive output is less from someone working 60 hours compared to someone working less than 40. The reality is that you would actually get more done by NOT working that time than you will working those extra hours.

This is a hard pill to swallow in a culture where ‘working hard’ is seen as a virtue, and the more hours I work the more virtuous I am. Long hours are often assumed to show commitment, dedication, loyalty. Maybe they do, but they don’t show productivity. If your company values those things above actual productivity then so be it, but understanding that it is about those attributes rather than productivity is a rather brutal fact to face. However, if you want to produce more and maintain high quality then you need to work less hours.

Parkinson’s Law

I am likely to offend a few hardworking people with this but my assessment of the findings of these studies is that is is a subconscious manifestation of Parkinson’s law. “Work expands so as to fill the time available for its completion” If I expect to work 60 hours then I’ll make my work last 60 hours.

Not just a European thing.

Europeans have a reputation for favoring reduced working hours and I’m sure it is an ongoing frustration to those in America that despite typically working more hours, American companies are consistently similarly or less productive than their European or Japanese counterparts despite the longer working hours and less vacation.
Interestingly, the study I’m quoting was actually a 12 year study by the Ford Motor Company of production in the USA.

Henry Ford… again.

Before I go into the study in more detail I’d like to go back in time and talk about the history of working hours and in particular Henry Ford.

If we go back 150 years there were campaigns all over the world to reduce the working week from 16 hour days, 6 days a week – 96 hours was considered a normal working week for many. Forward thinkers pushed for limiting the working day to 10 hours with breaks for food – a radical concept at the time.

Over time much of this became law despite fierce objection from industry, and by 1914 a normal working week was 9 hour days, 6 days a week. The pressure until then mostly came from humanitarian motives and agendas, and perhaps because of that, businesses took steps to prevent it taking hold, reducing pay in line with reduced hours so a reduction of 20% of hours came with a reduction of 20% in wages, this undermined the whole movement.

But then came Henry Ford. Ford created the 5 day working week, and a limit of 40 hours, but best of all he did it for profit and not for social good. At the time his factories worked 6 days and 9 hours a day (54 hours per week) just like everyone else, but he reduced working hours by 25% and instead of cutting wages he doubled them.

The productivity increases resulting from reducing hours were so significant that Henry Ford was attacked by the Wall Street Journal “To double the minimum wage, without regard to length of service, is to apply Biblical or spiritual principles where they do not belong.” going on to say “in his social endeavor he has committed blunders, if not crimes. They may return to plague him and the industry he represents, as well as organized society.”

51098603-f186b080bc53f64bbbd46208f7dec61a538631e4-s1200 — Henry Ford may have paid his workers a good wage, but it wasn’t out of charity — it was a good business decision that some say helped the middle class take off.

As you can imagine his competition was not happy either, paying more for “less hours” was maddening, but what really made them mad was that productivity jumped up massively. People simply couldn’t get their heads around the idea that less hours increased overall productivity. Slowly the competition copied Ford and got the same results, productivity went up for less hours, and eventually this carried across to office workers too. But even with those startling results and seemingly unquestionable evidence we stubbornly cling to the notion that more work is more productive.

I have written more about Henry Ford here.

Back to the present.

Last time the proposed reduction in hours was met with hostility but eventually it was seen as beneficial to everyone, especially the business owners that fought so hard against it. Once again studies show that reducing hours will increase overall productivity, and once again industry is pushing back on it in the face of the evidence. Challenging established culture with only facts is apparently not an easy battle.

Studies repeatedly show that long hours (40+ hour) results in reduced productivity, reduced quality and a less healthy lifestyle, and yet society still perceives the number of hours worked as a measure of hard work.
It is as if we see more value in the hours worked than the output of their labour. Someone that works 30 hours and produces 30 widgets is seen as less valuable than someone that works 60 hours and produces 25 widgets, because he works so much harder.

In our culture we see more value in the hours worked than we do in the output of our labour.

*In our culture we see more value in the hours worked than we do in the output of our labour.*

How did we get into such a mindset and how do we challenge that way of thinking. Surely we should reward the more productive and effective person? But we don’t, we reward the inefficient, we lift up Jane for being here at 7:30 PM finishing up her work and we criticize Anne who got all her work done and left at 4.

Part of the problem, especially in knowledge work, is that productivity is not easy to measure, just like quality and mistakes are hard to quantify. So rather than focusing on what is important we focus on what is easiest to measure – number of hours in the office, it is ironic that in our laziness in finding effective measures we end up working longer hours.

So what about overtime?

There is more bad news in the 12 year study by Ford they found that overtime (over 40 hours) results in reduced productivity in the long term. 40 hours is the very limit of maximum total productivity for a manual worker, this applies in both the short and long term.

Short term (less than 3 weeks) there are productivity gains for working beyond 40 hours, but after 3 weeks those gains disappear and actually reduce productivity afterwards. Even just 2 weeks of overtime and then stopping results in more loss in recovery than the gain made in the short term boost.

In other words, yes you can make a short-term gain using overtime to meet a deadline, but it will cost you more than you gain over the following weeks. So use it wisely and expect a recovery period.

Bad news for knowledge workers

For knowledge workers the news is worse still, the point of peak productivity is under 35 hours, and any hours above that are actually damaging, quality is markedly worse, mistakes and resulting corrections mean that productivity reduces dramatically when knowledge workers work beyond 35 hours, primarily because fatigue, stress and concentration have a profound impact on the quality rather than the quantity of work. We simply cannot be creative when tired, we struggle to solve problems come up with ideas or compose constructive discourse and debate, we are actually very likely making things worse not better and the clean up cost for knowledge work – bad decisions, introduced bugs, stifled creativity is far more damaging than not being there.

Worse news for Lawyers

Lawyers are typically in an unfortunately situation where they bill by the hour rather than by quality or even quantity of work. They are essentially encouraged by their business model to be unproductive (not consciously, it is just a product of the business model). Essentially a 60 hours week for them is the result of rewarding bad behavior, if you pay for time then they will take more time, pay for productivity and we become more productive. We also reward with status the hard working person that is willing to sacrifice his weekend for the appearance of working harder. More encouragement of bad behavior.

In ‘bill by the hour‘ work environments it is a challenge to change the model, productivity is very hard to measure – even if we see stress, mistakes and problems taking longer to solve. So it is hard to convince clients that working less is more productive, especially when it means charging more, and it becomes even harder when we can’t even convince ourselves because this notion is so culturally ingrained in us.

What now?

It is pretty simple really if you want to maximize the productivity of your teams, then reduce their maximum working hours to less than 32 hours (without reducing pay). They will work harder and more effectively for five 6-hours days than they will for 8 or 10-hour days. Your overall productivity will be higher.

Or work 8-hours, 4-days a week and you will find your teams will be more focused, more energized and and noticeably more creative. They will be happier, harder working and make less mistakes. They WILL get more done and it will be higher quality and more creative. They will also be refreshed have a happier home life.

Or we can ignore the brutal facts and continue to pretend that working long hours is a good thing, and praising the guy that works 60 hours a week and yet produces less than a part-time worker.

Note: my wife finds this particularly amusing as I work long hours and when I’m not working I’m blogging and when I’m not blogging I’m working on my game or running meet ups – there is a significant degree of hypocrisy and self-denial at play here.

Summary

Let’s not underestimate the difficulty here, this is a complex topic, and it is unlikely to be accepted any time soon, there is a lot of resistance – and that resistance is not based on facts or data. There are numerous studies on this topic, all with the same findings. Oddly enough despite the strong resistance to this idea, I couldn’t find a single study that didn’t find that overall productivity went down when hours went above 35-40 hours. There were even some studies that showed that regularly working 60 hours resulted in the same number of mistakes and level of performance as being drunk.

(If you see a study that contradicts this please share it, I spent quite a few hours on this but couldn’t fine one – and no, the contradiction has not escaped me.)

Decision Makers

Decision makers typically work longer hours and it is effectively their money, asking them to pay more for the perception of ‘less‘ work is never going to be an easy decision. We come from a puritan culture where we make a cultural assessment of someone based on effort not outcome. Deep-down we know this is not objective, I think we know this is wrong, but culture is not based in logic and changing culture will take more than facts and figures. It needs someone like Henry Ford to lead the way again.

References:

https://cs.stanford.edu/people/eroberts/cs201/projects/crunchmode/econ-crunch-mode.html

https://www.igda.org/page/crunchsixlessons

Why don’t developers water the plants?

Bike-shedding, Bystanders and Boredom:

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

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

Background

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

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

Defined Purpose

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

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

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

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

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

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

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

Structure vs Empowerment

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

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

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

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

The three layers of self-organization responsibilities

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

Primary Tasks

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

Secondary Tasks

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

Tertiary Tasks

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

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

Bystander Syndrome

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

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

Summary

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

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

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.

The Chart is not the Voyage

Or more conventionally – The map is not the terrain.

This is an old quote attributed to Alfred Korzybski which is highly appropriate to my current client, as we make Charts of the oceans. They will be the first to agree that a chart is not the topography.

Charts can and frequently go out of date and so frequent updates of changes have to be notified to mariners promptly. In response to the Titanic disaster there was an international convention for the Safety of Life at Sea and now all larger ships are legally required to carry the latest charts and to keep them up to date in response to warnings. But even with an up to date chart no mariner would blindly assume it covered all hazards or was completely correct at any given point in time. Sands shift, sea beds may have objects that drift, some hazards may seem too small to note at some scales, some Hazards are temporary, etc.

The expression though is a warning to planners and navigators that the information they are using to plan is a simplified and likely an out-of-date illustration of the terrain. Navigational charts will often come with additional advice on approaching ports or other hazards but none can confidently claim to cover everything accurately.

Have you ever used a Sat Nav and found it taking you a convoluted and often much slower route because the pathfinding thinks a particular route looks shorter but is actually a narrow country lane that has limited passing places, I’m sure we’ve all see photos of trucks stuck in a narrow road as a result of following a map (or Sat Nav) without really understanding the terrain.

Planning

When planning a project you gather information to help you make the plan but here is the challenge of all planners:

If you try to cover every detail, every eventuality and every hazard it would likely take you as long as if you acted out the plan, probably longer as you would be mapping potential avenues that are never followed.
If you over simplify the plan you may omit key information and as in the case of the Sat Nav missing something crucial like a bridge being closed could throw the plan entirely. Making it difficult to stick to a plan.
If you plan from an illustration it is difficult to truly anticipate how long the actual journey will take.

Accurately planning for a team, large or small requires that you understand in detail both the journey and the team.

So how is it possible to get a team to successfully follow a detailed project plan?

Is it possible to successfully follow a detailed plan?

In a rather defeatist way, my answer is that it is not possible, or at least not consistently.

In waterfall projects, the normal solution is often to add huge amounts of contingency, if I think it is a 6 month project, call it 12 months etc. Have milestones to regroup and get back on track, but contingency when not needed is waste and in waterfall contingency is generally consumed. But contingency is in essence a form of planning based on an assumption that our plan is flawed – which it likely is, but this is hardly efficient.

We may also throw more staff at a plan or change scope or move dates the usual reactive crisis management that occurs when a Waterfall project is running late, but all of these are the result of a flawed plan, and in my experience the longer the plan duration the more inaccurate it becomes.

So if it is not possible to successfully plan a complex project why bother?

Essentially what I am saying is that Eisenhower hit the nail on the head when he said

“Plans are useless, But planning is indispensable”

Eisenhower

Planning is Indispensable

In Agile terms, my advice is to set a clear Vision, we absolutely must know where we want to go, and then simplify the plan into high-level objectives, and then prioritize them. Flesh out the detail of the highest priority item, and begin to explore more detail on the next highest priority and so on. Have a plan that has the minimal detail and expand it as you go and be prepared to adjust. Agile projects have the wonderful tendency to separate the wheat from the chaff and you will get a much leaner solution, lower priority features are deferred until later and often dropped altogether.

If we return to a voyage analogy if I were planning a voyage that involved multiple stops, I’d want to know the final destination and the major ports on the way perhaps an idea of key navigational way points, I would eventually want a detailed chart for each stage of my journey but I don’t need to study them yet (the charts may change or perhaps I will need to add a stop or skip one), the detail only matters when I reach that point. Right now all I need are detailed charts for the current stage, so long as I can plan that part of the journey I can proceed.

How long will the project take?

“But I’m a Project Manager and I need to know how long the project will take.”

If you have been nodding along with me as you read this you will be in agreement that the notion of accurately planning a complex project is a flawed concept, and that your previous attempts to predict project duration inevitably result in inflated estimates to cover contingency and you are not competitive. So the question becomes one of “do you really need to know how long this will take?” Or “why do you need to know how long it will take?”

Generally this falls into a number of categories:

1 Dependency:

If you are planning a launch date and it must coincide with another particular event then this may seem to be a reasonable request, but the question isn’t really one of how long the project will take, but one of how much can be completed by that date? Can it be delivered in phases? What is the MVP? How fixed is the date? Could it slip? Could it be deferred? What are the consequences if we are late?

The best advice would be to defer fixing the date as long as possible if content (MVP) is critical, or to ask yourself if you are willing to adjust scope, and or cost to meet the date? It is rare to find a project where 100% of the requested features are truly mandatory on a particular date and when that is the case it is unwise to have a fixed delivery date.

2 Return on investment

More often the usual reasons for wanting a plan are because of cost constraints or price/profit related issues, neither of which are helped by an inaccurate plan. What they mean is “How can I predict whether this project will be profitable?” or “I’d like an estimate for how much is this project going to cost me?”

Both of these are perfectly reasonable requests but neither require a date to be plucked from the air and written on the back of a contract for the soul of the Product Owner.

In all cases where Scope, Time or Cost are a limiting factor Agile planning and Agile delivery should mean that you get the highest Business Value items for the lowest cost, and that you will know at the earliest possible moment when there are issues that may impact on the success of the project. The aim is to deliver value at the earliest opportunity, in theory this is the most efficient and therefore most profitable/lowest cost solution for the given parameters. And if the project fails it will fail quickly for the lowest cost.

Agile doesn’t guarantee success or profitability, but when applied well it maximizes the value of successful projects, and perhaps more crucially in commercially driven projects it enables mitigation of failures at the earliest opportunity.

But you will have spotted that doesn’t answer the question: An estimate is a different matter entirely – see Estimates – Planning and estimation are frequently confused and they really shouldn’t be, but that is another topic.

3 Resource allocation

There may be other projects and you may want to predict when the team will become available, but assuming you are working on the highest priority project then your team is being utilized in the most appropriate way. Programme planning, like project planning is better done at a high level for the future and only becoming more specific as the task draws closer. If there is a dependency then see above, otherwise trust that the project/product will be completed as quickly as possible and the team can move on to the next task at the earliest opportunity.

Summary

There is nothing wrong with planning, planning is vitally important, the mistake is relying on a flawed plan, rigidly sticking to it in the face of reality.

Plan with the expectation that your plan will change.

Project Management Mistakes

I found an interesting link discussing common Project Management problems and suggested solutions, and I found myself questioning the advice given…

http://www.cio.com/article/2391872/project-management/12-common-project-management-mistakes–and-how-to-avoid-them.html

So many projects, so much mismanagement. That’s the refrain of many IT executives. Indeed, even with project management software, IT projects often wind up taking longer (much longer) than planned and costing more than budgeted.

I have previously covered the issue of how many failed projects there actually are, the proportions are really quite frightening: Most projects will fail by conventional measures, they will go over budget, be late or the scope will change, even with ‘good’ planning and contingency. So an assessment of “why?” is a great idea, but many companies are still stuck in a rut of doing the same thing and expecting different results.

The Survey in the link above and the proposed solutions is nice to see, but to me it felt as if the respondents were trying to solve problems by doing the same things that have failed previously – only suggesting that if they had done it ‘better’ it would be different, rather than considering that maybe the process that was at fault? I wondered how applying an Agile perspective might offer different solutions to try.

I do not intend to be (too) critical of the original responses, they were clearly made by experts in their field and may very well be the right answer, but I have taken each issue – all of which are common project management issues, and I have applied an Agile head when offering a solution.

I don’t claim my solutions are right or better, but they may offer a slightly different perspective on persistent problems. And reflect how I would advise the problems should be resolved.

Project Management Mistake No. 1: Not Assigning the Right Person to Manage the Project.

Typically during resource allocation, most of the effort is focused on finding the right resources rather than finding the right project manager. Indeed, too often project managers get picked based on availability, not necessarily on skill set. However, an inadequately trained and/or inexperienced project manager can doom a project.

Traditional PM Solution:

Choose a project manager whose skill set(s) match the project requirements.

Agile solution:

1) Ask whether the project even needs a Project Manager, it may be that the content and scope could be ‘owned’ by a single ‘Product Owner’ When it comes to a project that involves integrating many independent components from different sources and there isn’t a clear hierarchy or dependency then a Project Manager may make sense, but where the project is delivery of a product increment, or there is a clear hierarchy and dependencies it is not clear to me what value if any that a PM adds, it becomes an extra layer of bureaucracy but no added value.

2) However the traditional answer applies in an Agile environment. Finding a Product Owner that has the right knowledge and skill set is vital, as is empower them appropriately. Finally have them focused entirely on this one and only product. Multi-tasking will generally lead to problems with one or both projects.

Project Management Mistake No. 2: Failing to Get Everyone on the Team Behind the Project.

Too often, projects are doomed to fail because they didn’t get enough support from the departments and people affected by and involved in the project. Either managers: 1) Didn’t make clear what everyone’s role was. 2) Didn’t describe the personal payoff everyone would get when the project was completed successfully. 3) Didn’t tell how each person’s contributions to the project would be evaluated. And/or 4) Failed to generate a sense of urgency about the project, leading the team to think business as usual will be fine.

Traditional PM Solution:

The project manager should start by calling the team together (being certain to include off-site staff via the best technology available) and delivering a presentation about the project and its significance in a way that gets everybody fired up.

Agile solution:

1) The Product owner should share the vision with the team, show how their part fits in with the big picture. The vision is crucial and should be clear to everyone. (just as above)

2) Where possible have team members dedicated to the project, this immediately builds ownership and commitment, have them co-located with colleagues and build a team. Motivation to team mates is more effective, more consistent and has greater longevity than that which can be created to a project.

3) Have the team involved in setting goals and expectations; the more involved they are the more they will buy-in to the project. Give them ownership of the design and the level of quality, a self-set target is more meaningful than an imposed one.

4) Discussing Personal payoff is not helpful, we are trying to build a team, in software projects like any cognitive task both carrot and stick are counter product and can be demonstrated to reduce productivity. It is far better to build a good team and share a vision, a well-motivated team does not need a sense of payoff, successful delivery of a product is motivation enough. A shared purpose and shared success.

5) Again a sense of urgency is not a helpful tool for motivating software teams, ‘Urgency’ should be reflected in prioritization not pressure or deadlines. An appropriately motivated team should work at a sustainable pace. Let’s talk in terms of priority: Urgency is a reflection of poor management and poor planning, projecting that failure on to the team is in my opinion a sign of failure of management.

One final note – “Failed to generate a sense of urgency about the project, leading the team to think business as usual will be fine” I find this to be a very bizarre comment, in my opinion “Business as Usual” is fine, in fact business as usual is great. If I have a team that works at a sustainable and predictable pace that is the holy grail for a project manager, or it should be. A known quantity, and one that can run and run and run like the Duracell bunny is what any project manager should desire.

Why would anyone thing that driving a team into the ground to meet an urgent deadline, followed by a crash of exhaustion, staff potentially off with stress, or quitting, or any of the other consequences of deliberately overworking and pressuring staff is actually a good thing?

Whilst meeting an unrealistic deadline set by someone outside of the team may well be the priority of a PM, it is naïve to assume you can move teams from one project to the next without a break always expecting them to work with a sense of urgency. It would be far better to think of the team as a machine that takes a while to get up to speed, whilst you may be able to stress the engine and push it to the limit, to do so regularly or for prolonged periods will cause damage. Whereas a good engine run at a sustainable pace can run for far longer.

Ultimately, It comes down to a question of respect. If you treat your team right, they will work well for far longer and be far more productive in the long-term.

Project Management Mistake No. 3: Not Getting Executive Buy-in.

Traditional PM Solution:

Somebody at the higher levels of the organization needs to own the project from start to finish and be personally vested in its success, When a project has no clear head, things tend to fall apart.

Agile solution:

1) A single Product owner should be empowered, and personally vested in the success and assigned exclusively for the duration. If the Product Owner cannot be sufficiently empowered to achieve success, then your organization has more serious issues.

2) Not all projects need a senior sponsor, but they do need support appropriate to the project.

3) Senior sponsorship for the way you work is vital – By which I mean Framework – in this case Agile. The organisation needs to be behind the delivery method. If the project is necessary then the project leader needs to have the backing of the company to get it done. Any block to agile delivery needs to be aggressively unblocked and sometimes this required uncomfortable change in attitudes, and that will require senior sponsorship.

Project Management Mistake No. 4: Putting Too Many Projects into Production at Once.

Most managers think that they can get more done by starting all projects at once, but in reality, it’s counterproductive. Multitasking slows people down, hurts quality and, worst of all, the delays caused by multitasking cascade and multiply through the organization as people further down the line wait for others to finish prerequisite tasks.

Traditional PM Solution:

To stop these productivity losses, a good first step is to reduce work in progress (WIP) by 25-50 percent. This reduces the back and forth and makes managers and experts more responsive in dealing with issues and questions. Though counter-intuitive, reducing the number of open projects by 25-50 percent can double task completion rates.

Agile solution:

The same as above: reduce WIP, far too often we resort to claiming credit for starting work, or for claiming it is in progress. The only metric that matters is completed work. If limiting the number of projects on the go, results in more projects being completed then what are you waiting for?

I’d like to write more on this topic, I feel this is so crucial to success, the number of times teams are held up because of competing demands on networks teams, DBAs or deployment pipelines or any number of other critical resources. The impact of these are often unmeasured, but simply reducing the number of concurrent projects relieves the context switching and demand on these resources. Which is an immediate easy win.

But more that if you can deliver 4 projects in 12 months, why not deliver 2 of them in 6 months, and then 2 in the following 6 months. That is two projects delivered 6 months early without any additional work and without delaying anything, you may even find they get done quicker.

Project Management Mistake No. 5: Lack of (Regular) Communication/Meetings.

Communication is the most important factor of successful project management. Without regularly and clearly communicating, the project will fall apart.

Traditional PM Solution:

Pick a day and time to meet each week (either virtually or in person) that works for the team (not just the project manager) — and stick with it. Having specific days and times scheduled, in advance, helps to keep everyone on the same page and keeps the project flowing.

Agile solution:

Meet daily, co-locate the team to reduce further any delay in communication. Use information radiators (Whiteboards to the rest of us) to prominently display useful and pertinent information. If the information is useful you need it now, if you can wait a week for it, it probably isn’t that important.

Communication in Agile is crucial, anything that can be done to reduce the barriers to communication should be considered a priority, getting team members and those peripheral to the team communicating effectively is vital. Co-locate where possible, a daily stand-up is a scheduled opportunity to get together and share, but for anything critical even a daily meet up is not quick enough. But communication should be useful, timely and concise.

Project Management Mistake No. 6: Not Being Specific Enough with the Scope/Allowing the Scope to Frequently Change.

Any project that doesn’t have an ultra-clear goal is doomed, scope change is one of the most dangerous things that can happen to your project. If not handled properly it can lead to cost and time overrun. Even something small, like changing the color of a logo or adding a page to a website might cause unexpected delays.

Traditional PM Solution:

Define the scope of your project from the outset and monitor the project regularly to make sure you and your team are keeping within the scope. And to avoid delays and deviation from the original scope, track change requests separately from the original project scope, and provide estimates on how it will affect the schedule and get explicit customer/stakeholder approval for each change.

Agile solution:

“Even something small like changing the color of a logo might cause unexpected delays” Wow! And the solution is to “Avoid delays and deviation from original scope” Wow!

I am utterly stunned by this problem and the response. First everyone involved in a project does or should understand that Change causes delays, any client that expects to be able to change a Logo or add a page without a consequential delay, is extraordinarily naïve or is being misled. Very simply work takes time, sometimes even removing work takes time. A product Owner or PM should be able to candidly discuss this with the client, if the client is asking for change they should be made aware of the impact and that information should help shape their decision. If you cannot have this conversation then there is insufficient trust between you and the client, and rigorously enforcing terms of the original contract is not going to promote trust.

In my opinion the response is shocking, just who is the Client here? If the client has changed their Logo, then who would consider it sensible to plough on with a solution that is wrong? Refusing to accept change is not working for your customer, it is self-serving and ultimately futile. This stubborn refusal to accept change is the primary reason Agile has been the huge success it has, because the customer is respected. In Waterfall the goal is to conform to a contract, in Agile the goal is to give the customer what they want. The difference between the two is a happy customer and an irritated customer seeking a new supplier.

Example: If we consider an extension to a house, upfront I may have architectural drawings, and building plans, and I may get a builders quote based on those plans. But as the build progresses I decide that I’d like to change the position of a window or I change my mind about the type of tiles, or kitchen units. As the customer that is my prerogative.

Situation A: Builder says, “No! that is not what we agreed, you must stick with the plan and keep the materials you specified. If you want to change this, you must wait until we are done, then rip out the work and redo it later.”

Situation B: Builder says, “Yes! But it is not what our estimate was based on, changing the plan and materials may increase the cost, and may take a little longer. So long as you are comfortable with the impact we are able to accommodate your requests.”

And Just for fun – and this generally doesn’t work so well for building work where planning permission is needed upfront but still…

Situation C: Builder says, “Let’s build the initial framework and you can defer making the decisions about the layout and internal fixtures until later, when you are better able to envision the situation.

Project Management Mistake No. 7: Providing Aggressive/Overly Optimistic Timelines.

The intentions are noble, as project managers are often trying to keep their clients happy. But missing deadline after deadline will only lead to distrust and aggravation on the part of your client.

Traditional PM Solution:

Good project management software will allow you to manage many work items and the bandwidth of available resources. However, it’s still important to add a buffer providing some extra time and money to your project, especially in the world of technology.

Agile Solution:

The proposal of Better software, and more micromanagement and adding contingency to counter optimistic timelines, is the opposite of good agile practices. Once again I completely disagree with the proposed solution.

Solution 1) If the timelines are unrealistic this should be addressed, the team (dev or management team, or customers) should assess why they are coming up with unrealistic estimates, and modify behaviour accordingly. Discuss why a timeline is needed, and plan accordingly. If we must meet a specific date then we plan the solution accordingly, if we must keep to a certain budget, we can plan the solution accordingly, but an estimate is not the same as a deadline. See blog post…

Solution 2) Rather than adding buffers and contingency, how about prioritizing content and being flexible with the scope to meet a timeline if the timeline is critical, or being flexible with the time. It is a controversial comment but I find the routine practice of PMs padding estimates or surreptitiously adding contingency is counterproductive, it causes mistrust, and is ultimately futile as management will react by demanding earlier delivery believing that estimates are padded. I’d much prefer to be open an honest, and build trust, I keep management informed of progress and allow them to make decisions on true and upto date information.

Solution 3) Fancy software doesn’t help. The more you micromanage the less productive the team becomes. For a former software developer and general technophile, when it comes to project management I’d actually prefer to have no software tool at all. A Kanban board and a backlog of stories on Index cards is actually very powerful, software has value in some circumstances but most of the time the simple approach is sufficient and clear to everyone involved.

Project Management Mistake No. 8:

Not Being Flexible. While you may think of your project plan as your bible, telling you what needs to be done, by whom, and when to do it to get to your goal. Don’t hesitate to listen to new information and suggestions that come up along the way.

Traditional PM Solution:

It’s good at various intervals to step back and take a fresh look at the overall project, review how things have gone so far, and how you can improve your future work based on what’s already changed along the way. That doesn’t mean you should or need to constantly make changes, just be open to suggestions if they help the project.

Agile response:

Schedule regular retrospectives, make the act of trying to improve a regular part of your job. Actively look for ways to improve, a passive ‘being open to change’ is not enough. We need to seek to improve and have a willingness to continually find even small ways to grow. Many small improvements can lead to significant benefits.

Project Management Mistake No. 9: Not Having a System in Place for Approving and Tracking Changes.

Often, success or failure of a project hinges on the changes that occur after it begins. However, all too often, there is no system in place for approving and tracking changes.

Traditional PM Solution:

Having a clear process that must be followed is the best way to ensure the pertinent details: how much it will cost, why it is necessary, the impact on the overall project etc., are known before the change is approved. It’s also extremely effective for auditing performance during and after project completion.”

Agile solution:

Change is a part of software development, no amount of planning can ever reveal everything, there will be change, so plan for it from the outset. Prioritise work rather than plan in detail, allow for priorities to change and expect them to change. Allow for new work to emerge, and consider and plan for the possibility of failure. As with the traditional PM approach, why; cost and impact need to be considered, but these are a factor of priority. Any heavy weight review process is unnecessary.

Failure is deemed bad in all circumstances, but that is not the case, to fail early may actually save significant costs compared to failing later. This should he heralded a success, but too often all failure is considered bad. Failure can lead to successes later. Not learning from failure or continuing along a failing path is the real waste. But too often any failure is not tolerated and this can be very damaging.

Project Management Mistake No. 10: Micromanaging Projects.

Don’t babysit, It’s very common for budding project managers to treat their job like an enforcer, policing the project team for progress and updates.

Traditional PM Solution:

Instead of babysitting the project team, let it be known from the start [i.e., the kick-off meeting] that there will be regularly scheduled updates for the duration of the project. This lets your team know that status updates and progress are expected from them weekly and will encourage them to vocalize any issues or delays in advance.

Agile Solution:

Don’t allow the Project Manager or Product Owner to micro-manage, it is the job of the Scrum Master to coach the team to manage themselves and then the SM is to run protection – keeping the wolves at bay. PMs micromanaging is rarely beneficial and is generally damaging. The saying goes that you should hire the right people to do the job, and once you have hired them, trust them to do the job right. If you have hired the wrong person no amount of micromanaging will help, and if you have the hired the right person micromanaging will only hurt.

Project Management Mistake No. 11: Expecting Software to Solve All Your Project Management Issues.

I’ve seen people throw software at problems all too often, and though projects become enumerated and more visible, the underlying process is still broken,” “What you end up with in that case is a potentially costly piece of software only serving as a checklist of projects in motion without any thought given to advancing each project/milestone effectively.

Traditional PM Solution:

Choose project management software wisely — something all members of the team will be comfortable using. Then make sure to train users properly and set up a system for tracking projects. Above all, don’t let human capital be “overshadowed by the allure of software solutions’!”

Agile Solution:

Fancy software doesn’t help. The more you micromanage the less productive the team becomes. When it comes to software project management I’d actually prefer to have no software tool at all. A Kanban board and a backlog of stories on Index cards is actually very powerful, software has value in some circumstances but most of the time the simple approach is sufficient and clear to everyone involved. Naturally many projects involve more than a single stream of software and in that case a software tool may be useful, so long as it doesn’t interfere with the software development streams.

If we limit scope to be a software development stream, then simple metrics on backlog, cumulative flow and perhaps velocity should be more than enough to check progress towards milestones. But in this case the Product Owner is the best source for the health of a software project.

Project Management Mistake No. 12: Not Having a Metric for Defining Success.

Traditional PM Solution:

The very first thing a project manager should do is ensure he understands what the end users will consider a successful completion to the project,” Understanding what will make a project successful…ensures that when the project is completed [all] parties walk away satisfied.

Agile Solution:

Very similar, a clear Vision for the project is key, but a vision is not a set of requirements it is a concept. Ensure that the Product Owner and the team understand the vision and any intermediate milestones. But the goal is satisfaction of the customer, that is the only metric that matters. Ongoing conversation to ensure they are satisfied with the progress is essential, regular reviews and conversations to ensure your solution is meeting their needs. This is not an exercise in checking off items on a contract, it is about delivering the right solution to the customer.

Summary

It surprised me how different an agile approach is, I had expected far more overlap, after all Project Management is as old as the hills. Some solutions are common to both approaches but even then the approach whilst similar seemed to have a different goal.

But what struck me most was how Traditional solutions fell back to a desire for more control: control the scope, control the team, and control the customer. Whereas Agile was about building a team, responding to the customer and guiding not controlling the delivery. The perception of control is such a fallacy when dealing with a customers evolving needs and the unknowns of software development.

A quick Star Wars quote to finish:

“The more you tighten your grip, Tarkin, the more star systems will slip through your fingers.”

Could it be as simple as that? As a Project Manager it seems that the more control you try to exert, the less real control you have on the delivery, but by accepting a little Agility:- whilst it may seem to be relinquishing control you are actually far better able to steer the project.

How not to motivate

A friend suggested I watch this YouTube video on Motivation: Worst way to motivate

I thoroughly enjoyed this video and it is well worth watching. The outcome flies in the face of some conventional logic but supports the view that we have come to know and love in Agile.

Spoiler Alert: for those that don’t watch the video, the premise is that The Federal Reserve bank in the USA commissioned a study in how to motivate staff and get better productivity, essentially how big a bonus do you need to give to have an impact on productivity.

The study was carried out by scientists at MIT, Carnegie Melon and University of Chicago and the outcome will surprise some of you.

Essentially what was classed as small or moderate incentive bonuses had no noticeable impact on productivity when applied to any task that wasn’t purely mechanical. And large bonuses (equivalent to 3 months wages) caused a measurable decrease in productivity. Yes that is right, give someone a significant incentive when working on even mildly cognitive tasks and they got worse.

In other words incentives are bad, very bad.

The key to increasing productivity according to this study is in 3 areas:

Autonomy
Mastery
Purpose

Quick tangent…

My mind immediately jumped to the financial crisis. If the Federal Reserve believe that financial incentives have a negative effect, why are financial incentives the principle method used for rewarding bankers? Does that mean that if bankers were paid an appropriate salary would they actually be better? Or is the conclusion that banking requires no cognitive input 🙂

It is not all about money.

It should be noted that for the study to reach the conclusion ‘salary’ had to be off the table, people need to be paid enough as a base salary for that not to be a motivating factor. This is easier said than done.

What I find interesting is that this study also supports old-school psychology too. Some of you may be familiar with Maslow’s hierarchy of needs. Essentially once basic needs are met, security housing food etc. which have a direct correlation with income, things get more fuzzy, needs above essentials no longer have a direct monetary driver. We get into Psychological needs: areas of personal relationships, social standing, and then on to our need for self-fulfillment, creativity, fun, personal achievement. All of which have an element of financial impact but it is clearly it is not the primary driver. Once Basic needs have been met money becomes far less important to us.

For example we don’t learn a musical instrument for financial benefit, or do a crossword, many of us have a hobby that takes huge amounts of effort, research, expense and often inconvenience and usually for nothing. Some participate in PTAs or Churches or social groups and clubs, or even write a blog. For most people money simply doesn’t drive us (Assuming we have enough to live), it is an enabler. So in theory if you have a reasonable base salary and you are content, then motivation needs to come from elsewhere.

Money cannot buy happiness, but being broke sure makes you miserable.

Aha, all looking good until…

A company in the USA read a similar study and concluded that if someone earned $70,000 they would have enough to be content, all essential needs would be met and so money would not be a factor and they could focus on productivity, so he raised the pay of all employees to $70,000. Perfect! Only it wasn’t, humans are contrary soles and whilst the pay raise was great for some, we also measure our social standing by income, not because we care about income, but because it is a measurable metric of your value in society (or at least the workplace). So when someone you felt was in a job that required less skill or less status than you was suddenly earning the same you felt disgruntled, your salary hasn’t changed, last week you were happy but today you feel you are relatively less important. So it is about money and at the same time not at all about money.

Do you pay fair?

Paying fairly doesn’t mean pay them all the same. Laszlo Bock from Google in his book Work Rules goes even further than this:- he says to deliberately pay unfairly, if you have a good employee pay them excessively, deliberately take money out of the equation.

My take from this is as follows:

Pay your staff well, pay them what they are worth as a base salary and review it regularly, but do not include any performance based incentives. And if you include profit share or Christmas bonuses, apply them equally (% based) and do not have them performance driven.

What you want is a secure workforce, you do not want them to be thinking they could earn more elsewhere, and you do not want high turnover of staff. Show your employees that you truly value them, pay above market rates to ensure stability, and be prepared to pay exceptional employees exceptionally.

So with a reasonable and appropriate salary (with no performance incentives) as our foundation, we can concentrate on the real issue of how to maximize productivity, and this is where it gets interesting…

more next time.

You can’t handle the Truth!

When it comes to leadership it seems that a lot of problems and a great many solutions come down to either a lack of communication or lack of trust, often both.

But why are those two skills so difficult to master? How much time and effort gets wasted simply because we don’t trust our employees, or don’t understand a request? How much dissatisfaction and uncertainty results from not trusting your boss?

Around ten years ago I was working on a major release of software, it was a gated waterfall project. I and three others were critical reviewers and gate keepers for a major component. At the gate review our component was a shambles, really late, testing was far from completed, documentation hardly started. My understanding of the gate review was to quantify risk and to ensure all components were on track with the plan. Essentially a structured early warning system.

We four reviewers unanimously agreed to reject the component. We met a lot of resistance and were put under pressure, we were told that “we were delaying the project”, that “it would make us look bad” it was a difficult decision and we were well aware that it would be uncomfortable. But the reality was that the project was behind and we saw no value in faking things to keep a plan looking good. We felt the purpose was to highlight problems so they could be corrected.

But at some point the plan became more important than the product. The next day a company wide announcement was issued, the project was on track, it had passed the gate and all was well. We were shocked, it turned out that our boss had removed all 4 of us as critical reviewers and replaced us with others that were willing to say all was well. My colleagues and I were deeply unhappy about this.

The lack of trust was shocking, the lack of transparency and honesty showed just how dysfunctional the process was. Unsurprisingly as the project neared the completion the target date it slipped drastically catching people by surprise and the project was close on six months late and we were not first to market. We will never know if being transparent at that point could have given the project opportunity to rectify the situation sooner, but hiding the problem certainly didn’t help.

It is not that waterfall projects inherently lack transparency, but a rigid plan that has a high cost of change creates a barrier to transparency, Project Managers feel pressure to hide problems in the hope they can fix them before anyone becomes aware, or as more often is the case in the hope that another part of the programme slips more so they are not in the firing line.

These days I advocate a software delivery framework that highlights problems as early as possible, but many execs don’t like this. I sometimes wonder if they prefer to pretend all is well or imagine that problems will resolve themselves, this is an Ostrich mentality that allows them to defer worrying until later.

Adapting to an Agile framework where everything is transparent can be a difficult adjustment for many execs and programme managers, being aware of day to day problems, minor issues, or simply that some tasks take longer than expected can be a difficult experience for managers used to only getting positive assurances from PMs. Suddenly they are exposed to information that was previously masked from them. They must fight the urge to interfere and learn to trust the teams, to trust the Product Owners and the Scrum masters. In many ways it was easier to ‘trust’ a Project Manager with a Gantt chart when the real story was hidden – even when 90%+ of the time that story was inaccurate. A pleasant lie is always easier to accept than a painful truth.

You can’t handle the truth

The sad situation is that for many execs they simply cannot handle the Truth, they want an agreeable story that lets them claim a project is on track and are happy to believe all is well until it is too late to hide it any longer, and then they can shout and blame, but all this occurs usually after it is too late to take corrective action, the screaming and the desk thumping achieves nothing but to upset people. No one wants a project to be late, chances are they have all worked very hard and done their best. So in reality they have far less influence over the outcome than if they had valued honesty over platitudes earlier in the process. Rather than enforcing overtime for the last couple of months or scrapping all quality control to meet a deadline they could have taken sensible planned corrective action much earlier had they simply fostered a culture of honesty and openness.

I like to think that most software professionals have a desire to do a good job, they want to complete projects quickly and to a high quality. Trusting them should not be a great leap of faith. In my experience you are more likely to get overly optimistic promises than padding. Your biggest dangers are more likely feature creep or boredom, it is very rare to find a developer that wouldn’t prefer to be busy and challenged.

In short trust the development teams, it is very likely that trust will be rewarded.

The value of a ScrumMaster

In June 2014 a new ScrumMaster was brought in to work with an existing and established development team

At the point of joining the team had already raised concerns about environments and tools but the team had been unable to express specific issues that could be resolved, these problems had been intermittent for most of the year. The team was composed of a BA acting as Product Owner, a Lead Engineer, three other developers and two testers with the addition of a ScrumMaster this made a team of size 8, which equates to an approximate cost to the business of around £600,000/$1,000,000 a year.

The team measure their productivity using a term called velocity, which is how much work measured using a relative scale is achieved over a period of time. The amount of work fluctuates for a variety of reasons, holidays, sickness, bugfixing, mistakes, environmental issues, focus or context switching, support requirements, spikes etc. It is an anecdotal estimate of productivity only. But has become the industry de facto standard for measuring improvement. This had been recorded over the previous year and the documented average for the 12 months preceding the new ScrumMaster is noted below as 100 basis points per week.

Velocity can only be used to compare a team with it’s own past performance, i.e. it is a relative scale, not an absolute measure but in that context it is very useful. But should be used with caution. In this case the team had an existing Datum and a set of benchmark stories. The Datum was not modified and the benchmark stories remained in this period, thus there is a consistent base level for comparison.

Year 1 (Prior to ScrumMaster)

The new ScrumMaster, spent some time with the team, observing and evaluating. He sought to identify problem areas and any behaviour in the team where improvements could be made. But unlike a conventional manager or trouble-shooter he did not issue directives on changes to behaviour.

The team scheduled regular ‘retrospective’ meetings where they review the past time period and look for ways to improve. The ScrumMaster used a variety of techniques, to coach and guide the team to focus on areas identified either by the team or by the ScrumMaster as problematic or where improvement could be made. The ScrumMaster collected and compiled metrics to aid this analysis, and facilitated meetings to be productive in deconstructing problems in a non-negative manner.

By using this approach the ScrumMaster did not solve the teams problems, he did not offer ‘his’ solution to the team, nor issue directives for improvement. The ScrumMaster worked with the team to enable them to become aware of their problems and the ScrumMaster created an environment where the team were empowered to solve their own problems. The ScrumMaster uses his past experience to identify problems and may steer the team to suitable solutions, but relies on the team to solve their own problems.

In the following quarter there was a notable upturn in velocity (productivity)

Year 2 (First quarter after ScrumMaster)

The ScrumMaster is responsible for creating an environment where the team can reach a long-term and consistent performance – a spike or a blip is not considered sustainable, so it is important to not seek to boost productivity with short-term fixes like overtime or cutting quality. The aim is sustainable pace and sustainable quality over the long-term.

The ScrumMaster continued to work with the team identifying more bottle-necks and waste, removing impediments and coaching the team how to work around impediments or resolve them themselves, there is always room for improvement in a team.

The ScrumMaster also spent time coaching the Product Owner and Programme Manager on expectations and in their interactions with the Scrum Team, including challenging the Programme Manager on how his priorities are fed to the team so that the team could focus to be more effective.

Year 2 (First full year with new ScrumMaster)

Velocity is only one measure of productivity and is largely anecdotal, however it is the only real measure we currently have available. The productivity improvement should be considered in that context. However, there is a clear and notable improvement in the productivity of the team over the 12 month period. The team deserves the credit for the improvement as they have improved themselves. But by adding an experienced ScrumMaster to an existing team he has been able to coach the team into identifying ways they could improve and in doing so doubling their productivity – a significant change in just 1 year. In this instance it could be argued that the ScrumMaster’s coaching of this one team has resulted in £600,000/$1,000,000 worth of added value to the business and assuming the team does not regress this is an ongoing year on year gain.

It is not often possible to measure the impact on a team, and velocity is a fragile tool for that, but I hope it is clear from these metrics the value that one person can have on a team. It is highly likely that Year 3 will not have the same growth but even if the new velocity can be merely sustained the value to the organisation is significant.