Do you have the right mechanisms in place to course correct?

As humans, none of us is perfect. Even if we can, on occasion, execute perfectly on something more often than not we all need to course correct at some point. Some examples of when we need to course correct are:

• Having incorrect or invalidated assumptions
• Starting something that has a lot of ambiguity
• Finding out about missing or hidden dependencies
• Having a plan that falls short of delivering on a specific commitment.
• Failing to accomplish a goal, milestone or key deliverable

That list isn't exhaustive and is applicable to the projects we work on, the way we interact with our peers/directs/superiors, career development and many other aspects of our lives. Having mechanisms in place to help you correct your course *before* or soon after you get off track will help you be more successful.  Here are some tips to help you setup mechanisms that enable course correction.

Be willing to change course

As humans change doesn't come easy for us. Once we set ourselves on a certain course we will naturally want to continue down that course because it's easy. This may sound obvious, but course correcting starts with being willing to change course.

What this means practically is that you have to be open to:

1. Being wrong
2. Doing more work
3. Scraping work you've already done
4. Having difficult conversations
5. Asking difficult questions
6. Being relentless about seeking the truth and proceeding with the *right* data

Ask questions that help you understand when course correction is needed

There are several questions that I try to consistently ask when checking in on the progress of something I'm working toward:

1. Where am I on track?
2. Where am I ahead of schedule?
3. Where am I behind schedule?
4. Is there anything I plan to work on that I no longer need to?
5. Do I need to re-arrange priorities?
6. Is what I'm working on right now the simplest/fastest/most efficient way to achieve my goal?
7. What information do I have now that I didn't when I started? How does that change my approach?
8. Is everything I depend on to be successful still on-track? If not, what does it take to get back on track?
9. How does the recent decision about X affect me?

Meet regularly with your key stakeholders and solicit feedback

Making sure that you're on the right course means talking with your stakeholders often. Depending on the context of what you're trying to achieve, the form of these meeting may look different. But the key is that you're meeting regularly and getting as much feedback as you can.

Some common forms these meetings take are:

• One-on-ones: This is where you are meeting with an individual regularly and asking for specific perspective and feedback. These meetings are more intimate and can typically get into a lot of depth. These typically occur weekly or bi-weekly.
• Daily project sync up: Most agile teams do this in the form of a daily scrum. The purpose of this meeting is to make sure everyone is aware of hyper local changes. Talk about what was accomplished yesterday, what you plan to accomplish today, and what you may be blocked on.
• Program status meetings: This is where you meet with the key participants of a project or program and check in on the status. In this meeting you want to focus on things that are either off track or at risk of being off track. Most often I've seen this occur weekly or bi-weekly. It's really important to have people in this meeting who can authorize change.
• Stakeholder meetings: These are regular sync ups with the people that depend on you and your work or that you depend on. These meetings are typically with people that you don't have much visibility into day to day operations with.
• Team/Org meetings: This is time with your direct team. This time is best used for vision casting, transparency, and/or checking the temperature of the team (i.e. how are people feeling).

You probably need more data to make your decision

In most software projects that I have been involved in there's always come at least one time during the course of the project where we've hit a crossroads and the right next step isn't clear. Usually there are two or three competing paths that each have merit on their own.

In these situations its typical for people to start relying upon conjecture. The conversation starts to turn from we should to I think.  What's the problem with I think? It means:

• The data the decision is being made on is coming from you and not your users.
• The conversation starts becoming more subjective and less objective.
• There is more risk that you build the wrong thing.

In many situations our experience is going to be enough to make a decision with incomplete information. But you need to be aware when the cost of making decisions based on conjecture can affect the success of the project itself. When there's a lack of data about something that affects the direction of the software using the term I think should be a red flag. Here are three key questions you should ask before proceeding:

If I make the wrong decision, am I able to go back and change it?

If you're building software that others are building on top of then it's likely that their business now relies on the decision you've made. In this case once you've released the software it's going to cost a lot of money and time to go back and change it. If you have a large user base it's even likely that some users will be unwilling to change their use.

What's the cost associated with the decision?

Does your decision require you to make significant purchases in hardware or other software? Do you have to bring on additional people on to the project to complete it? How much additional time will be spent building the proposed solution?

If I build this solution, what am I not able to build?

It's possible that deciding to do X means that you cannot do Y or Z. It's important to understand these trade-offs before you start down a particular path.

So how do you turn the conversation from I think back to a confident we should? Answering those three questions is a good start. But you need to also start the conversation with your users. In agile the product owner is the proxy between you and your users. Product owners are usually in touch with the actual users and can provide a more objective opinion on what your users will really need or want. Bring your product owners up to speed on the context and the ramifications of the decision. Let them help you get the right data to minimize your risk of building the wrong thing.

