Changing Your Software Delivery Process

Software processes come and go. Over the last 20 years we’ve seen the industry choose various types, ranging from the Rational Unified Process to V-Model, Scrum, Kanban, unprocess and many others, and — most commonly — combinations of all of them. We talk a lot about the advantage of various processes in different scenarios, and somewhere out there is a process that’s right for you. Once you find it, you’ve only got to overcome one more hurdle: getting to it from where you are today. Before you can decide on a process, you have to answer two big questions:

  • How do you get from where you are to where you want to be?
  • How do you continue to deliver software while you’re changing your process?

Big Bang‘Big Bang’ Vs. Incremental Change

It’s tempting to make an entire set of process changes at once — the “Big Bang” approach. Most processes assume you’ll be doing them whole-heartedly, and they work because all of their pieces fit together. For example, if the process you want to achieve is a scrum process, you can’t just start a sprint. You have to have a backlog from which you can create the sprint. The team has to understand how to estimate, scrum-style, and what commitment means. If you choose a Big Bang approach, you’ll start reaping the full benefits of the new process sooner. On the other hand, it’s a lot of change for a team to absorb, and requires a lot of learning and attention to process. That means you have to stop everything else — like delivering software — to make the transition effectively.

The alternative is to take an incremental approach: Introduce elements of the new process one at a time while keeping the rest of your old process in place. Getting to the new process takes a lot longer this way, but it’s less disruptive. For example, if you’re going to a scrum process, you might first start doing daily standups. Everything else — planning, estimating, delivering — can still be done the old way. Then you might introduce the idea of a backlog, looking at the next few weeks of work without committing to it. After that, you might introduce planning, followed by sprint demos, retrospectives, etc. This approach takes a lot longer and means that the benefits of the new process accumulate more slowly, but it gives the team less to absorb at one time and means they can still deliver software along the way.

Choose the Big Bang approach when:

  • It’s a new team or project and you don’t have a prior process or method.
  • The current state is bad enough that you’re not shipping software anyway.
  • You have a long enough time before the next deadline that you can afford a productivity drop specifically to make the switch.

Choose an incremental approach when:

  • You have ongoing deadlines and can’t afford the productivity drop.
  • Your new process and your old process aren’t very different, so the overall change is small.
  • You’re not sure the new process is the right one for you.

Before The Switch

Regardless of which approach you choose — Big Bang or incremental — you must do some preparatory work before any processes can change.

  • Identify Your Target. First, identify the process you want. Be specific and detailed. “Scrum” is not enough. Instead, walk through how it applies to you.
  • Do a Gap Analysis. Figure out what you’re doing already that’s part of your target process, and what you need to change.
  • Identify Affected Parties. Most software processes involve people outside the development team. Product management, release engineering and support are often involved in processes, and they will have responsibilities and changed expectations even if they’re not directly affected.
  • Train the Trainers. Any new process will lead to questions about how to handle specific situations. You need someone the team can always go to for answers. This can be a consultant who is an expert in the process you’re targeting, or someone internal who is a process evangelist. Whoever it is, this person needs to be identified and trained.
  • Choose Your Approach. It’s time to choose: Big Bang or incremental.
  • Create a Schedule. Figure out how long the training and adoption will take, and publish the schedule. This helps the team and external parties understand how long the process change will take and when life can get back to “normal but better.”
  • Warn the Teams. Let the teams know what’s coming, when and why. It’s much easier to get buy in when changes aren’t a surprise. Ultimately, the teams will be the ones living with the new process, and getting them on board makes success much more likely.

During the Switch: Big Bang

