Software Development Done Right

Even those with the best preparations will encounter setbacks and challenges that they need to overcome.

 

“Everyone has a plan until they get punched in the mouth.” - Mike Tyson

 

The key here is to not be discouraged. Building software is a journey, it takes a strong resolve, clear communication, and intense focus for you to succeed. What I’ve been covering in these chapters are many of the best practices that I have learned through my career and am sharing with you. These best practices are meant to enhance your critical thinking as you build your software product. In the final chapter, we will tie this all together with the Software Development Done Right Framework that puts these concepts into practice. However, this chapter isn’t about the process, it’s about emotions. It’s about that feeling that everyone at some point will encounter during the project. The feeling like you are caught at sea in a row boat during a hurricane. It’s during these times when you’ll need to look at your map, reassess the situation and focus on what is most important. It’s also recognizing there will be challenges and those who tell you otherwise, even if they have built hundreds of software products, aren’t being truthful.

 

So, what are some examples of rough seas you will encounter?

• You are forecasting now that the costs are going to be above and beyond what was planned.
• You aren’t going to release on time
• You are unsure that some of the features you planned on are even doable.
• You have lost some critical members of your crew.
• You have released your MVP and are not getting the market response you had wished.

 

I’m not stating this is an exhaustive list and you will encounter all of them, but you will at some point hit one of these (or another that I haven’t listed)

 

So, what are some principles we should bring to the discussion when things are off track?

 

It’s far too common for those in leadership, (i.e the captain of the ship), to want to jump in and start trying many different approaches such as pushing the crew to work longer hours, adding more people to the project, randomly cutting scope, etc. Instead, I offer you to take the time to step back, take a number of deep breaths, go out for a walk or a run, and let your mind clear. You need to move into strategic planning mode. You then do the following. This is taken from a system that we use at Lab651, called EOS, where during what are called Level 10 meetings, we clearly identify the issue, discuss it as a team, and generate a series of TODOs to solve it. What you’ll find in most cases is that the issue wasn’t clearly defined. You must, and I say MUST, define the problem in terms of an issue. For example (and, yes I would always write it as ISSUE: ). This forces you to make sure you are writing the issue.

 

ISSUE: The feature we have defined for this release will not be completed in the original budget

In this case, we will assume that costs are an issue. 

 

I will discuss in a future chapter, why you should always have a buffer (we set aside a +/- 15% window at Lab651), but in this case, let’s assume you are looking like you will be over budget. I want to be clear here, at this point the project is not actually over budget. If we are using our Software Development Done Right Framework, we will catch this well in advance through a series of milestones, weekly demos, sprint planning and estimations - all of which keep you laser focused on the progress. For this case, you are looking at the current amount of work left, and the estimated effort and can clearly see the costs will overrun the initial estimates. In that case, you need a Level 10 meeting with issues.

 

As the captain, you want to ensure the following happens in your meeting.

 

1. Be positive. Ensure that everyone on the team comes with a positive mindset.
2. Be open. Communicate openly with the team and other stakeholders about the issue, but don't be defensive or blame others.
3. Be creative. Let everyone present their ideas on how you can improve the trajectory of the project. You’ll be surprised
4. Come out of the meeting with clear action items that you hold those accountable for during your next standup.

 

If you are curious to learn more about IDS, visit this blog post on IDS.

 

If done right, regardless of the issues, you will find a resolution to the current crisis. And what’s beautiful is that you are using the power of the team to solve it!

 

I will save the concept of a retrospective for another chapter. But as we close this one out, I would ask that you be honest with yourself: If the project needed a reset, it means something went wrong along the way — and now it's up to everyone to figure out what happened so that we can prevent similar problems from occurring in future projects. As I stated at the beginning, something will come up that will cause your emotions to stir. It’s expected, and the degree to which you can handle it, you will be a stronger leader and build a stronger software product because of it.