“Sorry mate, I have to cancel my ticket to the game on this Saturday I have to work”
One Week Later…
“Oops! I cannot be available this weekend too as something has come up at work”
This is pretty much the case of most development teams when they are closer to the release, and they often end up working extra hours, in the evenings, and over the weekends. Usually, the defect fixing cycle has no time boundaries when it comes to any major release, the developers along with the project management team work until the eleventh hour to ensure all the release blockers are fixed to bring down the defect count, or at least have good workarounds to not block the release.
It's not enough if we have the fix just working in a developer environment, this had to be tested integrating it with the whole product and ensure that the fix doesn’t add additional problem or more cost. There will be a huge demand for test servers to test these fixed patches, once verified they must go through the queue which has many fixes lined up and then patiently the fix waits for its turn. Of course, this also involves constant apprehension that the build might fail/break anytime if the previously applied fix was incompatible with the fix that has been just merged to the master branch, or because of parallel workload which doesn’t quite match the needed KPI. After having gone through this dilemma, well let’s say that our prayers get answered, and the master build somehow held its ground: maybe because of the good troubleshooters in the build team who are also working with us inadvertently hoping not to see any more problems and to call it a day.
Having gone through this ordeal multiple times during my stint as a designer and as a manager, obviously, I was looking for a panacea or at least a reasonable solution to help us through this situation in the next release. Firstly let's define what is certain in any software release, and what are the things that are beyond a specific designer or a specific team’s control. There are certain things that must be assumed when it comes to a software release.
- The defects and the last-minute fixes are an inseparable part of the release cycle, there is no escaping that. This is mainly for the fact that in an agile development framework we focus on incremental development and don’t stop working after completion of a certain phase or a sprint(like we do in the waterfall approach). There is always continuous development.
- Can we begin early to finish on time? We cannot always assume that we can start the development cycle early to enable us to have sufficient bandwidth for testing and fixing defects, because the requirements in most cases become clearer mostly after the development teams start their sprint cycle i.e. take in that requirement and perform a few spikes/Proof of concepts to evaluate the possibility of the requirement/tools/architecture/design approach.
- Can we optimize the requirements better to scope in only what is needed? Because of the scope changes during the development cycle, it is imperative that the development cycle extends, as a result of the verification team consuming this developed product for further testing also gets delayed.
- So can we optimize the process that is being followed to gain maximum value and do not have so many pending must-do tasks- integration, testing, massive code-merge, queueing up, build up to the last minutes?
The answer is YES!
Value stream mapping (or VSM in short) can definitely help here.
What is Value stream mapping?
VSM is a lean management activity to enable efficiency in the process. It provides us a framework to identify the tasks/steps in a process considering an end to end flow, differentiate the value-add and the non-value add steps in the process, challenges us to eliminate the steps that do not add value which can be considered waste in an effort to increase the frequency of doing the value-add steps more, and helps us to eliminate waste completely. This will drive process improvements with an end goal of an efficient business and a delighted customer (as the customer will only pay for the value they receive, and not the waste)
I will try to outline what has worked well for me and for a few teams that have gone through value stream mapping activity.
Who should be present for VSM?
This depends on the process we are trying to improve. If the process falls into the remits of a team, then the team members and the representation from the organization that impact the team (for instance, if there is a separate testing team, build the team a representative from each of these teams should be present) and a facilitator should be present. If the process under discussion impacts a lot of teams, then we need stakeholders from each team and a facilitator to run the VSM activity.
How is the VSM activity run
A) Typically, the team maps the current state of the process including the time taken for each step. We should have the right data and we need to know the current flow of data and the information. This is to help us define the boundaries of the current process. It is useful to have the timelines across each step as we are defining the steps.
Let us consider an example where we are starting the sprint to implement a user story taking 6 steps. And eventually discover halfway through the user-story implementation that a fix is needed by another Team Y which leads to wait time.
B) The next step is to detail the steps in the wanted state or the future state. This should be done independent of the current state map, with the view of how the process should work and not how the management or project managers or some other stakeholders plan for this. Again it is useful to indicate the timelines as we are outlining the steps based on the accurate facts/data we already have.
C) These two steps above will give an indication of where we are, relative to where we should be in terms of the process and time.
D) The next step is to identify the parts in the process that give value and the parts that do not give value. This is the most important step where we measure and analyze the steps that add value and the steps that do not. (Please refer to Fig. 3)
I have step 2 as non-value because of the halfway implementing the story and by the time we get back, there is a lot of context switching involved which is considered waste.
- Now, we should be looking at how to optimize the process by eliminating the non-value steps, if not at least reducing them (Especially steps 2 and 3). To do that we need to list the challenges that are preventing us from doing it in the first place, and what are the improvements that can be done to eliminate these challenges. The nan- value steps may be added to the current process due to:
- insufficient tooling or
- lack of standardized 3PPs,
- lack of teams,
- lack of automation,
- lack of bandwidth,
- accumulation of technical debt or
- the lack of a streamlined process
- lack of governance model
- lack of communication
- lack of overseeing the entire flow
- too many communication channels
- delays in the steps
- unnecessary constraints in the process/ way of working
- lack of quality in development which leads to too many defects
- lack of awareness
So once this is visualized it becomes clear to everyone involved on the time and the effort that goes underutilized or wasted and gives a black and white picture to all stakeholders on what should be done.
The Visualization helps in focussing our attention to the amount of time that is spent waiting or wasted and gives it a quantitative measure, rather than an estimate.
In our example, Fig.3, clearly shows (in red) that 1 week and 4 days is wasted and can be gained back, this can be done by embedding Backlog grooming or story analysis in the team’s way of working. By doing so, we will come closer to the Future state as depicted in Fig.2
How long is the VSM?
VSM best works if it is a time-boxed exercise so that we can focus on the stipulated time and expect to see what we can improve at the end of the stipulated time. I recommend time-boxing in 3-hour interval.
If the given time is not enough, we should be thinking to split the process and fragment it, and take a part of this process and work through this.
What do we gain out of VSM?
VSM is a lean management technique which leads to improvement in the existing process and eliminates waste completely or to a great extent. This process helps to optimize the time and effort by getting rid of non-value items, this is complementary to optimizing the steps that add value. VSM might lead to different flow too if the current flow of data proves to accumulate a lot of waste. We cannot completely reap the full benefits of VSM if we do it as a once off activity, there is a need for continuous inspect and adapt approaches here. Finally, VSM is all about introspection and how we respond to it, in order to measure and analyze and improve the process to gain maximum yield.
When can we see benefits following VSM?
We need at least 3 iterations of VSM activities to get rid of inefficiencies in any process. We do VSM once, implement the actions, then we do VSM again, implement any follow-ups and again do VSM, see if there are any improvements that can be spotted and act on them.
In the current example, the next step is to reduce the time taken to release the software built. Currently, it is taking 3 hours, so I would challenge the team to reduce it and go about Value stream mapping that process and eventually come down to a smaller release time.
It is important to list down the improvements that we plan to do after each VSM and continuously check the fulfillment of our goal, and again do the VSM, list the improvements check them, so this pretty much should become an iterative approach in a retrospective mode.
What are the use-cases that can be made efficient via VSM?
I have taken an example of a user-story implementation, but pretty much we can apply VSM to any activity in the CI development process or to any phase between the conception of the product till the time it reaches customer, or from conception to delivery in its entirety, this can even be applied to any aspect in the lifestyle that we want to harvest better.