When developing new projects or services in an Agile way of working, it’s critical to gain insights from our customers to ensure we are improving the product and/or service. But how do we do this when we don’t have the opportunity to directly ask the customer for feedback? This is a challenge particularly relevant for organisations with a vast customer base in the hundreds of thousands, or with multiple business units, with hundreds of projects on the go at once.
In this post I will explore an approach to “Fast Customer Feedback” at scale, using data to drive project decisions and validate customer satisfaction.
“Interviewing customers at scale can be quite costly and time consuming for an organisation. The harder it is, the less likely it is to occur.”
It takes time to design. User Experience (UX) Designers will agree with this statement. Typically a UX Designer will follow a version of the Human Centred Design (HCD) approach when designing. A typical waterfall HCD approach focuses on understanding what you are about to design, spending time researching and documenting the context of use, gathering requirements, wireframing and conducting various user testing sessions to validate the designs. This process can take weeks if not months. In the end you are typically left with a big Functional Specification document that no one likes to read, not even the UX Designer who has written it.
Once the design is done, Developers will read the Functional Specification to understand what to build. This brings about its own challenges. On occasion, the time it has taken to get to the Build Phase can mean the designs are no longer cutting edge or aligned with customer expectations. Also, although it pains me to admit this, sometimes requirements are missed and the UX designer has since moved on to the next project, not being available for follow up questions or rework. This can and more often than not will lead to incomplete solutions. Unforeseen requirements. Change.
A common myth of being a UX Designer in an Agile world is that there isn’t enough time to understand requirements or deliver quality designs.
Taking a pragmatic approach to the constraints that exist in today’s large organisations, yet still realising the benefits from Agile.
What is the first thing that comes to mind when you hear ‘Hybrid Agile’? I asked this question to a group of 40 active Agile practitioners at the LAST conference in Melbourne a few weeks ago and the response I received was varied.
A recent report published by Forrester has concluded that ‘Water-Agile-fall’, synonymous to Hybrid Agile, is a practical and necessary reality for large organisations. After surveying 215 software professionals and collecting data about the adoption rates of Agile and its success, the report’s findings were:
In order to select the ‘fit-for-purpose’ point along the Spectrum of Agility that will best suit your organisation, it is imperative to be honest about the key constraints for Agile within your organisation.
The challenges with waterfall delivery are clear. Organisations can no longer absorb the risk of a solution which is either outdated or no longer required by the time they finish delivering their project. Using a waterfall approach can also:
- Be inflexible due to heavy governance layers
- Have complex yearly capital allocation processes
- Result in unforeseen delays caused by solution dependencies
This means organisations cannot keep up with the continuously evolving requirements, customer needs and technology landscape when using a waterfall approach. This has resulted in wasted time, cost, effort and unrealised revenue.
Agile delivery promises and has demonstrated the ability to overcome many of the problems brought about by a waterfall delivery approach. The question raised by many organisations experimenting with Agile is “why are we not seeing the benefits promised even though we are 1-2 years into our Agile journey?”
The Design Slicing framework is customised to each organisation’s unique constraints and is iterated using a Lean optimisation approach, paired with Agile test and learn implementation.
It’s no secret that change management has been ‘tipped on its head’ when it comes to agile project delivery. For large organisations encumbered by siloed structures, bureaucratic processes and complex legacy systems, they are increasingly finding it hard to respond quickly to changing business requirements using traditional ‘waterfall’ delivery approaches. So, how do we change the way we change to be faster, better, cheaper? How does one make change lean, lean, lean? But ultimately, how do we get our people living and breathing agile? Recently published, Deloitte’s Agile Change Lessons from the front line point of view describes five key principles for driving change in agile environments. But, what underpins this?
Building elements of gamification, playfulness and fun into team challenges and goals can also help drive creativity, innovation and agility.
Agile and Design Thinking are complementary. Design Thinking is a human-centred approach to defining and solving problems, which encourages innovation and creativity in the problem solving process. Design Thinking is particularly well-suited to situations where the problem itself is not clear, advocating a strong focus on problem definition, problem shaping, and requirements clarification. Likewise, Agile methods embrace uncertainty and are appropriate for projects where the requirements are subject to change.
While Design Thinking is a solution-centric approach, it also places great emphasis on having a clear articulation of the problem. For Agile projects, the backlog is where the functional requirements of the system under development are captured, and the quality of those requirements is a significant factor determining the success of the project.
“Design Thinkers prioritise empathy as a key factor in understanding and identifying customer needs.”
Like all projects, the ability to manage change within an organisation is integral to its success. In an Agile project environment, the fast and iterative changes to an organisation’s processes can leave many users with change fatigue, which can significantly impact the success of an Agile implementation.
Agile Change Management has developed from being an afterthought in an Agile project delivery to being an integral need for its success. In any Agile project, it is now important to consider how to incorporate Change Management principles into the fast changing Agile environment. Agile Change Management has developed to allow change practitioners to work in a more lean, collaborative and flexible way in order to ensure people are able to keep up with the impacts of change.
Historically, large institutions have approached the implementation of information management (IM) strategies by initiating large programs of work that typically struggle to justify extensive investment horizons. For the institutional division of a large financial services firm, Deloitte identified patterns in the IM challenges and data needs of the business that could be addressed iteratively, rather than setting out to resolve everything at once. Whilst not core to the client ask, Agile ways of working were adopted to provide increased business agility, speed of delivery, the ability to attribute benefits to specific investments, and to enable scalability despite an uncertain resourcing profile.
‘Embedding a flexible and collaborative culture helped teams to acknowledge information as an enterprise asset that impacts stakeholders from all business and technology functions.’
Today, more than ever there are greater expectations from project customers to achieve more with less, in shorter time, and longer lasting business value. In times past the business world appeared to be more predictable and stable. This allowed teams to plan more confidently for the future. Currently projects and indeed whole businesses are exposed to shorter customer and technology cycle times. The marketplace is moving very fast and has no signs of slowing down. Indeed, the latest Deloitte Tech Trends 2015 report highlights eight key trends, two of which highlight the possible benefits of what “thinking Agile” could bring to businesses against a dynamic business and technology landscape.
“Disruptive technologies, processes, and people are all to be connected, collaborated with, and harnessed to deliver customer value.”
When we consider Continuous Delivery adoption at organisations, we often hear success stories coming from the likes of Google, Amazon, Spotify, Etsy. These organisations have something in common; they are digital disrupters and are changing the way traditional organisations across all industries need to provide goods and services to their customers to remain competitive. The answer seems obvious, “we need to deliver like the digital disrupters, we must adopt Continuous Delivery”. Continuous Delivery is the practice of building software and leveraging technical capabilities in a way that allows you to deploy to production at any time. These more traditional organisations find the Continuous Delivery journey challenging and wonder to themselves, “if they can do it, what am I doing wrong?”
“Business hear the words ‘deliver to our customers every two weeks’ and immediately think of the chaos that will bring”