We need a strategy for this…

Been here before?

“I hear your issue and I think you are right, we need a strategy for this…” (feel free to roll your eyes at this point).

This is typically said in response to an expression of a problem – rather than a request for a strategy; and what is a strategy anyway?


Strategy should be a set of principles applied continuously, that support decision making to ensure alignment to your objective. It is not (or should not be) a fixed plan that implies excessive Big Design Up-Front. However I suggest our opening line isn’t referring to either of these strategies, no in this case it is much less. I will rephrase…

“I hear your point and I think you are right, I don’t know what to do. I don’t want to make a decision, because it might be wrong; but I don’t want you to think that I don’t know what to do, and I need you to remain thinking I am important.”


Basically the word strategy is over used and often thrown in as an opportunity to procrastinate without losing authority.

So how can we help prevent this response from being given (or even from giving it ourselves).

Firstly, take a stance that doesn’t suggest that solutions can be plucked out of thin air for a problem and then put through an expensive development process that won’t return against its own risk for months or years. Once the expectation is lifted from having to implement a solution with unknown consequences, then it is possible to retain authority whilst investigating, rather than acting.

Next understand the metrics by which the problem, and hence its resolution, can be measured. If you can’t define the metric, then you probably don’t really have your finger on the real problem.

Now suggest an idea that will affect the metric in the right direction and ask people involved what could we do to test whether the implementation of the idea will have the desired impact on the metric – a safe to fail experiment – mindful that most experiments DO fail.

Then do that test. This is a proactive decision to DO something, ACTUALLY DECIDE TO DO SOMETHING. Later assess the findings and then you can decide if the idea is worth progressing with. Now the expensive decision to invest in something is a lot less risky and the deep desire to procrastinate to avoid making a mistake is reduced.


Now you can call this User Research, Lean, MVP, Agile or whatever. I have avoided doing so because I don’t want to solicit an emotive response against poor implementations of these things that lead to organisations stating “We don’t do that here”. This is a call to those situations where enormous time and money is wasted with the word “Strategy” because it is an excuse to justify doing nothing hoping the problem will just evaporate!


The Agile Developer – “they may take our projects, but they will never take our freedom!”

One of the underlying principles of Agile and consequently areas of activity in an Agile transformation programme is Empowerment. I am a big driver of empowerment in my explanations and preferred implementations of Agile delivery – and it takes time.


There are two challenges  – firstly encouraging people that have been micromanaged to step up and take decisions, secondly to encourage people, who until recently have been making decisions, to back off and at most facilitate team discussions to make those decisions.

Enabling those things to occur is a complex and difficult challenge but that isn’t the thrust of this post.

Assuming that this has occurred we now have a team of empowered professionals that are shaping their world and the delivery of their product. They are in some context – free. I have heard Agile referred to as, “developer emancipation”. The teams have gained their freedom and the natural passion this evokes in delivery can be related to the soaring of a bird or the breaching of a whale, an expression of joy within their environment.


But consider a caged bird – which sang happily in the cage, ignorant of what lay beyond, or of the feeling of the wind beneath it’s wings. If you set the bird free and encourage it to fly and fend for itself … it will never return to the cage; and if you do capture it and return it to the cage, will it sing as sweet?


There is a risk in a non-committed Agile adoption that if you develop genuine Agile culture in a team and then opt (for holistic organisational cohesive reasons) to roll back to a waterfall model, then you are forcing your now “free bird” back into the cage. It is one thing to have never had responsibility or freedom, but to have had it, and then had it taken away can crush the spirit.

Organisations when considering an Agile adoption need to be cognisant of the risks they are undertaking. The change involved is not simple or pain-free, rolling back may suit those that never embraced the values, but for those that did achieve it, rolling back will be even more destructive than the initial adoption. I would warn that those that have tasted freedom, will not accept confinement, and if the organisation cannot sustain, or compensate for it, then they may fly outside to freedom.

How to measure your Agile delivery?

I am often asked what to measure in Agile delivery. The common measure appears to be velocity, which I concede is useful to track and is also readily available (assuming scrum) but, as is well discussed in articles and blogs, it can be dangerous to measure this publically as it morphs into something that is judged. It can end up be held it as a target for the team and then Goodhart’s law kicks in https://en.wikipedia.org/wiki/Goodhart%27s_law and what was useful information is now a manipulated artificial construct to give the desired answer. (Using it internally to help project delivery forecasts is very sensible – just don’t assess the team against it).

