EMBEDDING INNOVATION IN THE SOFTWARE DEVELOPMENT PROCESS.
Starting the development process with just a concept…
It is OK to start the development process with just a concept. Clearly define the objective/s in business terms and move quickly to development. There are certain pieces to the puzzle to make this approach work, but it has considerable benefits when it comes to innovation.
The task of detailing requirements and specifications lends itself to convergent thinking i.e. applying established rules and logical reasoning based on experience and existing knowledge. Most people can apply convergent thinking based on their knowledge and experience. Will we innovate with convergent thinking? I think it is unlikely without divergent thinking where ideas are explored in a more spontaneous and emergent fashion. We can combine the two styles to think laterally about business problems and solutions.
Albert Einstein was a strong divergent thinker. There are few Einsteins among us, but starting the development process with just a concept and the right framework can introduce a greater degree of divergent thinking as a team. The individuals in your team and your business have their own experiences and knowledge. Harness this. Approach development as an exploration where we continually throw a diverse range of ideas into the mix to come up with more ideas and ultimately the best solution.
With the right team and disciplined processes, developing a working prototype as a proof-of- concept can be the cheapest way to explore requirements and there is huge benefit in working with something real. A living, breathing canvas to build your ideas upon that no paper document could ever replicate. It also introduces end-users into the process, exposing requirements that were not obvious and further promoting divergent thinking. What you thought was the best solution at the start of the process you often find out was not. Simpler and/or more effective solutions result from this exploration.
We converge on the solution by evaluating and making adjustments in direction-based on objectives, not constrained by detailed functional requirements and specifications established at the start of the process. By defining and focusing on what success looks like in business terms, you can combine the spontaneous and free-flowing process of divergent thinking with systemic convergent thinking to achieve better outcomes for the business.
Solving real problems, not just coding…
Broaden the role of software developers in your team. Their contribution to innovation increases the closer they are to the problem. This approach removes layers and silos in the team, promoting lateral thinking and agility.
It seems common for developers to be shoehorned into operating more like a factory worker than a lateral thinker and innovator. They receive a specification, produce a product and pass it on for testing rather than being an equal contributor throughout the problem-solving process. I have not worked with a good developer that isn’t smart, creative and passionate about their work. Why treat them like factory workers and confine them only to implementing other people’s specifications? Having developers directly involved in analysis and the feedback loop improves efficiency and the quality of the outcome.
Traditionally, we have relied on highly detailed and accurate specifications to ensure the project delivers the right outcome. This is the best approach when repeating something that has been done before, but it stifles creativity and becomes costly when innovating. The goal should be to remove layers in the project team and have software developers working closer with key departmental stakeholders. If developers understand the problem and aren’t constrained by specifications, they are better placed to implement the best solution. If they are receiving feedback directly, they build deeper empathy with the individuals they are designing for.
It’s not everyone’s cup of tea. A lot of developers gravitate to the technical domain, and it is a continual exercise to promote a business focus. Once comfortable with the broader role, there is considerable satisfaction from solving problems, not just coding.
Involve the business in development…
Involve people from the business domain in the development process as much as possible. With the right project framework, non-technical people can contribute significantly to project success. There is great benefit to this approach in terms of lateral thinking and ownership of the outcome.
I talked about lateral thinking to solve business problems – combining the spontaneous and free-flowing process of divergent thinking with systemic convergent thinking. The experiences and knowledge of team members from within the business augment that of the technical team. With a diverse range of ideas and perspectives, we increase the opportunities for innovation. Their focus on business outcomes also provides an ideal perspective for converging on solutions.
The other benefit is ownership. It does not matter how good your solution is if it is not accepted. People that were involved in the process are familiar with how to use the software and they know how it came to being. They went on the problem-solving journey. It is their baby, and they will influence the attitudes of others in the business.
