How Agile principles can help you deliver value to clients
26.07.2021 | 5 min read
Originally published in March 2020
I think most of us would agree that it’s important to feel that your work delivers real value and is useful. But how do you ensure that this happens? There are several solutions of course, but the one that we favour at 10Clouds is applying Agile principles to our projects and cooperation with the clients. In the below blog post, I will tell you more about what this looks like in practice.
Update July 2021 - Since the blog post was written, we have iterated our approach even further - we have focused a lot on services related to the early stages of Product Discovery and Market Fit Validation. We also decided that a Product Delivery Manager would be a better way of supporting Product Owners in a comprehensive way.
Aligning our work to the needs of our clients from the outset
Agile principles help us to align our daily work to the business goals of our customers. We strive to support them every step of the way, starting even before the software development project. We do care about being efficient in our work and delivering products quickly; this is why we use Agile approaches to software development. But after all, what’s the point of very efficiently delivering something that does not serve its purpose?
Imagine you’ve just founded a start-up to deliver a new app. You have a pretty good idea what business needs it should answer and what features it should have, but you don’t know yet how much it will cost you to build it and you may not have a detailed product roadmap for it. Here’s where you can count on our support: our experts will identify the unknowns and collaborate with you to discover and scope the project. It may be via workshops, it may just be a few calls, or sometimes even just Slack communication proves sufficient.
At the end of that process, everyone has more clarity around the product. At this stage, we often collaborate with the customer to deliver the first version of Product Backlog, prioritised according to MoSCoW method (Must, Should, Could, Won’t) and divided into releases, based on what is known about the business value of the project. This serves as a great starting point for the development work.
Understanding our client’s context
Software development is at its most effective when the developers understand the client’s business context and constraints of the solution. Hence the need to start the project properly with a short inception that covers those aspects and provides alignment between the team and the customer. Proper kick-off gives understanding of the bigger picture, the team is able to refine the work and plan the first iterations (in our case, typically two-week Sprints).
Appointing a Product Owner
Of course, this is just the beginning of not just project management, but actually also of the product management. For the project to succeed, strong product ownership is of paramount importance. While a 10Clouds Scrum Master supports the customer’s Product Owner to ensure that the Product Backlog is managed well, it’s the customer’s responsibility to gather input and requirements from end users and other stakeholders to guide the delivery of something that will really be valuable. This needs to be a continuous process.
The Product Owner needs to devote a considerable amount of time to the project. It’s not just a matter of managing the backlog, participating in refinement, planning and review sessions every two weeks. It’s also the availability for the team for their daily work, when questions arise. (That’s one of the reasons we always give the customers access to our Jira, Slack and create dedicated project channels, so that there is transparent knowledge exchange.) We often see time constraints on the side of our customers, they can even be related simply to the time zone difference. In such cases, we involve a Proxy Product Owner. This person is in frequent contact with the customer’s Product Owner and based on that, supports the team with their questions as well as takes care of technical tasks like filling in Jira tickets. It’s a practical solution to a real-life challenge.
Transparency around the progress of work
Another way we support the Product Owner in product management during the project is by providing transparency around the progress of work. There are several tools and channels for that: first and foremost, participation of the Product Owner in Reviews and Plannings. The Product Owner also always gets access to our Jira boards where the progress of work and remaining backlog are visible. And additionally, they can expect the Project Manager from 10Clouds to provide information around team velocity and predictions around the delivery dates for the assumed work scope. Such metrics help in prioritising and potentially reordering the backlog as needed.
To sum up – how to minimise the risk of getting it wrong
Building software is inherently connected with risks; usually there are technological unknowns and surprises to contend with. However from a business perspective, the main risk is that the delivered product is not valuable. Even if the project ended on time and within budget, if we built the wrong product, then the customer actually wasted all that time and money (which is frustrating also for the whole project team!)
That’s why in our experience we aim at mitigating the main factors and patterns that could result in delivering the wrong, less valuable product. Agile principles of close collaboration, incremental delivery, focusing on business value serve as our guides.
Main risks or bad patterns and how we mitigate them
Unclear product vision
– Before the project – collaborating to arrive at a more granular product roadmap and features
– Inception and kick-off to align the team with the vision
Everything is a “must”
– Supporting MoSCoW prioritisation of the backlog
Everything needs to look perfect
– Coaching in the “Done is better than perfect” mindset and in setting sensible acceptance criteria
Not enough Product Owner time
– Proxy Product Owner
Basing the work on written documentation
– Fostering direct communication via Slack
– Ensuring that there are meetings to align the customer and the team
Not reacting to actual work progress
– Ensuring visibility of progress and velocity
– Escalating the need to reprioritise backlog