So given that, what would be a sensible answer? I would advise digging a little deeper into the question rather than giving a snap answer. Information is only as good as the decision made off the back of it (and by extension information provision when no decisions will be taken is waste). Why do you want to measure the Agile delivery? And there are a few honest answers to this:

  • I want to see how much value the team are delivering
  • I want to ensure the team aren’t slacking off
  • I want to understand how the team are performing / struggling

Each of these really justifies a different approach.

For Value you need a discussion as to where the organisation perceives value – and this usually causes some uncomfortable moments when comparing existing process to fundamental Agile values – Working Software over Comprehensive Documentation and Working software is the primary measure of progress. The real measures should be associated to the benefits the organisation reaps as a consequence of the software but that can be a little unfair on the team (as they are not responsible for the requirements) – but critical for the organisation as a whole. Considering just the software delivery then Cycle Time is probably the best measure. How long it takes from idea to delivered software. Measuring, and by extension managing, this will also encourage the organisation to break their deliverables into smaller units. The benefits of the delivered work should still be tracked to avoid a situation where a highly efficient software delivery outfit rapidly and consistently delivers a stream of valueless changes.

The “I want to avoid slacking off” is a difficult one, and is probably always just under the surface, even if they say value – they may really mean – I need something to beat the team with. Despite what they say, what we really have here is fear of loss of control, someone who maybe accountable but has little influence over delivery. This suggests a structural issue with people put in management positions abstracted from delivery, and it also suggests a culture where trust is lacking. The Product Manager or Project Owners on the engagement should be close enough to the teams to have an opinion on current activities and levels of engagement. They will have a first hand understanding as to the reasons behind delivery ups and downs (reflected in velocity) associated to complications or setbacks identified in development (perfectly normal and expected in a complex industry). I usually suggest these people provide sprint activity information to the programme, which can decrease overtime as the management structure adapts.

The third request is a little refreshing and implies a maturity often lacking. This says we are concerned about value – trust the team and want to know when to try to help to support them. To understand what to measure here requires a little “Genba”, real world observation of how the team copes with adversity. Systems are inefficient when operating at 100% capacity, any change to an input variable that worsens the situation will cause failure, so the more dynamic the system the lower the optimum operating capacity. The difference between the optimum and the maximum could be considered contingency – if you want to give support to a team, measure the use of that contingency. This will give an indication of when and by how much the team is struggling and therefore when to act. This could be overtime, or compromising the Definition of Done, items added mid sprint etc.

As a metaphor consider a racing yacht, if you just record the speed then you may miss the unsustainable efforts the team are making to achieve it. Instead note just how many people are hanging off the side of the boat – and how long they have been there, they can’t hold on forever – and if they are made to, then the yacht will speed along until they drop off, at which point the yacht won’t slow down, it will capsize.

An Estimate is a guess in a suit, you can do better than that

New project, new team, new opportunities, a fresh start for everyone, a room full of hope and optimism. Then someone senior comes in and asks for an estimate for the full scope of work – and things start to spiral downwards.


There are three answers to this question, the right one, the wrong one and a refusal to answer. The right answer is impossible, even if you do get it right it will soon be wrong as the scope, and hence the question, will soon change, which leads us to the second answer – a wrong one and for the majority of circumstances this is what is provided.

The problem with an estimate is both the background from where it comes, and what is done with it. If you have a heavily caveated range that is used to inform medium term planning with an awareness of the risk, then that is great. If it is a guess that is treated as a commitment – well we all know the trouble that causes – but people still ask for them.


So firstly why are we so poor at estimating with the software industry? There are other industries out there that appear to be able to get things done against simple predictable plans – yes a few things slip, but houses get built, gas pipes are laid and aircraft get assembled. The important difference is one of experience. Software is repeatable at very little cost and effort – CTRL C, CTRL V, this means that the majority of large software projects are new – never been attempted before by definition. Therefore the solid experience that drives the confident project planning in the industrial sectors is absent in the software industry. Software is now largely a creative / knowledge based activity, like graphic design or management consulting. (It is important to note that other engineering disciplines also have these issues when attempting something unique, so automotive design, large bespoke construction projects etc).


So what is the solution? It isn’t realistic to respond to every request for an estimate of when something will be ready with a wise frown and, “it will be done when it is done”.

