Developers and users
Software developers have historically been portrayed as mushrooms sitting in a darkened room. It is forbidden for them to connect with the business units. It also makes sense, as focus is needed to produce quality code.
It is also unthinkable for a developer to contact a client directly to understand how they use the software.
Let us shift our perspective away from the traditional silos for a while and look at the impact it would have to move developers to the forefront of the software development lifecycle (SDLC) – the gathering of requirements.
Unused and unfit code
Every company has a few solutions that never made it to production. Money was wasted on something that was believed to add value – but didn’t.
Imagine the opportunity to find which part in a solution does not add value. How would the landscape change if we could stop a process that doesn’t add value before it even starts? By closing the gap between the end-user and the developer, this would be identified well in advance.
Mary Poppendieck describes the difference between development and production. She likens development to the creation of a recipe, and production to following the recipe, with the principle differences outlined in the table below:
|Quality is fitness for use||Quality is conformance to requirements|
|Variable results are good||Variable results are bad|
|Iteration generates value||Iteration generates waste|
The focus should be on learning what adds value and what is a waste. To avoid relearning, the team can keep track of all the functions in an excel file, with supporting documents in a folder in the cloud or on a shared drive.
This should be accessible to everyone in the team.
On a practical level, it would look something like this:
- A feature has been requested
- What would be the most valuable assumption that could be tested? What can we learn from this?
- How do we code to test our assumption?
- Can we build just the user interface without any features and check with users if the idea works?
- Once implemented, how can we measure what we’ve learned?
- How does what we’ve learned change our view and way forward?
Let’s look at an example.
A request came through for doing credit checks on multiple people at the same time to check for the affordability of a loan. It included complex email business logic depending on what your partner’s credit score is.
In a traditional business, this would go to the business analysts that would break this down into stories to build. Within a business focused on learning, the team would question how could we test if this would add value:
- Can we add a menu item on our website and a contact form to test if this would work? Can we track this through Google Analytics?
- Should we include the complex emails, or can we just to the multiple credit checks for now?
- What part of the feature will add the most value?
- Is this feature at all necessary? How can we prove that we should build this feature at all?
Unless the business consists of a single person, it would be best to let the team decide on how to test that the idea will be viable.
Developers understand code.
Business understands the requirements.
The client uses the software every day.
Though software developers tend to dislike meetings, it would be worth it if they assist in defining what needs to be learned and how to measure the outcome. By closing the feedback loop between the coder and the user, the learning can be accelerated. Here are some ways to do this:
- The business analyst should have regular conversations with the coder and user to establish what would be quick wins, what is doable and what will take more effort.
- Get developers to shadow users in a focus group
- Have regular sessions with business, business analysts developers and users so that everyone is aligned on where the software is heading
- Allow developers to speak to users directly when resolving bugs and issues
A business should work as a team. Work together to learn and grow.
Avoid silos – learn as a team what will work and what will not.
Keep track of all learning so that one could refer to it at a later stage.
Simply be effective.