Successfully Shipping Software

It's unfortunate how much software gets written and never actually ships and is used. This can't be wholly avoided because there are times when priorities do change. There are times when projects do need to get shelved due to more pressing needs. And if you're working at a company that values risk taking then projects will get canceled in an effort to fail fast. 

As a software engineer not shipping due to changing priorities or having to shelve something in favor of a more pressing project were two of the most demoralizing things. Especially when I had worked on a project for N weeks or (even worse) N months.

Being able to ship software fast is one of the big benefits of Agile software development. Agile encourages you to ship at the end of every sprint. In the ideal world this would mean putting something in users hands that can be used at the end of every sprint. In reality, this is usually not the case. Often, you ship a series of smaller end-to-end pieces into production which at some point you'll tell your users about.

Here are some things to consider which will increase your likelihood of shipping software your users will use and decrease the chance that you'll build the wrong thing.

Understand your problem

While this sounds like a no-brainer, it's actually one of the things that I see get missed the most. Understanding your problem is not about requirements gathering. You gather requirements about a known problem space. One reason software projects can fail and never ship is because the problem was based on an idea that was never validated. You should always be able to tie your problem back to something a user has asked for.

Identify your milestones

Many software teams identify milestones from the beginning and move forward linearly in time till shipping. This is not a pit of success in that it's easier to miss a requirement than it is to not miss one. It's better to start with the last milestone and ask the question "what needs to happen right before this to achieve this milestone".  Then you keeping going backwards in time asking that question and defining new milestones. Eventually you'll get to a requirements gathering milestone. You'll have achieved either defining all your milestones, or identifying ambiguity that would have likely derailed or delayed your project had you started defining milestones the other way around. 

Know your risks and how they can be mitigated

Every project comes with risk. Being able to identify what risks are associated with your project will help you determine how your project will succeed in the event that one or more of your risks are realized. Some common risks to software projects include:

• Upstream/downstream software dependencies (often internal software being developed by another team) being late or failing to ship all together.
• Hardware/software purchases that need to be made.
• Making sure you're able to deploy to production.
• Not having user documentation.
• Not having a marketing plan for a new feature or product.
• Getting started with performance testing or security reviews late (or not realizing you need to do them at all).

Make sure you know what you need to measure

Milestones are great to help you know whether your project is on track. But they won't help you once your software is released. You need to identify the ways that you should measure your software to understand it's health. You should understand both your customer facing metrics (like the number of failures, the latency of requests, or etc) as well as your internal metrics (cost, performance, system health, etc). Talk to your product owners and your sales teams to understand what they need to measure about the software in order to aid them in their jobs.

Have an exit criteria for success

What is your definition of done? This doesn't mean you won't maintain or make changes. It just means that you've successfully delivered what you wanted to deliver. This should be a checklist of items that's been validated on both the business and technical sides of the house.

Understanding Trade-offs In Software Development

I've worked in the software industry for a decade and a half as both a software engineer and software development manager. One thing that I've learned to do for the projects my teams work on is to anticipate and understand the possible trade-offs you're going to have to make downstream.

It's a given that something is going to change between the start of a project and when you actually ship that's going to force you to make a trade-off. As I've talked about before, Agile and LEAN allow us to mitigate the cost of making these changes by reducing the time it takes to get and incorporate feedback.

One thing I haven't talked about is how to make the right trade-offs for your product.

Minimal Shippable Product

Understanding your minimal shippable product is the foundation of any trade-off decision you're going to have to make. I'm not taking about a gut feeling about what you're customers may want. I'm talking about understanding what makes your product different.

Some questions to ask yourself to identify the minimal shippable product:

• Does the lack of feature X put my product at a significant disadvantage in the market place I'm entering or are already in?
• Will 80/90/100% of my customers use feature X?
• Will missing feature X make you look stupid? For example, a text editing product without copy/paste or an image processing app without the ability to adjust contrast. 
• Is feature X a key differentiator for my product?
• Can your customers achieve feature X in some other fashion? 
• Does missing feature X cause significant friction for your customers?
• Is feature X on the short list of reasons to buy your product?

Time To Market vs Feature Complete

Another very important thing to consider is how important is time to market vs feature completeness. Are you providing a service that no one else currently provides? Does the market you're entering have a sales cycle that requires you to make a specific date?

Being first to market has strategic advantages that cannot be ignored. But being first to market with a sub-optimal product may hurt you worse than not being first. Apple wasn't first to market with the smartphone, but they offered features that weren't available anywhere else. The converse is also true though, they were first to market with the modern day tablet and it took half a decade for anyone else to really break into that market because there wasn't a compelling enough reason to buy the alternative to the market leader.