Existing and well discussed techniques such as Story points and then breaking user stories down into Tasks and estimating those Tasks in hours is a valid approach but suitable only for the current planning horizon and is unfeasible for an entire backlog, indeed to attempt it for the entire backlog would require such extensive analysis and design you are pretty much back at waterfall – the scope will likely change before you finish.


Understanding the issues with estimation is more a psychology than technology challenge. Typically we estimate by drawing parallels between the work in question and prior experience, but humans are naturally self centred and optimistic, we exaggerate the parallels between this work and previous, undervalue the substantial differences and have a rose tinted memory of how it went last time.

The scope of work to be estimated can be considered in the context of the KNOWNS, these are the same “Knowns” that Donald Rumsfeld referred to on US defence policy, although he only mentioned 3 of the 4.


These are:

  • Known Knowns, these refer to deliverables that are well understood and the premise that short term user story estimates are still valuable.
  • Known Unknowns, these are deliverables that we are aware there will be issues and problems with and those problems are not solved, could be easy, could be difficult but fundamentally require investigation to understand. These requirements are the reason we apply contingency or a margin of error on the Known Known estimate – but without any possible logic as to what that margin should be. The advantage here is that the team will have a fair idea about how to improve their understanding of total work and what activities will help them to become more precise.
  • Unknown Unknowns, the black swan events. These refer to issues that are not understood and not even known to exist. Problems that nobody has even considered would occur and usually lie well outside the realm of contingency planning. These issues may have minor impact, or could completely
  • The last and the most pernicious of the four, and for that reason the one that Mr Rumsfeld wasn’t brave enough to mention, are the Unknown Knowns. These are things we know but choose not to accept or allow for because recognition is so disruptive to our social construct that it is more comforting to create an illusion where they do not exist. In wider society things like state oppression of minorities are often raised as examples, in the less dramatic world of software delivery, issues like stakeholder politics would be a better example. When estimating deliverables it is important to try to surface these as much as possible and be honest about their influence – they typically supress estimates.


A solid appreciation of Complexity Theory, and an awareness of the “Knowns” should enable us to look at the work to be estimated from an informed perspective, and should give us good, communicable reasoning as to why a firm estimate of complex software deliverables beyond our planning horizon is so difficult as to be fruitless. However, good examples of estimation techniques used on complex (unpredictable) systems do exist – the best of these is the weather. The weather later this week is projected, not by a group of experienced meteorologists given today’s information, but by adding that information to all previous information and passing it through a very complex model that is continually evolving. This approach can be applied to our software delivery to deliver long term estimates but now we can appreciate the difference, what we would be providing is no longer an estimate – a guess in a suit, but a forecast. A FORECAST is a statistical likelihood of something happening given historical information and a set of input data. The Monte Carlo simulation approach is a well documented version of this and can be simplified dramatically to be easily employed and still gives very helpful, and importantly fast, forecasts for software delivery.

All forecasting tools rely on data, and therefore before any forecast can be delivered, the team need to make a start on the delivery and record their performance. Once the team have delivered 10 items, as long as those items were not chosen based on expected size, then the probability of the next item taking longer than any previous item to deliver is 5%. Assessing the full list of deliverables in this light – taking the 50% mark would enable a team to rapidly give a most likely forecast and bound it by X% either way. Then after each additional item is delivered the model is improved, and the remaining work reforecasted refining the given result.


So when someone asks your team for an estimate, the first thing to do is have a discussion to see if this work could be described as a KNOWN KNOWN, and deliverable within your planning horizon. If so, then proceed with a breakdown by User Stories and Story Points, compare to velocity and give a duration with heavy margins of error.

If the work is less well defined or substantially larger, then divide it up and compare against your historical delivery through a statistical model. If you have no model, because you are a new team or the work is completely different to anything previously undertaken, then you have to have the awkward but honest discussion explaining that you can’t give an estimate until after you have started, “so give us a month to deliver something of use and we’ll then be able to start to understand enough to give future projections”. Now if that isn’t acceptable then I suppose you could guess what you think you think they want to hear, and revise that figure after a month or so with something more credible – good luck with that.


Keep in touch on #philagiledesign

Improving Agile team performance

I have often been asked my opinions on teams that are not performing. Typically this is prompted by an observation of going through the motions on a Scrum ceremony that they have witnessed. I have seen the same situation a few times now so thought it worth sharing.

So consider this team:

