How We Build Enterprise-Size Software: Part 2 — Approaching Constraints
Using agile and lean to optimise outcomes.
In Part 1 of this multi-part series, I discussed how we deliver enterprise-size software in small increments. In Part 2, we explore business environment constraints, and how an agile approach creates better outcomes.
At Propellerhead, we urge our clients to use less money, fewer people and shorter time frames in pursuit of less complex goals. To enable this, our large-scale engagements typically follow a lifecycle that has its roots in Agile, Lean, Lean Startup and Design Thinking.
We understand that in enterprises there are often multiple stakeholders and a number of challenges and opportunities that are presented.
The organisation must have ways to decide which initiatives are pursued and how much investment should be made on them. Once a decision is made, there are a number of controls within the organisation that are used to constrain projects within its business case parameters to ensure the expected return.
Agile development is perfectly suited to deliver maximum value within these constraints.
Constraints
#1: Goals and Cost
When an enterprise identifies the need for new or changed technology, there will be certain goals that are hoped to be achieved by the initiative.
These goals will always have a value to the organisation.
When a cost is presented by a vendor or project team, the organisation can determine whether the value equation (the return on investment) is right:
Are we prepared to pay the cost in order to realise the value?
In most larger organisations there will be cost controls in place: once a budget is set, it is usually difficult for an organisation to spend more if they find out the cost analysis doesn’t match the real implementation. Usually some level of governance is in place to ensure the project is managed to within the budget.
Therefore, the challenge is to achieve the desired goals within the approved budget.
At the core of agile software development is the shared understanding of the outcomes we’re delivering to. There is also the shared understanding that implementation detail can vary, providing we still meet the goals.
At estimation stage, aligning the goals and budget is achieved through mapping out the high-level approach and assumptions. If the initiative has a high degree of research-and-development or novel innovation, then we might include some experimentation activity before setting a budget.
#2: Time Deadlines
It is common for a development initiative to have a timeframe that is understood broadly within an organisation.
Most organisations have financial reporting responsibilities that mean budgets often have an expiry. This may be somewhat arbitrary but does present a real constraint.
Other times there may be timeframes set by business objectives: product launch date to meet a business opportunity or expiry of system support, etc.
This presents another target to the project team: not only do we need to meet goals within the approved budget, but we must also meet a time deadline.
In agile software development, a target timeframe and budget are combined to specify a required “velocity” — the pace at which development needs to proceed. This will dictate the number of agile teams that need to be employed on the initiative and will lead to planning the division of work between the teams and the dependencies that will need to be managed.
#3: Scope
In waterfall development projects, requirements are determined up front, before development begins.
Much has been written on the fallacy of knowing all of the requirements in sufficient detail. Anyone who has been involved with software development will understand that a considerable amount of requirement detail is discovered by the development process itself.
General scope, however, must certainly be agreed in enough detail in advance for time and cost budgets to be set. Agile does not neglect this.
When the goals or outcomes of a project are assessed, there is always a scope assumption. All stakeholders need to agree on the scope in order for there to be a realistic understanding of the return on investment.
In agile software development, the scope is defined as a backlog of user stories. Rather than populate the entire backlog at the beginning and then try to work through it (waterfall), we start with a high level map of the entire project and then elaborate the user stories just-in-time of them being needed for development.
“Just-in-time” will not be uniform; some sections of the project will require more analysis, stakeholder management or prototyping than others. At all times, we concentrate on the top of the priority list.
The backlog is regularly reviewed to ensure that we are only working on what is most important.
Balance
Since we have already agreed to deliver the goals within budget and on time (the constraints), the only variable we have left is scope.
We have worked with organisations who have failed to embrace the benefits of agile because they fear their requirements (the scope) won’t be met. Or, the scope will be delivered beautifully but the budget or timeline will be blown.
This does not need to be the case at all, and when enterprise and vendor work in partnership, a balance can be met that optimises delivery.
The first step in effective scope management is for all stakeholders, especially senior sponsors, to focus on the big goals of the initiative. This addresses the business case and is expressed as a set of desired outcomes.
All agree that this is WHAT needs to be achieved and WHY, but also agree that there is flexibility in some of the detail on HOW they are achieved.
By holding agile values of delivering working software in short, continuous cycles, stakeholders can clearly see the features emerging. By using a Roadmap and “layering-up” features, we keep a close eye on the scope of the initiative as a whole.
Roadmap
For us, managing an enterprise-scale agile project happens on two layers:
- Roadmap management holds the high level outcomes
- Sprint management deals with the exact details of deliverables
These two layers receive continuous attention and review.
At Propellerhead, we have found that two-weekly cycles of planning and review on both of these layers provides attention without causing too much interruption to delivery velocity.
At the Roadmap level, a plan like the one illustrated below is maintained. The plan breaks the project down into a series of business goals that are to be achieved at each stage.
Goals can often be cumulative — that is, a set of intermediate goals are aimed for in the effort to meet some ultimate goals. High-level features that will be developed to meet the goals of each stage are mapped out and metrics that will show whether or not the goals have been achieved are stated.
The roadmap is used to construct a high-level sprint plan. The sprint plan describes goals of each sprint, how the goals will be met (such as prototype, design spike, shippable software, A/B test, etc.), and the metrics the team will use to measure whether the goals of the sprint are achieved.
Everyone on the project agrees that the detail within sprints is to be elaborated just-in-time, but by maintaining a calendar of sprint goals, we achieve the purpose of ensuring the scope will be met within the time and cost budget.
The roadmap and the sprint plan are maintained in-step with delivery agile sprints - the roadmap informs what needs to be elaborated and worked on in the imminent sprints, while the outcomes from sprint activity informs any change in emphasis or priority in the roadmap.
By continuously aligning the delivery activity to the roadmap and sprint plan, the scope, timeframe and budget are nurtured:
Layering Up
One of the most important techniques for keeping an enterprise-sized software initiative on track (time, scope, budget) is to deliberately build the very minimum set of functions for each feature on the first pass that meet only the most important outcomes.
This will build out the breadth of the scope earlier. Then iterate: add more richness to each feature in small increments — always adding only the next most important function.
It is perhaps not surprising that in many projects delivered in this way, we have seen a change in emphasis as the software emerges. Some features end up minimally meeting outcomes without further effort, while other features need more detail to achieve their goals.
By not making this guess up-front, we save time and money by only building what we know is important.
In Summary
By bringing the agile software practices of delivering working software at every iteration, ensuring we are only building the next most important thing at any point in time, and focussing on outcome, we increase the chance of project success.
To avoid missing the big-picture constraints of budget, time and scope, we maintain a high-level view of the goals of the project in-step with the agile delivery.
In greater detail, benefits include:
Visible Roadmap and Sprint Plan
Reporting to senior stakeholders is done from the project management cycle.
It can be very useful to have the roadmap in a highly visible location such as a set of Post-it notes on a wallboard. The Roadmap is stated in business language so everyone understands it.
Remaining Goal Focused
It is important to remain goal-focussed to avoid getting bogged down in implementation detail.
An important discipline is to “layer-up” features over time by building the minimum function to achieve an outcome and then extend it later in the project if it is still important.
Project to Product
We move clients from having a project mindset to a product mindset.
Instead of working towards a “finished” state, we work towards a stable state that allows continuous development and improvement. This allows less important backlog items to be deferred without anxiety they will never be addressed.
Having a continuous product mindset ensures the system will stay current and continue to provide maximum value over time.
At Propellerhead, our software powers some of the largest ideas in government, commercial and non-profit institutions in New Zealand. Our clients include Auckland Museum, Orion Health, Skinny, Spark Wholesale, NZ Post, Ministry of Education and Auckland Transport.
If you’re interested in what we do, you can reach out to us here.