Breadth vs Depth

The last major trade-off to consider is whether your product provides a breadth of features which are mostly polished or a sub-set of those features that are fully polished. I'm not talking about your minimal shippable product here. I'm talking about the things that didn't make your MSP list, but may be the right things to build for your customers. For example, if you're providing a parity product, you need to know how much parity you need to achieve to be relevant to your customers.

What's your measure of success?

In the software industry, or any industry for that matter, you're constantly making decisions as to where you're going to invest your time and resources. Maybe you're building a greenfield project and deciding where to start. Maybe you're 12 months into a project that isn't going as planned. Maybe your company or organization has pivoted it's business objectives and you're being asked to pivot with it.  Whatever the case, I've too often seen these decisions made without fully understanding what you're committing to and without having a clear plan to measure whether where you're investing your time and resources is actually being successful.

Measuring success isn't simply a matter of checking a box that something has been delivered. There's much more too it than that. You need to make sure you're delivering the right thing. You need to make sure that you're able to fail quickly if/when you discover that you're not on the right track. You need to have a clear definition of what's enough.

Here are five questions I like to ask before I invest in any project that allow me to have a clear understanding of what success looks like.

Do you have well defined user scenarios?

Well defined user scenarios allow you to know if you're building the correct thing or not. A well defined user scenario should clearly articulate what problem you're trying to solve, how you plan on solving it, and it should tease out some of the unknowns or external dependencies.

A great place to start with a user scenario is with a story board. Storyboards allow you to think about your product as it is used in the real world. Too often we start our user scenarios with an interface or UX design. These designs are great but they don't help us tease out the context surrounding our problem. For example, where users are when the problem occurs. Or what type of constraints the environment adds to the mix, like only having one hand available.

Can you show that you're providing business value now?

Does your new investment require that you wait until the product is complete before you can judge it's fitness? This should be a red flag that the structure and milestones of your project are not lined up correctly.

Agile using scrum and Kanban are two great ways to help you answer this question. Agile allows you to break things into smaller more iterable pieces. It gives you a way to measure your velocity as you go to help you adjust your milestones and scope. Kanban allows you to understand what work in progress is going on. It also allows you to understand and account for the unexpected work that inevitably comes down the pipe. Kanban allows you to make more informed resource decisions based on current resource allocations and throughput.

Is what you're investing in structured in a way as to allow you to change scope?

Do you have a way to show incremental progress? Do you have a way to see your work in action in the real world? If not, you should. Having a way to check-in and get a real world feel for how what your building works in the real world is crucial.

One way to do this is by setting up regular demo days. In agile, these tend to fall at the end of a sprint. It gives you a way to quantify what it is you're delivering and a framework from which trade offs can be discussed. I've seen pretty successful scrum teams decide what they're demo'ing at the next demo day BEFORE deciding what stories are in their sprint.

Having demo days allows you to break up larger work into smaller more consumable pieces. It also allows you to identify dependencies earlier in the process. Maybe your demo requires some work from another team? Maybe it requires some additional hardware or resources. Maybe it requires a deployment. Whatever the case, you're able to start asking the correct questions and unblocking your team before any work actually begins.

Are you able to measure success incrementally?

Demo days are one way to measure success incrementally but not the only way. Alpha and beta releases are another way. Getting something in-front of real world users (even just internally) will open your work up to a higher level of scrutiny which will inevitably make your product better. It will also force you to ask yourself the correct questions on how you measure success for individual features. For example, if you're adding a button to make peoples lives easier, how do you know if they're using it? How do you know if it was discoverable? How do you know if it actually solved the problem? Knowing the answers to this class of questions is paramount to the success of your project. Asking that class of questions helps inform the approach you take to solving your problems.

Do you understand the unknowns?

As you start asking the other questions it will become clear that there are always unknowns in your project that need to be fleshed out. It may be understanding the cost associated with the project and how it's going to be funded. It may be intra-team, inter-team, external, or 3rd party dependencies that are not apparent at the inception of the project. It may be that the level of effort is greater than the rewards for building any particular piece of your project.

Whatever the unknown, it should be your goal to root it out. You're process should make finding the unknowns easier than allowing them to crop up at just the wrong time.

Post Mortems

In my previous post on Continuous Delivery I mentioned using postmortems as a way to share responsibility and create action items to address and prevent failures as part of a change. I thought it would be helpful if I took the time to explain how I like to run postmortem meetings.