They appear listless, little passion or focus. They have the necessary process and artefacts but more from a sense of obligation than because they are actually deriving any value from them. They probably get together as a whole team to discuss stuff right at the beginning of the sprint and then drift off into smaller groups at the start of sprint ending with a minor panic in the last couple of days leaving sprints incomplete. Standups are largely pointless, mumbled status updates to the Scrum Master. They will often respond with excuses of interdependencies or lack of understanding. Their “Definition of Done” is a little hazy and regularly compromised to get things though at the end of a sprint and for the same reason, smaller pieces of low priority work often get put into sprints to enable the team to take some easy wins – to keep THEM happy.

It is easy to point the finger at the team, kick them a little bit, maybe even shout and mention things like performance reviews, objectives and the like, but for a team to have gotten into this mess there must be something systemically wrong and pep talks will have short term benefits at best.


So the Scrum Master is at fault, well maybe. Typically I find the fault is in the system the team is in and either the Scrum Master is part of that system or has given up fighting. Watch the Scrum Master. If they are busy directing the team flow like a policeman at a busy junction, having quiet chats with the Product Owner and separately with Architects and Project Managers then yes, the Scrum Master is part of the system that is killing the team. If however – as I have often mentioned, the Scrum Master appears like the rest of the team, quiet, reluctant, weary and at a loss, then you probably have a respectable Scrum Master that isn’t sufficiently powerful to break the system and therefore is as beaten as the team.


A first starting point is to look at team size, most of the situations I have seen have been compounded by over sized teams. I know many people in the Agile Coaching industry that would argue that you can have teams up to 11 and yes you can get things to work with larger teams, but you need the system to be working well first; and many of the issues that affect smaller teams have a more significant impact on larger ones.

Agile is fundamentally about people, it is light on process by design, and process enables people to be directed forcibly. The Agile approach depends on self direction and self direction thrives on motivation. Fail to motivate the team and they will become despondent and without the structure and direction in a waterfall model, they will split, drift and performance will be a fraction of what is possible.

Motivation in an Agile context typically stems from empowerment and an appreciation of what they are working on, not just realisation of the final product but also a direct understanding of their element of it.


Given this there are some demotivational factors to look out for:

Component teams – delivery teams that are working on technological slices of the application have a much harder time to appreciate the point of their work, and therefore their impact on the value. Because it is harder to see the final solution it is also much harder for the team to drive out an MVP, component teams often gold plate because they struggle to be able to identify which features are the most critical.


Specialists – A team of specialists that are able to completely break up the work will find themselves operating in increased isolation. The handoffs between team members will start to become increasingly formal in an attempt to ensure responsibility. What this means is each team member looks out for themselves to ensure that when something goes wrong they are able to point the finger elsewhere. The team will start working when they act as a team, and that can be helped though cross functional delivery.


Knowledge of the users – have the team, not a management representative of the team, but the team themselves, ever actually met and talked to the actual users of the system? People will probably have spoken to the team about the users, may even have involved the team in creating personas but there is something very powerful about actually meeting them. Seeing the whites of the eyes of the people you are building things for. It is about consequence, about responsibility. It is harder to cut corners and deliver substandard product for someone you have actually met and have a relationship with.


Culture of Management – This is the most subtle and pervasive of the issues, and also the one that typically gets worse as performance issues grow creating a vicious circle. A poor team typically attracts more management attention, who will act to direct and control the flow and definition of work. What the team needs is empowerment, freedom to own their own process.  Did they write their own definition of done (and not have it “rephrased” by someone senior)? Have they chosen their own tracking and reporting templates?

A really important piece will be the decision makers. These decision makers need to be in the team and making decisions with the team – in the presence of their team members. This makes their decisions team decisions, as opposed to decisions made on behalf of the team. It is an important but subtle distinction. Project Managers and Architects are the two roles that this usually applies to.


In short if you have a team that appears to be drifting and disinterested then:

  • Reduce the team size as much as possible – facilitate the team to split maybe
  • Empower the team – stop making decisions outside the team on their behalf
  • Connect the team with the users
  • Enable the team to own their own process
  • Give the team a slice of the system where they can own the definition, delivery and deployment of something of value


Digital Transformation – No, just having a website doesn’t count!

Recently a colleague asked me about Digital transformation, and how best to express it; and more importantly, what practical steps to take to start to achieve it.

As I understand it, Digital is about using information to shape your product line and sales strategies to the ever changing market, using the technological capabilities of the modern age to tailor your product offering and operate at lower cost.

