This is the final instalment of a three part series in which I cover my methods of delivering successful business outcomes via software.

We have now decided to proceed with a software initiative. We have a well defined goal, a high-level solution scope, an awareness of the risks, assumptions, issues, and dependencies that exist, an idea of the potential ROI of the initiative, and most importantly: a budget within which we are confident we can succeed.

Now comes the hard part: actually delivering it!

Deliver

I’d like to preface this with a disclaimer: this is not an ‘introduction to Agile’ post.

If you’re looking for a primer on the why of Agile software development, I highly recommend listening to Kyle Aretae talk about Diamond Agile on the Agile Uprising podcast. As Kyle states, the basic tenants are always:

Small teams, aggressive prioritization, feedback loops, small batches of work, long term investment.

Just Words

I made a similar comment to the quote above in an Agile discussion within a local developer group recently, to which someone challenged “Just words”. They were, and are correct. It is easy to write about Agile in a way that over-simplifies it, that generalizes it to a point where many unique organizations and people can broadly grasp what the core ideas are. The danger in doing this is that the words do not convey any useful information as to how to be Agile within your particular context, or how to solve the difficult challenges that will need to be solved to transform the way your organization delivers software.

For that reason, I’m going to avoid talking about Agile.

Key Elements

Instead I’d like to talk about:

The conditions organizations need to foster
The behaviours teams need to exhibit
And the dangers teams need to be wary of

In order to give them the best chance of success in software delivery.

Conditions

Strong Development Capability

Forming the backbone of a successful software delivery are strong software developers. There is no substitute for this capability, and it comes first in our list of conditions for successful software delivery. Developers are at the center of executing a given initiative, and need to be capable of doing so. This does not mean we expect our developers to be 10x Developers, Rockstars, or any other vaguely offensive archetype. What it does mean is that we expect the team to have a balance of skills that when wielded can solve the problems present in the delivery in efficient and effective ways.

Strong software developers can reason about pragmatic solutions to difficult problems. They have many tools in their toolbelts, and have solved many problems with these tools over time. They truly understand what extensible, maintainable, testable solutions look like. They can reason about how to wisely invest their efforts for greatest reward.

Software development initiatives are accumulations of thousands of small decisions, and many of these decisions are made by the developers on the delivery team. A team of strong software developers can ensure that this accumulation forms a strong and resilient solution. In a team whose skills do not match the task at hand, the accumulation may end up being death by a thousand cuts.

One Team, One Dream

Next to capability in importance is culture and alignment. And this isn’t just in the IT department, or the development team, this is within the organization. An organizations culture in relation to software development can mean software delivery can be viewed as a collaborative journey towards a goal, or as a negotiated set of compromises towards fulfilling a mandate.

In some companies, who have a divide between The Business and IT, who treat IT as service and cost centre instead of as a creator of value, software delivery will always be a challenge. These organizations will always view on time and on budget to be more important than value delivered. Decision making will tend to fall outside of development teams, with teams given solutions to build, instead of problems to solve. When things don’t go to plan, these organizations will seek to attribute blame and fault, rather than acknowledge the fact that they are solving challenging problems, and to learn from failure.

In other companies, people work together collaboratively towards a clearly communicated goal. Everyone assumes everyone else is working with integrity, discipline, accountability, effort, and respect, doing the best job that they can given their environment, information, and tools, to progress towards the goal. Decision making is subordinated to the appropriate level, with leaders and managers understanding that the best people to create the solutions are those closest to the problem being solved. These organizations will focus on embracing reality, empowering their people, collaborating to solve challenging problems, and ultimately create value-driven cultures that are far more effective at delivering successful outcomes.

Strive to create the latter.

Autonomy, Mastery, and Purpose

A capable and aligned team still needs to be motivated to continually kick goals for their organization. Motivation for developers is intrinsic - it comes from within themselves. Many modern studies have been done on what motivates people, which expel the notion of carrots and sticks being effective, and instead work on creating environments in which motivation is best cultivated. Dan Pink’s Drive is a must-read for anyone looking for a deeper understanding on what motivates people who participate in creative work like software development.

So how do we support and nurture intrinsic motivation in our teams?

Autonomy - allow teams to choose what problems the work on, who they work with, what technologies they utilize, what techniques they employ, when they work, how they work. The more freedom you can give a team in pursuing a goal, the more they will be motivated to own it.
Mastery - ensure teams have time to master their craft. Allow them to explore new techniques. Embrace failure and learn quickly. Ensure a culture of continuous learning and improvement exists. Encourage and support a high bar for quality and capability.
Purpose - is dual-faceted for developers. Many developers, myself included, find strong purpose in technology - using our capabilities to make people’s lives better via tech is at the core of our being. Along with supporting your team realising their own individual sense of purpose, communicating a vivid vision for the organization that people can connect with, that resonates with them and imbues them with purpose, will motivate people when times are tough.