To me a good postmortem meeting has five distinct parts. Each part has a goal that's measurable and useful in understanding a failure and preventing that failure from being exhibited in the system again. It's important to go through these parts sequentially and in the order defined below.

Identify what happened

This may seem like common sense, but a good postmortem should always start with a chronological list of the sequence of events. These events should focus on the WHAT and not the WHY or the HOW. The purpose of this part is to get everyone on the same page as to what the sequence of events were that lead up to the incident, happened during the incident, and lead up to the resolution of the incident.

Identify what went wrong during the incident 

After the sequence of events has been identified and everyone understands the WHAT of the incident, it's important to understand what went wrong during those sequence of events. It's extremely important to try to keep this factual. If you can't back it up with data, don't include it. Again, that may sound like common sense but it's very easy to get into a finger pointing argument or start blaming other folks or groups during this part.

It's important to call out things like coordination failures, escalation issues, trouble shooting guide issues, or anything else that impeded resolution of the incident. The main goal of this is to take a constructive look at how the existing processes worked and identify holes or gaps in the process.

Identify what went well

After you've identified what went wrong during the incident it's also very important to identify what went well. This is important from more than just a moral perspective. It's important for the group to come to consensus and understand things that accelerated resolving the incident so that they can be included and continued in future incidents. It's also a good way to recognize the efforts of team members or other product groups that put skin in the game during an incident.

During this part it's important to call out things like issues that were identified by an automated system or that were recognized early by some standard operating procedure. It's also important to call out good coordination between teams, any heroic individual or team efforts, as well as any new mitigation strategies that were created or discovered during the incident.

Bring up what issues have been identified as a result of the incident

The main goal of this part is to analyze the data presented in part one in light of what went well or poorly. During this part you want to clearly identify gaps that need to be filled as a result of this incident. This is not the time to bring up HOW to resolve the issues but simply to identify the issues.

During this part it's important to call out gaps in communication or process around incident status notifications. If holes have been found in the trouble shooting guide this is the right time to bring them up. Other things like team members having incorrect permissions or access problems should come up during this part as should lack of training or improper knowledge of third party (or first party) systems.

Identify actionable improvements

By this point you should have a list of things that can be improved. This list may include process improvements, documentation improvements, or software improvements. It's important during this phase to make those improvements actionable. The goal of this part is to walk out of the postmortem with not just a list of what actions need to be taken, but also who is going to take the action. It's very important that one of the goals of the postmortem is that there is a clear understanding of what changes need to be made and accountability for getting those changes implemented.

Continuous Delivery

Continuous Delivery is an important topic in the software world, and particularly the DevOps movement. A lot of the talk around continuous delivery centers around the technical side of achieving it. But there's another aspect that needs to be considered first before it can truly be achieved. That aspect is the cultural changes that need to happen within an organization in order to truly achieve continuous delivery. These cultural changes are not a pre-requisite for continuous delivery, but you should be aware that they do accompany it.

The follow are the five areas that I believe are required for any organization to be successful at continuous delivery/deployment. Most organizations won't be starting at ground zero but being aware of the cultural change that will come can help accelerate a move to and adoption of continuous delivery.

Cross Discipline Teams

Development and operations need to work together. Ideally, they're both represented on the same team. One of the main goals of continuous delivery is to identify defects earlier in the pipeline and to provide business value as early in the pipeline as possible. The best way to achieve this is to think about delivery from the beginning. The project team should be planning the deployment even before the code is written that they'll be deploying.

Raise visibility

For every change the project team should understand how the change can be measured. Here are a few simple questions that you can ask as part of the dev cycle:

• What metrics are associated with this change and how?
• What are the risks?
• Is the performance profile expected to change?
• How do we measure success for this change?
• What are the signs that the change is not effective?

Build trust

Operations and development need to know that enabling the business is the #1 priority for BOTH units. No change should make it's way into the deployment pipeline unless it provides business value. If both units understand this then we have a shared understanding of the importance of each change and a shared desire to get that change out.

In order to build this trust the operations folks need to know and believe that the development folks will include them in feature discussions. Having operational discussions early and often in the conversation will help ensure successful deployment of the change.

On the flip side the development folks need to know that the operation folks are including them infrastructure discussions early and often as well. Again ideally, these folks work on the same team and these discussions are part of the normal standup discussions.

Minimize risks 

We need to understand that failure happens. It's how you deal with failure that leads to success or failure for the change. It's naive to believe that failure can be prevented 100% of the time.  Because we know it can't our goal is to minimize the risk of any change should it fail.

In order to minimize the risk to the overall system for any given change should focus on reducing the overall surface area of the change. The smaller the change the less risk there is of a failure associated with that change being catastrophic. The longer the time between releases the larger the risk of that change. The more code that's released with every change the larger the risk of failure or bugs.