It is not achieved by simple having a website!

Moving to Digital is a business strategy that leans on IT’s capabilities, it is not an IT strategy. Digital is moving from selling products that consumers use to fulfil their needs to selling the actual use – servicing the NEED – your tangible product may be part of that but the engagement is based around the customer not around you.

To illustrate this, consider this evolution – a hard working peasant farmer with his cart of cabbages some time in the middle ages. One man – some cabbages, selling them to people that a) find him, b) want a cabbage for whatever purpose. Now fast forward a few hundred years and his cart has become a shop, another hundred years and a catalogue is published for mail order and then last week he launches cabbage.com. Massive progress, but hold on, still one enterprise, some cabbages, selling them to people that a) find him, b) want a cabbage for whatever purpose. Finding him is now easier due to the internet but fundamentally this is still the same concept.

This is not a digital transformation; this is channel shift to new channels as they become pervasive. There has been more than one company disappear from the market place that had full channel coverage but hadn’t innovated their product line.

Mr Cabbage man is still fundamentally selling the same product and expecting the same approach from the customer. The customer must still have a need that they identify with your product, approach you to purchase it and then use the product to address their need.

Going digital is more like the next step from the data driven product placements that have been so effectively used by the supermarkets. Through extensive data analysis of purchases, footfall, and buying patterns the supermarkets have been able to change their layout and merchandising to better tap into the underlying need of the consumer. Originally the shop would sell ingredients, it was the consumer’s need for a meal that drove that purchase but it was still down to the consumer to identify which ingredients were needed and later to assemble them into a meal. The introduction of ready meals in the 1980s was a product shift based on addressing user needs. Digital is the next step along that path.

Going to Digital means the ability to have a comprehensive understanding of your customer, and then offering services (based on known experience and products) tailored to the exact customer. Technology now gives the possibility of providing specific services to the individual and then automatically matching them to the best service offering. This is can often be done with minimal human decision involvement enabling much lower cost to operate.

Many IT buzzwords start to crop up at this point: Big data, CRM, analytics. These concepts are what really lies behind Digital, it isn’t really the IT stack or web screens – that is just what it needs.

Moving to Digital is considered a challenging cultural change because the change is not in the IT department – it is a change in the business, in the product offering and your understanding of their customers and your USP, IT will help you deliver the new world, but cannot lead it.

Many companies are now employing a Chief Digital Officer (CDO), this is a very difficult role because they are responsible for breaking out of IT, you could argue (if looking for sensationalism) that their job is to destroy the IT department – to bring technology into the heart of the business to be something we all do, not something “they” do.

It somewhat misses the point if the CDO sits under the IT director and is basically manager of online product offerings, although they would be in good company. I would imagine that the relationship between CIO and CDO would be at times tense, and to work they must be equals.

But practically speaking what are good steps to take to a digital transition:

  • Understand who your customers are, and more subtly why your customers are. What is it about you that makes them come to you – or “come back” to you.
  • Next ensure that the data that you are currently capturing is accessible – and cross referenceable, and not just along the existing product hierarchies. I remember back when I worked in retail that we could give really detailed sales information along product lines and store lines, so general merchandise, men’s shirts, that range, that size, in blue. But if you wanted aggregated info you were limited to that hierarchy, so you could find sales for all shirts in that range, but what was needed was sales for ALL BLUE clothes… but that basically meant you had to know the code for every blue item and run a query asking for each item in a list.
  • Then add some analytics on existing product lines.
  • Then get someone to actually look at this stuff, someone with a CRM background – there is too much critical work to just add this to someone’s existing work.

All these steps will help your organisation understand what it is selling, how and to who and why. From there they can try to understand what your customers are really wanting (of which your existing product is a part), and then you can start to consider what service you can offer to address that.

Don’t rush to solutionising a software build to a problem you haven’t validated and you can’t just point to a picture of your product on a web screen and declare digital success.

Empower your Scrum Masters

It is all very well people talking about Agile and how great it is, but giving good advice on how to take steps to get there, without being there, is difficult – and there is a good reason, change is a hugely personal, context dependent issue, therefore advice without an intimate understanding of your situation can be damaging. However I have recently aligned a few thoughts in my head following personal experiences, discussions with others and some powerful presentations I have attended, and believe that there are a few generic steps that can help.

There are three concepts that I think neatly reinforce each other: 