I’m planning on writing a more detailed post on this topic in the future, so stay tuned.

Discipline Is Mandatory

A running “joke” I hear from many program and project managers in large enterprises is that Agile is just software development with no up front planning, ad-hoc decision making, no estimation or budgeting discipline, and no accountability. As one program manager at a large utility company recently scoffed to me, “I wouldn’t use Agile to build a dam!”. He must not be aware of the margins built into construction project budgets to accommodate the risk of their up-front planning.

What is more likely is that they have fallen prey to attempting to manage an “Agile” delivery run by a team that lacks the discipline to execute successfully.

Discipline is hard. It involves constantly scrutinizing, inspecting, adapting, foreshadowing, planning, scheming, spiking, communicating, collaborating, all whilst still getting shit done. Good teams attack problems aggressively. They do not postpone. Someone once told me that good developers have low pain thresholds - as soon as something bites them, they need to prevent it from biting again, immediately. Nothing gets swept under the rug. Everyone owns something. They are responsible for the outcome, and accountability is high within the team. They have hard conversations within the team and the wider organization. They do all of the less-glamorous stuff that is required to support and facilitate good Agile software delivery. They do the needful. They admit failure. They improve.

All of these behaviours are backed by discipline - individuals don’t wait for ‘motivation’ to refine the backlog, send out communications, drive a dependency, or validate with users. They have the discipline to do what needs to be done, when it needs to be done.

With the conditions now set within our team and organization, we have an environment that is conducive to software delivery. Let’s move on to execution.

Execution

Always Be Setting Expectations

Whilst it doesn’t have the same ring to it as Always Be Closing, setting expectations is the most important part of software delivery. It should be the very first thing we do, and the very last thing we do.

Business stakeholders with aligned expectations are connected to reality. They are armed with up-to-date information about the software initiative being delivered. They were well-primed at the start of it, they participate in constant feedback loops, they are supplied detailed summaries at short and frequent intervals, they are involved in all decision making, and they have an always-evolving but clear overall picture of the delivery. They feel like they are “on the journey” - one being directed by a competent and capable delivery engine.

Stakeholders who have been engaged and engage in this fashion are almost always satisfied at the end of a software delivery - there is no surprise, they know exactly how the end result was achieved at a detailed, nuanced level - as they were involved in producing it!

Set expectations on the first day regarding:

What our goals are
Who is responsible for what
What we are doing
What we are not doing
How we will execute the delivery
How we will work as a team
Current known risks, assumptions, issues, and dependencies

Get To Production, ASAP

Once the team and the wider group of organizational stakeholders and sponsors are primed and aligned, we want to make a bee-line for production. Ask the question:

What is the most direct route from “nothing”, to being able to ship “Hello World” to production, in a repeatable, reliable way?

Why go push so hard to get to production straight away? Surely the automation can wait, we can F5 the software for a while and build some boilerplate or the first few small features before we sink effort into that endeavour? Or perhaps we can do some Right Click > Devops to a skeleton environment for a while?

Parting the sea to production allows your team to start shipping small, frequent increments for inspection reliably and repeatably. It is the primary conduit of our feedback loop. Feedback is important at many points, but none so much so than feedback on the working software running in production.

Note: Sometimes we may not be able to provision a production environment due to constraints. This is okay, but still not optimal. Remember: there is no production-like, just not-production.

Build, Measure, Learn

Our team has a budget, and a goal, that were created during Discover and Decide. As soon as the delivery starts, we begin consuming our available budget. We need to make sure that we validate that the budget (and effort) we are spending is moving us towards our goal.

Lean Startup, an approach born from the dotcom bust of the early 2000s which saw startups need to become much smarter with how they expended their capital since it was no longer growing on virtual trees, is a methodology that allows us to do just that - validate that what we build is taking us towards, or away from our goals, before we reach the end of our budget (or seed funding).

Building is a combination of creating and exploring hypotheses, and writing relatively small amounts of code to test these hypotheses. The hypotheses we explore tend to be cause and effect - “if we build x, we expect y”. All software requirements are stacks of assumptions that in aggregate say “If we build the described functionality, then we hope we will have created something that moves us further toward our goals”. The cheaper and faster we can verify or disprove each hypothesis, the more efficiently and effectively we can build towards our goals.

