Baby step into Continuous Improvement

So you keep these buzz words around the water cooler huh? “Continuos Improvement”, “Continuous Delivery”,  “Kanban”, “Kaizen” and “Value Stream Mapping” but what does it all mean Basil?

Well I don’t want to dive deep into all that right now but I do want to sell you the idea of trying out Continuous Improvement, even for a week or two.

Give me one good reason you know it all schmuck!!

Improving your work flow will allow teams to deliver faster.

Simple right? It is yet so many engineering teams do not focus on this during week or sprints, it’s all features or bugs!

If the engineering team can deliver faster they will deliver features faster, hopefully meaning the faster revenue comes through the door.

But How?! I’m only a man!!

First, of you need to visual your current work flow.

  • Where does work come from?
  • When do product teams see the work?
  • When do engineers see the work?
  • How is it released?

Estimate how long it takes from one section to another and you will quickly see the pain points.

Excuse the crudity of this model


You can see here the later steps in this diagram have times indicating how long it takes to progress from one stage to the next. You can identify issues with certain areas like tickets could stay in UAT for 3 days or each release takes 40 minutes.

If we focus on the latter stat of a release taking 40 minutes, how much time is the business wasting on releases every week? If you do 10 release a week thats almost 7 hours per week!

Continuous Improvement is tweaking this development cycle in order to get work through it faster. If we want to baby step into Continuous Improvement, instead of having a team taking on 20 points of feature work per week, take on 15 points and use 5 the remaining points on something that will help speed up delivery.

Some improvements could be:

  • tweaking the build pipeline that will allow teams to release faster.
  • write a tool that will auto generate files that are needed for new pages, controller or modules.
  • Engineers having trouble with a tech stack, allow time for learning and knowledge sharing

The idea is to come back to the above diagram every few weeks, and seeing how the team can tighten those times down. Try this for a couple of weeks and see how the team does, you could save hours or even days per feature meaning the business gets to market faster, which means you can fail faster… wait what? Oh, more on that later…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s