If you choose the Big Bang approach, the process switch will happen over a relatively short period of time. Take a deep breath. It’s going to be a whirlwind! Here’s how to do it:

  • Kick It Off. A formal kickoff is important. This is the time to reiterate with the whole team what you’re doing, how it’s going to happen and why. It makes sure everyone is on the same page. This meeting is best done in an hour or less, and providing lunch is never a bad idea.
  • Train Every Team Member. Divide the teams into their functional groups — developers, project managers, release engineers, testers, etc. — and train each one. Spend as much time as the team needs walking through each process change and talking about the new way and how to do it.
  • Walk Through a Practice Cycle in Functional Groups. Every process has a cycle, whether it’s a full release, a sprint or an arbitrary time period (a week is pretty typical). Have each functional group walk through a practice cycle and discuss activities and responsibilities throughout the cycle. This is a good way to work through any holes or questions about the new process.
  • Walk Through a Practice Cycle as a Whole Team. Repeat the cycle with the full team. The goal here is to identify any gaps between functions and resolve them.
  • Introduce the Experts. Let the team know how to contact the trainers, who can answer questions or offer advice at any time. Since there are a lot of changes happening simultaneously, consider embedding the experts in to the team for the duration of the change. They can provide ongoing training and reinforcement.
  • Set Up Reviews. Set up two reviews: one after a single cycle, and one after about three cycles. These are explicit times to look at the new process and answer the question, “How’s it going?” The outcome of these meetings should be any needed changes to the process, retraining, etc.
  • Communicate Externally. Since this approach results in a productivity hit, management and other external parties are going to be very interested in how it’s going — and how fast you’re going to be ready to deliver software again. Make sure you’re providing updates on the status of the process switch multiple times a week, and that you stick to the process changeover schedule.

During the Switch: Incremental

If you choose the incremental approach, the process switch will take longer but will be less disruptive to the delivery cycle. During the switchover you’ll have to do everything you would if you were taking a Big Bang approach, but you’ll do it in smaller doses. Let’s look at how.

  • Kick It Off. The formal kickoff is important for an incremental approach for the same reasons it’s important in a Big Bang approach. Be sure to discuss the schedule and reasons for the incremental approach. This will help the team understand the benefits of the new process, even though they won’t start accruing immediately.
  • Train Every Team Member. Training here will happen in bits, one process change at a time. Each process change should take an hour or less of training since it’s one change and not an entire project. Make sure that training happens for each process change.
  • Introduce the Experts. Let the team know how to contact the trainers, who can answer questions or offer advice at any time. The experts in this scenario should work closely with the business to ensure that process changes don’t get in the way of software delivery. They may recommend doing something “the old way” to meet a deadline, and work with the team to reconcile the old way and the new way during the transition.
  • Set Up Reviews. Set up period reviews, usually weekly. These are explicit times to look at the new process and answer the question, “How’s it going?” When one change is going well, then it’s time to introduce the next change. The reviews will make the readiness apparent.
  • Communicate Externally. Since this approach takes a while to implement, it’s important to keep communicating with management and other external parties. Report on how fast the process change is occurring and on the benefits of the new process as they start to accrue.

A process that provides a better way to deliver software is a great thing. Getting from old to new takes preparation and planning. Today, we’ve talked about the tactics of going from old to new. Next time, we’ll discuss getting team buy-in as we move from the old way to a better tomorrow.

Comments

  1. BY DavidEBrumbaugh says:

    Some excellent points … a problem I’ve observed, and I suspect you have to, is that a process that is too well defined becomes a goal in itself. Clearly, from your article, you know that the goal is to ship the software. However, overemphasis on process (especially by process junkies) makes the process itself the goal.

    SE processes seem tied to the maturity of the company. Most of my career, I’ve worked with start ups. In that environment, the process is “whatever it takes”. Then, when it comes time to upgrade and maintain, and add more programmers, a lightweight process is added.

    The founder then sells the company to investors or does an IPO and the people in charge now know about “business”, not about “software”. At that point, the process often becomes more important than shipping. This is where senior software engineering staff plays a critical role. They KNOW that sometimes you have to do “whatever it takes” and they also KNOW that you have to follow the process and that often those two seem to be at odds.

    This article provides a very nice framework for a senior SE to walk that tightrope in a maturing company. Well done.

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>