Is the Customer at the Center of Your Current Development Project?
Be sure to keep the customer and the measurable value that your project delivers at the forefront of your development planning.
Join the DZone community and get the full member experience.Join For Free
If you're in the middle of a Digital Transformation initiative and planning your next release – stop! I want you to take a moment and ask yourself: “What is my focus?” Is it making sure technical staff are busy or delivering real measurable customer value?
Optimize for Customer Value
An organization’s main driver is to deliver value to the customer, so ask yourself again: “Is my transformation program truly focused on achieving customer value? And more importantly, is my next release?”
I’m sure you’ve heard this before: your Agile delivery is supposed to be quick. Your sprint planning consists of ensuring everyone is busy for the next couple of weeks and the prioritization of your backlog is predominantly driven – or heavily weighted by – the above factors. Taking a step back and questioning, “What is driving delivery?” can have a significant impact on how you approach each sprint plan and the overall success of a programme.
I think it’s fair to say that today’s organizations understand the importance of ensuring that all processes are efficient and that they focus on delivering value to customers in the most cost-effective way. However, in many industries, this has driven organizations to Agile delivery on the promise of faster, higher quality deliveries all at the same cost of less – a promise that doesn’t always stand up to test.
On the whole, this inadvertent drive to ensure people are busy and the resultant outcome of features not getting delivered quicker or better comes from distraction; when the teams don’t fully understand the what and why of the delivery.
Move from “Busy” to “Benefit”
Traditional Agile – yes, I think we can use that term now – designs teams around components of the architecture, commonly known as component teams. This approach makes it very difficult for people and groups to understand the impact each of the components has on the end user. It is also hard to plan due to cross-cutting functionality and hard to deploy or run due to dependencies. The real problem with this approach is that scaling breaks it, and with the overlay of Brook's Law (more people doesn’t work) it is incredibly difficult to deliver full features fast.
After stopping to look from the outside of a project, the realization is that generally there’s a misalignment between the management team (the outcome), the design of the solution, and its components, including which elements of the delivery bring benefits to the customer. These issues become heightened in most projects as the complexity of the task they are trying to achieve increases. The business value is cross-cutting the organization and impacts multiple components.
Remember, Agile is about innovation and should be used for solving complex problems. It should be used when the potential solution is unknown at the start, the scope isn’t clearly defined and where cross-functional collaboration is vital. The need for cooperation only enforces the requirement for teams to understand better the outcome they are trying to achieve and the end goal or problem they are targeting.
Moving an Agile delivery to a model that focuses on ensuring that you are building customer value every time requires a new approach to software design, re-organizing of delivery teams and ensuring that the business understands the value it is trying to deliver.
3 Points to Consider
Move Away from Component Teams to Feature Teams
A feature team is in essence, a cross-functional, cross-component team that develops numerous end-to-end customer features—one by one. Not as easy as it sounds, this is a massive change to the organization but done correctly will give everyone clear understanding of why features are getting built, what value they bring and to who, and ensure that each feature within the delivery has clear ownership from end-to-end.
Focus on Value Still to Be Delivered Rather than Time Spent to Date
Reporting is traditionally a retrospective action that lets management know what the team didn’t achieve and how much it cost. Historical information is helpful to know but doesn’t allow you to measure the progress the business has made in achieving the outcome. Moving the focus on to remaining value (once defined) means that some projects can finish early should value or outcome be achieved.
Ensure Everyone Understands the Overall Model You Are Trying to Deliver
Giving the delivery team a clear, concise view of the business areas and value the project is aiming to achieve is a great way to help people understand and prioritize functionality requiring delivery. This approach can help product owners remove gut instinct, help with prioritization and ensure that everyone understands the impact on the customer or channel.
Published at DZone with permission of Gregor Cunningham. See the original article here.
Opinions expressed by DZone contributors are their own.