Modern Solutions: Stakeholder Experience

by Jim Leonardo, Vice President, Capax Global

At Capax Global, we work collaboratively with our customers throughout the software development life cycle to build not just the software, but a complete solution. By applying modern practices, processes, and technologies during development, we’re able to deliver high-quality solutions tailored to our customers' needs. This approach is what we call Modern Solutions.

The Customer Experience

Modern Solutions focuses on the customers’ experience when they engage with us. To ensure their experience is always great, we have to clearly define the Stakeholder Experience, User Experience, and Developer Experience.

This article specifically discusses our Stakeholder Experience, which is how we ensure our customers get the product they need and have a good experience with our company. I’ll be covering the User Experience and Developer Experience in upcoming articles. User Experience defines how we develop a system that meets the users' needs in an efficient and brand aware manner. Developer Experience is how to ensure the people who are building the system are doing so efficiently, with high quality, and in a way that can be supported now and in the future.

Stakeholder Experience

At the end of the day, our product isn't software, it’s a satisfied customer. Creating custom software solutions is how we accomplish this. Building custom software is a collaborative, exploratory process but no amount of upfront analysis will come up with a complete system specification. There will always be something missed, something to be changed, and something that can be improved. At Capax Global, our Modern Solutions approach to software development uses commonly recognized Agile and Scrum techniques for project management adapted to our customers' needs. To guide our adoption of Agile and Scrum techniques, our Stakeholder Experience focuses on four values:

• High Quality
• Predictable Delivery
• Frequent Feedback
• Embracing Change

High Quality

When I was in school, there was talk about proving a system was correct mathematically. The "mathematically" bit always tripped me up because most of my professors were refugees from the math department. I always thought that was a bit unrealistic because the reality of state-of-the-art application — even then — was a multitude of subsystems. Even a text editor needs a subsystem to handle saving and retrieving files, printing documents, copying and pasting, and dealing with all the craziness that comes along with user input into the text area.

It seemed nigh unto impossible to me at the time that we could prove an application worked by "mathematical" proof. Today, I'm sure those professors are still looking for their proof, but the development community has matured greatly in the realm of automated tests. Especially using unit tests, which focus on our small pieces of code, we can test inputs and validate outputs in a systematic way and measure the completeness of those tests through coverage analysis. The coverage analysis allows us to see what code within the application has been tested and be sure all of it has been tested. This form of testing is quick and easy to write because it is isolated from the rest of the system.

Ensuring high quality ultimately comes down to testing the system thoroughly. Traditional development models rely heavily on separate Quality Assurance (QA) staff to find bugs and report them back to developers, then the developers fix them and repeat the process with the next test release. This is slow and expensive as it allows bugs into the process in the first place.

Our first principle of high quality is to be clear on the role of QA, which is to validate the solution is fit for its intended purpose. Under this principle, QA's job is not to find bugs. It’s to make sure there are no defects in the system and the system is what the stakeholders need. QA will find bugs as a natural consequence of this, but the test release should be as good as the delivery team can make it before it reaches QA. To ensure QA understands what the stakeholders need, we include QA team members during the upfront discovery phase as well as during the product backlog grooming sessions.

This leads to our second principle of high quality, which is that it’s the developer's job to thoroughly test their code before sharing it. Under this principle, we develop a large number of unit tests (sufficient to cover 95%+ of all code written) and automatically execute these tests before the developer even shares their code. We also build integration and acceptance tests to provide more holistic, yet still automatically executed, tests that run as part of the server-side build process. By having a high degree of test automation, we are able to build and deploy with confidence.

Predictable Delivery

Nothing causes lost sleep at night like not knowing if the people you are relying on to meet your objectives are going to deliver on time. Every manager wants to be able to predict their delivery.

Our first principle of predictable delivery is that we work against a product backlog. A product backlog is a list of all features that have been identified for the solution, even if they are part of some far future release. Each feature is a product backlog item consisting of a description and a set of acceptance criteria. These features are force ranked to provide a relative priority so we know what is most important. Once all features are ranked, we work with the stakeholders to decide which product backlog item is ranked lowest — so we can then measure progress against it. As we build features, we measure velocity and progress by watching how quickly we close the product backlog items that are ahead of the last item for that release. This allows us to know if we will reach that last item in time or if an adjustment needs to be made. The product backlog is managed in a tool such as Azure DevOps, where stakeholders and the delivery team can view and edit it.