Whether we are working in a startup or a large enterprise, we can still embrace Lean tenets. If we are building a product, we may use something like Launch Darkly to A/B test our newest features with our customers and closely monitor the impact of those features via the data we are gathering (Note: we aren’t discussing collecting data here, but to be clear - you must. If you don’t measure it, you’ll never know if you’ve improved it). If we are building a product for users within an enterprise, we can shortcut the process - practice _Genchi Genbutsu_ and go and talk with the people who are using the new features!

Feedback

Along with feedback on what we develop, we need to ensure we cultivate a strong feedback culture within our team. Feedback is what helps us grow. It allows us to understand what we are doing well, and what we can improve. It should always be timely - the best time to give and receive feedback is immediately after the subject of the feedback has occurred. It should always be supplied in a way that Feeds Forward, and does not just focus on the negative.

The best way to do this is to embed an understanding in the team that feedback isn’t just encouraged - it is expected. This should come from leadership, and be fostered within the team.

Embrace Reality

Whilst we progress with our delivery, a litany of eponymous laws will likely strike. Murphy’s Law, Hofstadter’s Law, Zawinski’s Law and many more - all of these are reflections of the Volatile, Uncertain, Complex, Ambiguous problem spaces we work in whilst delivering software. Outside of the more common laws of software, many many more unique circumstances will arise in your particular initiative that will challenge your team, and move them away from any theoretical optimum path.

The most important thing we can do when confronted by situations that are less than favourable is to lean into the pain. It is imperative we both clearly understand what has led to our current reality, and can articulate that both within our team, and to our stakeholders and sponsors. If we can do this, we can then make sensible decisions steeped in reality. If we don’t do this, we delay inevitable and more severe decision making and consequences.

We must strongly resist and dispel reality distortion fields - I’ve worked with people in my time, whether they be developers, project managers, or stakeholders and sponsors, who will attempt to create alternate realities based on either out-of-date information, or on pure subjective opinion. These realities tend to be created to serve people’s individual motivations - saving face on the delivery side, on budget and timeline adherence, or in sponsoring the initiative. One classic conversation that many people will be familiar with centres around why the team isn’t meeting up-front estimates, or aren’t tracking a Gantt chart correctly.

There is a simple antidote to these sort of politics: visibility, transparency, and lots of open, two-way communication.

Our job is to equip ourselves and our organizations with information, data, and knowledge to help make the best decisions possible within the stark light of our current reality.

Overcommunicate

Embracing reality is critical, however we can’t do that unless everyone understands what the current reality is. Here is an question - in your business, can the key stakeholders and sponsors of the initiative you are delivering answer questions about:

The current budget burndown
Key decisions that have been made thus far on the initiative
Whether scope has changed significantly since inception
Current outstanding risks
What has been delivered to date
What will be delivered over the next 2-4 weeks
The overall health of the initiative

If they can’t talk to most of the above, you haven’t communicated enough. Being frequent, disciplined, consistent, and thorough in your communications leads to creating an environment where everyone understands what the current reality is - and they can then make decisions and take actions that support that reality within their own responsibilities for the initiative. This may be product managers setting expectations with customers about new product features, or it may be the head of a division reasoning around whether she should seek more budget, or cut scope, to accommodate recent discoveries.

It is almost impossible to communicate too much. Communication creates a symbiotic relationship between the delivery team and their stakeholders - stakeholders that are well informed are more likely to engage with the team more often in an informed, open, and honest way - which will ultimately lead to the team being able to deliver better outcomes for them.

All Activity In Plain Sight

Communication pushes information from the delivery team to stakeholders and the wider organization we are delivering within. This is important, as it allows the delivery team to provide context to the numbers present within the communications, reducing the chances of misinterpretation.

However it does not promote stakeholder self-efficacy. If all information comes from delivery team communications, there will be times where stakeholders will want to get a hold of the most current measurement for a particular thing, and for this they will have to ask the delivery team, or dig through their email trail for stale information.

Instead of enforcing this potential bottleneck, we want to empower stakeholders to ‘sample’ various delivery metrics at any point, and have them recieve the most up-to-date information possible when doing so.

We want to make this information visible to all - all activity in plain sight. This will sometimes take the form of digital information radiators with dashboards, burndowns, and sprint boards being presented. It may take the shape of physical card-walls and a curated display of 2-3 key metrics which get updated every morning. Whichever medium is taken, the important part is that it is somewhere where many people can see it - not just in the corner of the dev team’s space.

The displays should both give people an idea into what the dev team are doing, how the delivery is progressing, and invite stakeholders to engage with the delivery and contribute to work in flight.

One Eye On The Horizon, Code For Now

