Software Development Done Right
Ch. 1: Software Development Is Emotional
While I alluded to it in the introductory article, Software Engineering is its own discipline. Over time I believe you’ll soon learn, it’s much less Engineering than you might think. In fact, just as it is when leading any team, I hope by the end of this chapter you’ll see that it’s much more emotional than science.
While there is a process and any good team you work with should have a process, it has “Engineering” in the name because at the core the word Engineer is derived from the Latin words ingeniare ("to contrive, devise") and ingenium ("cleverness").
Engineers are taught through their schooling to be clever and design systems that haven’t been seen before. And that’s what is unique about what they do. Every project and every application has a component that not only an engineer, but really everyone on the team hasn’t seen before. Because of this, we need to ensure that all of the stakeholders who are invested in the success of the project are working in concert.
Like all of the instruments in an orchestra, or as I touched on in the first chapter, working together on a ship, each is doing its part to create something that is more than the sum of the parts.
But that is just good communication between all parties. Nothing more.
Where the emotions come in is when constraints are put on the system. As you work with a team of individuals to build your software product, there are three circles that exist: Good, Fast, and Cheap. If you are lucky, you can pick two. Here’s a diagram with explanations:
When the project is starting, you’ll find everyone is gung ho. It’s the start of a long journey -everyone is fired up, the skies look bright, the wind is light and enormous potential lies ahead. The map to the treasure is clear with success virtually ensured! If you have the right team, they will have done their homework by defining the various phases your product will go through by putting together a development roadmap, bringing the team together with clear alignments on the tasks and priorities and how the project will be run. It’s all perfect!
Until it’s not.
At some point, the promises of what will be completed and in what time frame begin to slip. The product is tested in real-time and requirements need to change. What you originally thought you needed to build is close, but not ideal, which causes people to work even harder.
And here’s the kicker. No one wants to hurt each other's feelings and bring the hard truth to the forefront.
Emotions kick in
HOLD ON - STOP! We have taken something that most view as a purely scientific-based process that has clearly defined steps with algorithms to be coded and compiled and run flat into the face of people’s feelings. And as long as we are humans on this earth, the feelings will win. So how do we solve this? I have presented on this topic at many conferences and have seen this far too many times to count.
In short, there are a handful of things that we can do to help.
- Most importantly - recognize it and accept it within the team.
- Discuss openly and honestly what factors lead to the current state. Most often you’ll find that members of the team need to accept accountability. This can be a culture shift, but it’s needed.
- Everyone on the team needs to clearly understand the “WHO” “WHAT” and “WHY” of the product and its features. Make a Product Charter. Having this explained gives an emotional tie to the work being done and a clear understanding that results in a better product being built.
- Process - As you’ll see in future chapters that I write, I’m a big fan of clearly defined processes and procedures. When things are left to chance they are not repeatable. One of the things that often happens is “assumptions” are made. The team begins to get sloppy and assumes that everything is going according to plan. One of the things we do at Lab651 is schedule demos and short retrospectives at the end of each sprint. These are on the calendar and are non-negotiable. When communication is a part of the process, it’s not missed and items are brought to the forefront right away. No questions asked.
So there you have it. My perspectives on how building a software product is an emotional journey based on experiences that I have seen. I also have suggested both here and in my slides, a number of things you should put in place. I would encourage you to ask whoever is partnering with you to build your product to ask how they mitigate the emotional aspect that is sure to be a major component during your development journey. The items listed here are by no means a silver bullet and teams certainly have other approaches, but these are questions you should be asking as you evaluate your software development partner or internal team.
Don't miss a chapter! Subscribe to get the monthly chapter in your inbox >