The second principle of predictable delivery is establishing a regular delivery cadence. We work in three-week sprints where we identify the work from the product backlog to be completed over those three weeks and make a commitment to deliver it. We then measure what we completed, checking our velocity against the last item in the release. By working in three-week cycles, we have a known day when all in-progress work must be completed and then we can measure progress across the entire team. Most important is the commitment we make to deliver all the work we said we will deliver. Barring truly exceptional circumstances, we take whatever steps are needed to complete the work during that three week period. Three weeks offers a reasonable amount of time to get a lot of work done, yet we aren't having to work long hours for an extended period — in case something turns out to require extra effort.

The third principle of predictable delivery is frequent and structured checkpoints. We provide a regular cadence of meetings designed to communicate progress and risk. We demonstrate progress after each sprint to ensure the stakeholders have regular visibility into the progress:

1. Daily Standup meetings: A 15-20 minute morning meeting where each member of the delivery team discusses what they did yesterday, what they are doing today, and what they may need help with. Stakeholders are welcome to attend so they are informed, but the meeting is focused on the delivery team communicating what is happening today with one another. As part of the daily standup, we measure the progress of tasks within that sprint, helping us predict whether we will hit the goal or if we will need to redouble the team's efforts to complete the sprint.
2. Weekly Project Review Meetings: A one-hour meeting with the project sponsor and possibly a smaller set of stakeholders. This presents a formal report that covers progress made during the week, budget usage, risks, and an updated delivery forecast.
3. Sprint Showcases: Held every three weeks, the audience of this meeting is all project stakeholders. This is a live demonstration of work completed over the past three weeks. Actual working code is shown and feedback collected from stakeholders to improve the solution.

Frequent Feedback

There is a game called "telephone" where you take a group of people and tell one person something. That person then tells the next person, then that person tells the next one, and so on until it gets to the last person. The last person then tells the first person what they heard and — inevitably — it's completely different than what was originally said.

You can march predictably against a predefined product backlog and get everything done on time but still miss the mark in creating a usable system. Sometimes this is because communication from the people creating the requirements to the people implementing those requirements isn't quite complete. Sometimes it's because there is an unknown or trivial use case that turns out to be quite important. It may be the original requirement wasn't quite right. Or, even if the delivery was on point, there may be a better way to serve the need that only becomes evident once that functionality is available in a living system.

So in our "telephone" example, how do we protect against the message being corrupted? One way is to have the first person listen to each conversation and provide their feedback as to whether that was the right message. We use a similar approach in developing our modern solutions and this leads to our first principle of frequent feedback — regularly scheduled system demonstrations. We use a sprint showcase as a collaborative discussion to identify where the system can be better, what is on target, and what missed the mark. If anything can be different or better and is a very trivial change, we can complete it that day. If not, we hold separate sessions to create new product backlog items to address the change.

Our second principle of frequent feedback is open communication between the development team and subject matter experts. We establish close communication with customer subject matter experts through modern collaboration tools like Microsoft Teams and old-fashioned ones like face-to-face discussions and phone calls. With open communication, our development team is able to ask clarifying questions as they are developing the system rather than waiting for formal meetings. This reduces the amount of work that goes into developing the wrong thing.

The third principle of frequent feedback is open access. Key stakeholders are given access to the continuously deployed "development integration" environment where they can log in at any time and see the state of development. This allows them to see work before sprint demos and comment on it. If the comments result in a trivial change and the work in that area is still ongoing, we may address it right away. Otherwise, we include it as a new product backlog item.

Embracing Change

No business is static. It changes every day. Even when we're delivering the solution exactly as asked, the stakeholders may decide there is another improvement to be made, something could be done differently, or there is a change in their business that requires a change to the solution.

Our first principle of embracing change is to constantly refine the definition of the product. During the course of each sprint, we work with stakeholders and subject matter experts to refine the product backlog. We focus on items that, by priority order, are likely to be included in the following sprint. We add product backlog items if needed and refine the description and acceptance of the existing product backlog items. Often, we don’t even define the acceptance criteria until the sprint before. This ensures the work in the next sprint reflects the current understanding of what the system needs to do rather than a months' old understanding.

Our second principle of embracing change is to limit how much change we're working on at once. We won’t change the sprint commitment except under rare circumstances. Not changing the commitment means not changing the definition of the product backlog items that have been committed to as well as not pulling in additional items. This helps ensure we get our commitment done and makes sure we're focusing on the current work and not dividing our attention across multiple progress items. After all, embracing change means we have to be able to deliver on that change.

Conclusion

At Capax Global our goal is to ensure we have a satisfied customer. To do that when building a custom solution, we must embrace clear communication to understand, and adjust to, the customer's evolving needs. By adhering to the four values of our Stakeholder Experience — high quality, predictable delivery, frequent feedback, and embracing change — we can support the communication and change needed to successfully deliver complex modern solutions and ensure an excellent customer experience.