I once heard that those that know how always work for those that know why. After thinking about this for a bit I realized that those that know why could never achieve anything without those that know how. When it comes to software the “why” folks are the business guys (executives, product owners, etc.) and the “how” folks are the tech guys (scrum masters, developers, QA specialists, etc.).
The business guys don’t necessarily care “how” it gets done, only that it actually gets done and as fast as possible. They are looking to address specific revenue related business concerns The don’t care about software methodologies, frameworks, patterns, and architecture, only that the software does what they need it to do. The end user of the software doesn’t care if an agile methodology was used, or what java script library was used, they only care that they can be as effective as possible in using the software.
As product owners we’ve all been there! When will it be done? Why is it taking so long? Throw more bodies at it! Have the current team work extra hours. This point of view from the top, especially over a prolonged period of time, will create shoddy software, lower morale, and cause turnover. All outcomes are not good for the organization as a whole and will wreak havoc on the long term sustainability of a software product.
The tech people don’t necessarily care “why” it needs to be done, and sometimes don’t know 100% how to actually do it. A technical person will know what framework to use but when given a vague list of what the software should do it becomes extremely difficult to interpret these “requirements” and implement the right thing.
As developers we’ve all been there! A vague list of steps that the user needs to take with no real understanding of what the actual user’s goal is; show this screen, allow them to press this button, require them to enter this info, show this list of things. I’ve seen instances where product owners feed the instructions to the developers piece meal over several weeks, imagine trying to build something good and not knowing what you are building until it’s done, how can it be good?
Some of my greatest memories and most successful implementations were when the business and tech guys were totally aligned, when the developers knew more of the “why” while they designed and built the software, and when the leadership vision of the organization was to create the right software for their users and customers.
Building a team like this is not easy but it can be done. It requires change from both the business and the tech guys, and it requires trust. Trust that the technical people can make delivery schedules, that the software will meet the goals of the business, the users will be able to get done what they need. The technical people need to know that the business has their backs, that the business wants to develop a good product, that the business actually cares about the customers.
There are strategies that can be implemented to help both of these groups get closer, build trust, and become the well oiled machine that they need to be. By improving the processes used to design, build, and distribute software these teams can start to work together.
Here’s a short list of ideas that can help make things better:
1) Allow software to be deployed as fast and as often as possible, if you have a SAAS product or the like this is easier than you think. If you have an internal line of business app this is a little more difficult but the same principles apply.
2) Take the time to do more automation; testing, building, releasing. The more you automate the less manual risk you have. There’s a small up front cost but the ROI can easily be shown when applied to a period of time. 1 week overall, not consecutive, up front for a 4 month project is nothing, you will gain the 1 week of time back with more releases, less debugging of issues, less production troubleshooting, and less customer service issues.
3) make the desired result of the software or feature known to the technical people. The more these guys understand what the desired result is the better they can make the software both architecturally and usability wise.