Collaborating on the common purpose is just the start. Our teams move transparently and openly throughout the product journey.
Purpose-Driven Agile Engineering or: How I Learned to Stop Worrying and Love the Progress
At Architech we rally our teams around the client’s business problem. By placing business value at the heart of an agile delivery team, we empower everyone to face the unknown. With the entire team as stakeholders, we then deliver better progress than could ever have been promised.
Facing Ambiguity
Agile engineering is a process designed to acknowledge ambiguity – the fact that the future is unknown. While this is a critical point of strength for the process, it can come into conflict with client expectations during delivery.
As client partners, Architech regularly guides stakeholders who are new to agile to the finish line.
The benefits are many, including releasing early and often, having the flexibility to impact product direction throughout and delivering a better product than we could have been imagined from the outset.
The Promise
As a digital product studio with over a decade of experience, we have delivered a lot of solutions. One clearly established maxim is that the solution cannot be fixed from the outset. Too many details along the delivery journey have yet to be addressed. Ideally, we can avoid tying ours and our customers’ hands.
One common expectation held by stakeholders, new to agile, does constrain the solution: the promise of a fixed price for a fixed scope (and timeframe). Software engineering expert, Martin Fowler, identifies fixing these factors together as a “mirage”.
It is an untenable strategy that results in workarounds to maintain the illusion of the initial promise.
How could a vendor make a legitimate promise under these circumstances? It’s not that vendors don’t try. It has been attempted through accurate execution planning, identifying detailed project scope, and accounting for all associated time and costs.
But, it’s a tough strategy that suffers from the ‘the missing shade of blue’ effect: there’s always another hidden detail to identify, scope, and estimate. It also suffers from inaccuracy, since certainty increases with time. Important external factors like technology and customers are always changing.
The more we bank on today’s information, the less accurate this type of plan proves to be.
Another approach is planning with large contingency estimates. With this strategy, the parties can promise to aim for an expected outcome to be delivered after some fixed time period. The challenge exists in managing the expectation gap between customer and vendor.
How will the team establish the missing scope together? Time will always run out towards the un-established expectation. This is a recipe for CRs at the end of the timeframe to bridge the gap.
If the delivery can’t match the expectation, it doesn’t sound like much of a promise.
The Progress
Agile engineering is a clear match with Architech principles. Acknowledging change as a natural part of delivery allows us to start engagements with an honest foot forward. Our promise is to plan at the appropriate level of detail, at the appropriate phase, using agile delivery.
This redirects project investment into delivering working software faster, with more frequent releases, and with more flexibility around requirements. It elevates the value of product progress over product promises.
This is a good tack to follow. It has created value for our customers, a decade running. Customers see results in weeks and months instead of years, develop relationships with us as partners instead of vendors, are free to make better product decisions than what could have been initially planned, and avoid wasting time on politics.
Embracing Change
Adopting the benefits of agile engineering doesn’t happen automatically for all clients. It can cause confusion unless everyone is prepared to embrace change and roll with the speed of progress. Especially required is a departure from traditional customer expectations by doubling down on the unknown. We guide partners with success stories from previous clients, high visibility of progress during delivery, and frequent, transparent collaboration. Ultimately, delivering working software that progresses according to business needs is what has brought us success.
To deal effectively with change during project delivery, team members need to make decisions quickly and effectively, grounded by some kind of consistency.
Ambiguity will occur at many levels.
Scope for a specific requirement will be too large, too small, or be deprioritized in favor of more critical business value. The technological solution for a piece of business value will be clear through one lens and murky through another.
Product owners will be put to the test when faced with new options about what is possible, and development team members will need clarity about what is required today versus tomorrow.
Everyone will need a strong, guiding vision.
Purpose-driven Agile
The product team must establish a rallying point for the engagement and the many decisions that must follow.
This is done by modelling what business value is to be achieved. Simply put, why is the project being undertaken by the business? We answer this question collaboratively with the client, state it in our contract, and take it to heart.
This starting point is the foundation of a common product language that empowers all stakeholders.
Our strategy, design, and engineering teams wax astutely on product direction with the client. Leveraging this common understanding, the talents of many people are brought to bear on the problem. This transforms the common understanding into a holistic guiding principle that unifies client and delivery team.
Necessity is the mother of invention, and it is no accident that the unifying spirit of the engagement is rooted in client business value. This allows the development team to feel the client’s ‘pain’, having brought it to everyone’s level. Innovation and cross-disciplinary contributions occur in alignment with the goal.
Epics, story-writing and release planning, fine-grained story scope and story to technical task breakdown, as well as tactical change management and pivoting decisions are made in alignment. The original purpose permeates throughout.
Psychological benefits aside, delivery progress is clearly bound to the purpose. Epics and all that follow have been derived such that the common project seed grows into trunk, branch, and leaf levels of business value. The initial common language grows from a few statements to potentially hundreds of stories and thousands of technical tasks, all in manageable amounts of detail at just the right time.
Even technical tasks are justified and validated by their relationship to the goal. The value delivered by the team is traceable to the original problem definition. Since tasks derive from a story that had been derived from an epic that represented a major goal, the purpose inherent in these tasks is clear.
All of the work being undertaken is easier for the whole team to understand. Furthermore, a very practical economy is achieved; the minimal number of tasks required to achieve the project goals is essentially guaranteed.
The Agile Engineering Journey
Collaborating on the common purpose is just the start. Our teams move transparently and openly throughout the product journey. We offer insights but establish direction as a team -- of which our client is a part. We complement our client’s business domain expertise with the market, user, and technical research; consider unexpected directions together, and execute quickly.
After goal setting, we establish a strategic release plan.
This commonly includes proof-of-concept, launch, feature set, and stability releases. This is the map by which we can clearly plot our current location, although it is open to future change in the case that additional destinations should be visited in pursuit of the goal.
Delivery at Architech is multi-faceted and efficient. Strategy and design teams drive delivery with LEAN and design-thinking analysis methods. Modelling the customer’s existing processes and comparing with the desired future state, we eliminate waste before proposing a technical solution.
This results in a streamlined feed of requirements. Our product team and client prioritize these by business value, our technical teams deliver the activities that add the most value as of today, and we all judge the next steps for the product together.
We push releases of working software throughout the delivery effort. Tactical execution plans published in the language of business value keep teams focused on both the big picture and the current finish line.
We release sprint packages every week or two, establishing feedback points to guide next steps. Then we evaluate release goals in context with the current state of the product, steer as required and move on.
When release goals are satisfied, we push to production. The value of progress reigns over the value of promises.
Avoiding the mirage doesn’t mean we can’t make promises. We just focus on those important to successful digital product delivery. We can minimize delivery time by building only what is required when required. We’ll offer honest, justified opinions for open discussion.
We’ll transparently communicate cost and tradeoffs, and provide recommendations. Most of all, your business will always get the product you need. You will love the progress.
