Customer-driven Agile Software Development
Or how I turned around the entire software development process in an organisation from ‘agile’ to agile. In a way that we could better serve our customers, show earlier results and build better engagement
Why?
Pretty early in the creation of my current team, it was obvious we have a group of people with a pretty wide selection of skillsets that could all contribute to a variety of projects on our roadmap. It was very hard to get external and internal stakeholders to agree on urgency vs. priority and timelines. Then there was the additional complexity of external deadlines and revenue. If a customer is paying, or even has paid, for something to be developed and there is a timeline, does this mean it automatically takes priority over other things that SHOULD be taking precedent? Furthermore, is the decision with the technical team, or with someone else?
Some of these projects were big/long-term projects that would mean these scarce resources would be locked into this project for up to a year. Impact for the timeline for other projects would be significant, and as a result these bigger projects were typically assigned a lower priority by the stakeholders of the operational teams. As an inevitable result, we would also see quick-win and short-term projects being picked up over more fundamental redesign projects or more ambitious new market projects.
Another observation we made, is that the requirements and specifications of projects would sometimes change as development went on. The typical project initiation document and the requirements it contained were always wanting in details. Sometimes, as we were iterating, it felt like the requester themselves weren’t really aware of what they wanted until we started ‘improving’ our initial deliverable.
The tangible product that was developed so far would often inspire or alert the requesters or stakeholders of what exactly we were doing and introduce certain must-haves for adoption in our operational organization, or even objections to the project entirely as it would conflict with other internal projects or processes. It would also lead to additional feature requests that ‘had’ to be part of the project. Requests which, in hindsight, should’ve been part of another project picked up in a different sprint. A typical example of unnecessary scope inflation, despite the best intentions of my colleagues.
This disconnect between the technical team and the requester, and the lack of guidance, and a pretty long feedback loop left some room for improvement. We wasted resources building things that would have to be completely rebuilt, didn’t fulfill the user’s need, or were not what the user requested or needed. Furthermore, this disconnect led to a pretty time intensive user adoption process. Typically, when the project was ‘done’, user adoption would mean some sessions to explain how the product works, where specific high-priority features and processes could be found and a nice list from the trainees/users of ‘should have and could have’ functionalities that we should ‘definitely pick up in the next sprint’. The product already felt outdated and a subject to improvement when the user started using it.
What?
The need for a strategy or framework on how to best prioritise and structure the work was clear to almost everyone in the organization, and a pain that both the stakeholders but also the people in my team were (and are, to some degree) feeling. The disconnect itself meant we were never short on work. However, it was also a potential win we had been eyeing in terms of team efficiency and user satisfaction for quite a while.
The first obvious candidate to me was to break projects up into smaller sprints and deliverables. We were already believers in the agile framework, the requirements and priorities we are given are constantly changing. But in terms of strategy and finance the vision was always somewhat short-term. “What can we finish in this timeframe”. We would have to more strictly enforce ourselves to work as agile as possible. Breaking down projects into deliverables that could then be divided over sprints. But also create a framework or ruleset that we would enforce to make sure that these different deliverables (or sprints) would still lead to the unified solution the requester/user was envisioning. As the filler of the Software Architect role, I think this ruleset and overarching framework for the different teams was the most work. Inherently this weakness was obscured by just not dividing the work up, and it’s something that I keep an eye on and work to improve to this day.
The second part of this strategy had to address this potential win in terms of our efficiency. We had to make sure that what we built in these sprints would fit the user need, while also giving transparency about the long-term planning and vision of the ‘real’ end-product. If you break projects up into smaller sprints to make sure that you can work on the most important things first, you need to be transparent about WHAT is currently ‘the most important’, and what that implies for the timeline of all the things you are currently not actively working on. We would rather do a few things right, than a lot of things okay-ish. This was the primary reason I opted to enforce what I now know is called ‘Customer-driven Agile software development’.
What does this really mean for the team?
This framework does not mean ‘build whatever the customer wants’, and also isn’t another name for ‘feature-driven development’. Instead, we will plan our efforts with a focus on shareholders/clients;
Within the project add the most value with the least effort (low hanging fruit)
This does not mean, the lowest hanging fruit in terms of projects. Rather we aim to look at the importance and effort of different functionalities within projects that we are picking up, and aim to deliver as much functionality/added value as possible. The aim is to get the user/requester involved, show a tangible prototype so that you can iterate/fail/learn quickly
Be transparent about what the client/user can expect (even if it doesn’t look good)
Be transparent and clear on what projects and functionalities you are and aren’t working on. Have a rough estimation on timeline for the things you aren’t working on, or be honest and transparent on why this timeline doesn’t exist. Maybe that request just isn’t important enough? Or there isn’t enough traction within the organization?
Really understand the requester/customer’s need and purpose.
Sara Blakely, as I’ve learned in her online course on entrepreneurship, regards this simple objective as a cornerstone of her product development. “Always stay connected to the why”. If you want to develop something that truly helps the user, solves their problem and even overdelivers on their expectations, you first need to truly understand WHY the request was made in the first place. The better you understand the purpose of the solution you are building, the more value the user will eventually get out of it. It also creates a safeguard process in which you can evaluate whether the proposal contains problems that need to be addressed, or even if a similar solution is available off the shelf or even within the company already. It’s worth planning effort and resources into this understanding, as it returns on the investment throughout the entire rest of the development process.
What did we do, and what did it result?
Obviously, I don’t just want to point out the benefits of Customer-driven Agile development, or some inspirational best practices. I will outline some concrete changes we have applied to our processes to highlight HOW we have made our Agile workflow more Customer-driven.
Stakeholder briefings with Prototypes before development starts
As part of our ongoing effort to improve our process, we onboarded a UX/UI designer that works on converting customer input into graphical mock-ups. That way the users can already get a feeling on what exactly we think we are going to build, and give feedback on the alignment with their need and user-experience before a single line of code is committed. Depending on the extend of the sprint these mock-ups vary from a set of screens that are demo’s and then used by our front-end team to start development, to a full clickable protoype of the product featuring all the different front-end elements, processes, and user-flows.
This was by far the biggest improvement we have made, especially for our front-end team’s productivity. We found that client-evaluations were often slowing down the development process, or even led to features being re-though or re-built in the middle of sprints to better align with the customer request. It also allows for better end-user engagement as you can show them the potential of your project much earlier in the development program. Where normally about 15% (rounded up) of the features would be over budget, we have now reduced it to 5% (rounded down) as estimated by the front-end developers.
2-week sprints rather than 4-week sprints
Another change was the amount of work (and time) we allocated to a sprint. With shorter sprints we force ourselves to be more critical on what we can pick up in a sprint, and estimate workload for items more accurately. A secondary benefit is that the deliverables of these sprints mean that we can show tangible result to the client earlier and with a higher frequency. So far we’ve found that this improves the clients faith and confidence in the project.
Storyboard stakeholder/user feedback
This one is a tricky one to write about, because I feel like we can definitely implement significant improvements when it comes to properly storyboarding the use-cases and processes within the solutions that we are building. The better we understand the reasons and purpose of why a client is using our solution, the better we can make a system work for that user. To facilitate this we have so far set-up meetings with key-users for our front-end developers and UX/UI person to make sure we better understand how and why a user comes to our solutions and how they go about their tasks.
But with a two-week sprint, the time involved in storyboarding these users becomes quite significant and subtracts from our actual development budget to get features done. Perhaps when our team grows it becomes more economically viable to make this a higher priority.
Better foundations for early adapters and co-creation
Something that we have been able to test and prove with a variety of users and companies in the last one-and-a-half years is that this short feedback loop to clients, as well as the high frequency of tangible deliverables makes for very fertile grounds for co-creation and creating a bond with clients that turns them into ambassadors of the solutions that you build. I would say in terms of market-research, competitor analysis and funding we have learned how the customer-driven agile ecosystem can help us adjust course, pivot or persevere in what we are doing.
What’s next?
In relation to this topic two very important topics come to mind that would be a logical extension of what I have talked about. The first one being the most obvious one;
Internal vs External
Because of the authority we could leverage to our external users and partners, the lessons-learned and practices have been very well implemented throughout the entire ecosystem of our solutions.
The irony would have that for the internal users, clients, stakeholders this dynamic is different. Of course we implemented the 2-week sprints, and the UX/UI driven prototypes. Yet the connection of the original vision of the product and the business needs stays an ongoing challenge. The key issue here in my personal view is mostly the dynamic between the two teams. At the current time the developers seem more like the requesters than the users they are building the solution for, due to lack of concrete input for the details of the end-result. This mostly requires some changes in processes surrounding the sprint planning and roadmapping, but also a sort of culture change where we set shorter-term, concrete goals and let go of a kind of perfectionism. Which leads me to the second point
Fail faster
There is a variety of slogans surrounding failing fast, and with good reason. Over the last 18 months I have also spent significant effort changing the dynamic and mindset of the team from a perfectionist, 100% complete, 100% sure mindset to a more agile, progress is progress mindset. Something that I will also elaborate on a little further in a next article.
The current shorter sprint format allow us to make necessary adjustments as we go, meaning we can start with lower fidelity products and start improving them right away. Historically once a project was finished resources would immediately be allocated to other (very important or longer term) projects and that which was delivered wouldn’t change over the course of a couple of years. Nowadays every sprint should make incremental improvements to the solutions that matter the most.
It might mean that we need to be flexible and allow our focus to shift from project to project, or solution to solution a lot more times than we historically had to with our monolithic approach. But isn’t that the textbook definition of agile?