When building software - particularly when building products in a Lean way - one of the key challenges we will be presented with is deciding when to solve particular problems.

For example, if I am building a SaaS product, I may have a few problems that I know I need to solve outside of core functionality, such as:

What is my multi-tenancy architecture going to look like?
How will I onboard new tenants?
How will I scale my solution to many tenants?
How will I optimise my hosting costs across my tenancies?

These are all important problems to solve, particularly if our product takes off! But which do we need to solve right now, and which can be safely delayed, allowing us to more effectively prioritize the expenditure of our limited time and budget?

Most people will answer with the classic It Depends TM for this question. But we can effectively generalize this to something that has merit - Solve today’s problems. From our example above - we won’t get very far if we don’t have our tenancy architecture decided upon, as we will only be able to accommodate a single customer! However we can likely put off thinking about advanced concerns like optimizing our product’s hosting costs for another day (sorry, you’ll have to wait a little while longer before you deep-dive into Kubernetes), allowing us to focus on delivering the must-have features for our MVP.

This does not mean we should turn a blind eye to future concerns. It is unwise to not be aware of, and to not think about and plan for the future. We also need to make sure decisions we make now do not paint us into a corner for future concerns. However the future is uncertain and vague, and today is concrete and clear - so we should solve today’s problems, and plan for the future’s problems.

Pragmatism In All Things

Hand in hand with not solving All The Problems right now comes making sure we constantly evaluate how much effort we expend when solving the problems we do need to solve. I mentioned earlier:

Software development initiatives are accumulations of thousands of small decisions

If we ensure that each decision is made in a way that appreciates we are expending our finite resources, likely in the form of someone else’s money, to achieve an outcome, we should be able to maximise the value we can deliver within our budget.

Examples of decisions that should be made with pragmatism include:

Should we host in Kubernetes, or will Elastic Beanstalk suffice?
Do we need a faceted filter along with a Google-like search experience, or will a simpler solution deliver the same value within the product?
Should I spend two weeks building a custom calendar component, or should I buy an off-the-shelf product?
Do I need to go the infrastructure-as-code route for the hosting environment of this application?

We have now covered some of the elements that go into creating a high-performance software delivery environment, and the behaviours that will help us excel within it. The last thing we need to cover is - what should we be wary of? What might pose a danger to our delivery, that we should be vigilant in detecting and responding to?

Many of the dangers present are simply the inverse of the above Conditions and Behaviours. However there is one that is worth articulating below.

Dangers

The Agile Divide

One of the biggest dangers facing software teams is when they attempt to use an Agile methodology, where the wider business is still operating in a way that puts process and output above all else. We talked about this previously in One Team, One Dream, however outside of gross misalignment, there are other ways this can manifest in organizations.

One of the more insidious ways this creeps in is via scaling and governance mechanisms. Large organizations with existing established silos and poor cross-function collaboration tend to favour tools like SAFe, which allow them to assign decision-making roles in software initiatives far away from the actual development teams. Just look at the infographic on that page, and take stock of what portion of it the development team occupies.

Other organizations will employ Agile coaches, plaster their walls with propaganda, and adopt an entire way of working that purports to be Agile, whilst completely missing the fundamental tenets of it.

In either case, these organizations will say they are Agile. I once had an IT manager proudly proclaim to me “I get Agile. I’ve done the Scrum course. I know this stuff!”, all the while forcing his teams into weekly “status update” meetings where they were forced to provide hours worked / hours left on tasks to PMs who would then communicate it back to The Business.

This is the biggest danger you can face in software delivery, and it is far more challenging than organizations that refuse Agile - at least they can attempt to optimize within their own self-imposed constraints.

These organizations are the primary creator of previously described reality distortion fields. They have iterations, but they do not Build, Measure, and Learn. They cast blame, encourage empire-building, and usually have enough money and cannon fodder to somehow create “successes” out of horrendous deliveries.

When working within these sort of environments, we need to double down on our Behaviours, and attempt to affect meaningful change.

Repose

Successful software outcomes are created not just in delivery.

Successful outcomes start being crafted at the very first discussion, in discovering what we can do, from funnelling the unlimited opportunities that may be present down to something that can be clearly connected with a business goal.

We can then further enhance our chances of success by applying a right-sized effort in deciding whether to proceed or not, based on an evaluation of risk vs reward.

Delivery is the final step in enacting our success, a combination of an environment that champions transparency, ownership, and value delivered; of teams that employ discipline, capability, and pragmatism; of high levels of communication and engagement between all parties of the delivery; and of ensuring we optimise toward learning, both within ourselves, and our products.

Andrew Best

Discover, Decide, Deliver: Part Three, Deliver