In order to respond to change effectively we need to build a culture that responds to failure well instead of trying to prevent it. The easiest way to respond to failure well is to practice it. Build failure tolerance into your system. Understand how your system responds to failure and identify the expected and appropriate user experience when failure happens.

Shared responsibility

We all succeed or fail together. It's not possible for operations to succeed and development to fail (or vice versa) and have the product succeed. Both disciplines need to succeed in order for the business to truly succeed.

Once we've grasped the concept that we succeed or fail together we can create a culture where it's okay to talk about and address our mistakes. We try to avoid finger pointing and are able to do this because people own up to their mistakes and take responsibility for them. They participate in postmortems where they create action items to address the failure and prevent failure of that kind in the future.

Having shared responsibility also means that we treat rollback as a last resort. When a problem arises with a particular change we stop the line. We work together to figure out the problem when it happens and we work together to fix the problem before we move on to making additional changes in the system.

Sharing responsibility means that both the operations folks and the development folks should be on-call for incidents. Nothing provides better incentive to fix a problem than getting woken up in the middle of the night or interrupted on a Saturday.

Software Craftsmanship: Project Workflow

In working through the topic of Software Craftsmanship for the past few weeks on this blog we've talked about how to approach software development from a code perspective.  I'd like to take a short break this week and talk about optimizing your project workflow in step with optimizing your code.

Over the past decade the Agile development movement has really taken over in the technology industry. You'll find many different forms of agile development used throughout the software industry. You'll even find many different flavors of the same form of agile used differently from organization to organization.

While there's no single one-size fits all solution when it comes to managing your project, it is important to have a base template to use as a frame of reference. My go to template is made of up a hodgepodge of different agile methodologies. The template is made up of three parts, and like any agile process, involves constant iteration through the parts.  This template is driven around three main concepts. First, the beginning of any project involves more unknowns and more risk than the end. Second, the process should involve creating features that are useful and complete. Third, communication, preferably face to face, is needed throughout the process.

Ideally this template is used in conjunction with some sort of Kanban process. A lot of people make the mistake of centering their process around Kanban. That in my opinion is a recipe for failure as Kanban helps you understand how to move work through a system but doesn't do a good job of helping you identify the correct work to move through the system.

Part 1: Identify The Problem Space

In this part you want to have an Initial Design Meeting. This meeting would consist of the project team, the key stake holders of the project, and any other outside tech advisers (like an architect or team lead) which may be able to provide insight into how this problem space fits in with other problem spaces throughout the organization.

In this meeting you want to Identify The Unknowns. The first unknown is what we're building. A quick discussion about what the problem is or what features the system is missing. Once we know what the problems are that we're trying to solve we can start creating straw-men for possible solutions. A good way to flesh this out is to create a few user scenarios that represent the desired workflow for solutions to our problem space. Questions to ask when evaluating the straw-men are:

1. What are the big open questions?
2. What risk do the unknowns represent?
3. What's in scope?
4. What's out of scope?

Part 2: Identify The Features

This next phase is all about defining the Minimal Viable Products. This is key as we want/need to know how we can provide some sort of business value as early in the project as possible. There are a couple of characteristics that I use when trying to determine if something is an MVP that I think are useful:

1. Can the MVP stand on it's own. I.e. if the project were to end or the company were to switch gears for a time, would the MVP still provide value to the business or would it need subsequent development in order to be of use?
2. Is success clearly defined for the MVP? Do we have a clear idea of what the definition of done means for the MVP?
3. Is the MVP achievable in a reasonable time frame?
4. Have we identified the external dependencies of the MVP?

When we're done identifying the MVP's we can organize them by things we can work on now and things that need more information to get started. Each MVP or a set of MVP's can constitute a project milestone.

Part 3: Create stories

During this step in the project workflow the team will get together and identify the stories associated with each milestone (or at a minimum the first milestone).  Take a gander at this article if you're unfamiliar with user stories. Breaking work out into individual stories helps us to keep focus on delivering on our milestone.

Once we've identified our stories we need to identify their dependencies and possibly associate some of the stories with other milestones if they have dependencies that can't be resolved early on in the process.

Lastly, in this part we create "bite sized" tasks for each story. This can be done all at once or, more preferably, at the beginning of each milestone.

Starting the work

Once we've gone through these three parts our teams can start their work. In order to be truly effective and stay agile, the team should work on one milestone at a time and not move on to next milestone till all stories for the current milestone are complete. During the teams daily stand-ups you'll want to report the status of each task/story and identify any of the blocking items that need to be resolved.