Firstly there is an acceptance that an empowered team is a positive force; Dan Pink’s work gives credence to what many Agile deliveries have empirically shown in recent years, but how to achieve empowerment? You can think of power as points, you can only redistribute them, not change the quantity as it is the ratios of power that are important. So giving more points to the team means that they are coming from somewhere, and that is usually the first hurdle – people don’t like ceding power.

Secondly, related to this, is the quandary that traditionally minded organisations have with how to promote a Scum Master. People have to move up, there are levels… and typically each level dictates to a greater or lesser degree to the level below. That DICTATION implies a lack of empowerment at the level below. Some organisations attempt to navigate round this by promoting Scrum Masters to Agile coaches; whilst this is a possible career path I think this unsustainable and it requires great patience and abstraction to be a good coach – so as to not become an “Agile” dictator, that imposes lots of good processes but fundamentally misses the point, disempowering the teams under their CONTROL.

A better answer to the Scrum Master promotion question, is one that starts to challenge the traditional hierarchy, instead of actively moving the person up, instead, remove the person above them. Now the Scrum Master retains their team awareness but can bring the responsibility and authority of the higher level to the team, it is like a vote of trust. It resonates with the concept that you promote a Scrum Master to a better Scrum Master.

The final point is one of MANAGEMENT. Management as a concept is really born out of Taylorist Scientific Management from the 1910s – 1920s. Fundamentally it separated the thinking from the doing. It aligns with McGregor’s 1960’s Theory X and Y premise, where X type people dislike work, prefer to be directed and often have to be forced.   When applied this made sense, a large majority of the workforce was uneducated and most work was functional rather than creative.  The auditors of Theory X can be labelled middle management, a swathe of most organisations that are responsible for “managing” or directing and coercing the work that others are doing.  

Many people (far better and more respected than I) have suggested that (at least here in Western Europe and the US) that the workforce and nature of work have progressed to a point where this approach is no longer appropriate and that the associated trappings such as strict hierarchies, work allocation, and most project controls are a legacy hangover. This is the age of Theory Y, where work is natural, people thrive in self direction,will actively seek responsibility and where achievement is its own reward.

I recently worked on a very successful project as a Scrum Master without a Project Manager, now there were lots of things that needed doing – many of them would fall into the project manager role description but a key thing that wasn’t missing was Management, we could have done with help on project timesheeting, project account keeping, project reporting, project risk and issue logging, all of these collectively could be called project administration, but not project management. The team was self managing, and it would have been detrimental to have imposed external management onto them.

So where am I going with this… I would suggest that if we accept that empowered teams are desired, and that Scrum Masters need some sort of career path and that middle management is a legacy of Taylorist ideology then… when approaching an Agile adoption, empower your teams by removing as much middle management as possible from around them, and critically from above them. However to cushion the transition and keep the rest of the organisation comfortable then supporting your teams with a project administrator may be a sensible move.

Own your process – or it will own you!

Process is a highly emotive topic, there are one set of extremists that believe that everything needs a process and even if you claim there isn’t one – actually if you look hard enough there is, and one the other side there are those that suggest that all process is evil and a waste of time.

Typically in these frothing debates the truth lies somewhere in the middle.

When you get down to the real ethos about Agile delivery it is a bunch of people getting down to do what is necessary to make a genuine improvement to a situation, reassessing their situation and then repeating.

Stripped bare and free of politics there are no requirements, no roles, no reporting, just people doing stuff. This works brilliantly in the teeny start up world, can you imagine documenting your first requirement when starting your own company, or allocating roles between 3 people as to who will do what? no of course not, everyone will do what is necessary, as well as they can, asking help when they need it.

So why doesn’t this scale? Even a single-team Scrum implementation brings a role, (Scrum Master) and definitions like User Story and Sprint and Velocity. What has happened?

Well critically the people doing the work are typically one step away from the passion of delivery, the real success criteria – the PURPOSE. Now we need to consistently communicate to a wide audience what is going on.

In a start up – the consequence of failure is so great that you’ll do whatever it takes to get over the line and don’t need to justify your self to anyone; at the other end of the spectrum with a heavily controlled PRINCE2 type environment it is entirely possible for an individual to do everything they are supposed to and deliver no value on a failing project.

As things continue to scale more process starts to creep in, this is usually as a consequence of lack of relationships, lack of a true, trusted connection. Process is a consequence of a problem – and not always the right solution. We need to acknowledge that the process is an inferior replacement to a trusted, close relationship and should be introduced only to the point where the people concerned are able to operate almost as well as they would in the context where it wasn’t needed. The process is not to be aspired to, it is the necessary evil. It is what you do when you can’t get people to work together due to location or contract or politics or possibly just personality

Process is a pollutant to your system – only introduce that which you truly need.

So how much do you need?

There really is only one way to find out, start with none and introduce process until you find things start to work and then ceaselessly attempt to remove it as people work together for longer. Generally each step you take will make the situation better and this lean (both in process and headcount) approach will be cost effective.

The alternative is the PRINCE2 or SAFe approach which starts with a HUGE pile of process, roles, terminology, gates, documentation etc and suggests that within it are all the pieces you need. If you are unsure exactly which bits you need in your entirely unique situation both in terms of context and people, then just apply everything. Once you have everything then you can start to remove bits.

But that is the difficult part, which bit to remove?  The consequence of change when operating this way is the reverse, change the wrong bit and you move from a ponderous expensive working system to a broken one. Also the people likely to be tasked with deciding which process to remove are part of the process, and one thing I have learnt is that it is rare for someone to suggest that they are the problem.

Removing process is especially difficult to justify in a client supplier relationship. Process is expensive because it requires a lot people to manage all the people that are managing all the process artefacts that manages the work that the remaining individuals are actually doing. But once you have set the precedent to the client that that approach is necessary, being able to later remove people and artefacts with no impact on performance is awkward and embarrassing – it also negatively impacts revenue – easier to just continue on with the client losing but being ignorant of doing so. Savvy clients will challenge the initial setup but there are many that are not, and it is in the best interest of the big consultancies to keep it that way.

Identifying the processes and tools you need should be something mutually agreed by the team – the whole team, and then continually reassessed. If the team has requested something then they are far more likely to abide by / use it. Externally pushing something on the team will be resented and resisted – which typically results in the introduction of someone to enforce it and you can see the bureaucracy mount… you will be owned by your process!

This is why we have retrospectives, to assess the approach and change it, where retros are not productive is when you have lots of externally enforced processes that can’t be changed. What is the point about discussing something you can’t change – if you can’t adapt why bother inspecting? Before long you are back in the world of a disempowered, disinterested team burdened by bureaucracy.

So, free yourselves, cast off your process and then look at all the little pieces on the floor. Now pick up the bare minimum and see how you get on.

Agile Manifesto – The Dark Side – Part 4 of 4

Finally reached the last of my 4 posts looking at the other side of Agile. The last line of the manifesto:

Responding to change over following a plan

This is slightly different to the other 3 in that it feels obvious, common sense, but so does the right hand side when considered in isolation – following a plan – well Duh yeah, who doesn’t, no plan no clue!

So making a case for having a plan is slightly easier, but then what is the problem, what do the agile community have to say about planning that warrants a direct attack in the manifesto.

When explaining Agile in training events or discussion groups I usually enhance this line with an extra word – makes things a little more colloquial but really stresses the point:

Responding to change over BLINDLY following a plan.

Now the issue is clearer. Having a good understanding of where you are, what is going on, the consequences of dependencies and whether we are likely to deliver what we thought we would when we thought we would, is a good thing. The problems occur in three places:

  • When the plan attempts to predict beyond your delivery horizon
  • When there is a lack of acceptance that the current position isn’t the planned one
  • When achievement to the plan is more important than delivering Value

I often joke about plans that if when you start a project you have a plan that says you’ll deliver in 18 months time, on the 14th of March for example, then can we pay upfront for a massive launch party on the 15th March….? Of course not – so why so much effort, scrutiny and confidence in something you don’t truly believe in?

The best plans enable change, those that don’t are either ignored, undergo endless expensive change control or drift off into fantasy in comparison to reality and then suffer catastrophic failure.

The ability to change a plan isn’t about changing the right answer, it is about avoiding the wrong one. Don Reinertsen explains this wonderfully with the following: If you were offered a chance to guess a three digit number for three dollars and if correct you win $3000, would you take it? Statistically you are break even. Now if I give the option to pay $1 for the first digit and then be told if correct before paying $1 for the second digit, and the same for the third. Which has the biggest payoff? The later costs the same to play, wins the same but is 96% better value, and it isn’t because the player is more likely to get the right answer, or because they pass less or win more. It is because they can identify a losing situation and can change their plans.

So within the wonderful world of planning, which elements should be encouraged? Engaging in a truly Agile delivery does bring some challenges to the business that are required to consume a constantly changing / enhanced technology landscape; the training material approach will need to adjust, communications need to be aligned for example. Having a high level plan of what features are in the pipeline will keep these departments together and then a low level detailed plan of what is being worked on NOW will enable the associated organisational change management activities to keep up.

A roadmap, of the type Pichler espouses for example:


is a great plan in that it indicates direction and purpose but doesn’t give details that can instruct delivery teams blindly.

At a sprint level – when in a scaled environment, ensuring that after sprint planning all teams are aware of all dependencies is also an important activity – how this is done – central google doc, notecard for reference in Scrum of Scrums is contextual.

Eisenhower once said that “Plans are worthless, but planning is everything”. What he meant by this is that through planning you get a clear understanding of what is happening now, an awareness of all the moving parts and how they interact – and that is vital because it enables you to respond. The reasons behind why the plan being worthless can be answered with another great quote from Moltke the Elder (19th Century Prussian military strategist), “No plan survives first contact with the enemy”. There are too many variables at play to expect any long term plan to be expected to remain static.

In my experience the benefit of planning over following a plan is that it forces acceptance of the realities of the situation you are in, free from the illusion of where you’d like to be.

Agile Manifesto – the Dark Side – Part 3 of 4

It has been rather too long between this post and the last – consequence of client commitments, apologies.

Last post I looked at the second line of the Agile Manifesto, considering what is suitable documentation standards in Agile Delivery, this time I’ll look at the third line.

Customer collaboration over contract negotiation

So just how much contract negotiation do we need, and taking a step back what really is a contract?

I suggest that a contract is an agreement that specifies the details of the consequences for failure.

Agreements are essential for group delivery, it is what enables one individual or group to operate independently from another. There is usually some element of collective benefit, either both sides are working towards a common goal or there is a transaction attached.

Good agreements run on trust, each party has respect and trust in the other to deliver as expected, and therefore what is really at stake for failure is that trust, which is often the most important powerful thing we have. Agreeing to your spouse to be home for 19:00 is a good example. Within Agile delivery you can express Sprint commitments , WIP limits and acceptance criteria as agreements.

Agreement is based on trust and respect, a contract goes further than these honour based agreements, extending this to provide consequence to failing to comply with the agreement.

Firstly contract can mean different things to different people in different contexts. I currently find myself in a supplier /client type relationship where the contracts are legal documents and stipulate costs and disclaimers and liabilities and the like, at other times I have been working in house in which case the contracts are more intimate and are reflections of commitments between departments or even people.

There are many articles on commercial Agile contract structure / writing and I am not going to tackle that subject here – save it for another day. In summary I’d say keep it T&M and keep your contracts as short and easy to renew as possible.

It isn’t contracts that the Manifesto makes reference to, but the negotiation. Negotiation is an attempt to reach an agreement that is favourable to you. I’d argue that the best (more realistic) contracts are those that you’d be willing to sign up to either side of.

Agile delivery is all about safe to fail experiments, having the freedom and flexibility to try something and then take the learning, we wont be right all the time but the really important part is the consequence of failure is not catastrophic.

Excessive negotiation implies that you are looking to tip the balance of in your favour – it is less of a partnership now and the trust is being eroded. In a one sided contract either then likelihood or consequence of failure on one side is greater than the other – and probably known to be so. Risk is not equally shared. This is not limited to legal contracts, a senior manager in house can make it clear the consequences of failure to deliver a sprint in terms of performance appraisals, future projects or weekend working.

The premise of the manifesto statement is to put the interests of the project delivery ahead of those relating to an individual or a supplier; an unbalanced contract will encourage behaviours of self-protection, as opposed to collaborative, delivery facing behaviour. Teams will start to look to identify where they can cut quality without being noticed, or the scope details of feature items will be expanded – in addition to other nefarious activities.

The sad truth is that in both scenarios, everyone loses. Either the project fails or the client has over paid and is unlikely to offer repeat business.

So we value contract negotiation, in that it gives us a framework to deliver, it makes clear the agreements and a fair set of consequences, negotiation to a point where you’d no longer sign the other half of the contract… now then I believe it to be counter productive to delivery.

The ultimate contract is a partnership, and the ultimate consequence is loss of trust.