Beyond the continuous delivery

Recently I was sharing my vision of modern software engineering with new colleagues, what triggered me to look at the last couple of years of my software engineering experience. I went through past projects and teams and got a list of practices that I found interesting to observe. So, here is the list:

• Continuous usability;
• Continuous architecture;
• Continuous testing;
• Continuous improvement;
• The experiment based development from The Lean Startup of Eric Ries.

Some names are just working titles and deserve some explanation, and I promise to follow up with future posts to explain them. You probably noticed that most of them have a word continuous. Why is that? Here I have to make a short step aside.

I’ve started as a software engineer in 90th. Software systems were a bit different back then. Most software products were developed and deployed as a single package. Hardware and operating systems were much more straightforward. The waterfall process was a perfect fit. Then something happened, and we’ve got RUP, Prince, etc. Those are far more complex, although they were designed to solve the growing complexity with the same core as the waterfall process.

Technologies have made a massive leap from that time and we try to handle them with tools developed a long time ago. Just think about it. Scrum introduced two decades ago. The agile manifesto was born in 2001. Of course, agile methodologies have helped many teams to level up, but they based on ideas from the last century. They fail at scale. Now we see next generation frameworks like SAFe and LeSS. Do you see a pattern here? So I keep searching for missing pieces. I want to keep up with the new situation in software development, and this is why the word “continuous” pops up more and more.

In the year 2012, Joel Spolsky posted about Software Inventory. He says that any work in progress has the same nature as physical inventory. It has to be stored, tracked and maintained. Software inventory has a considerable cost, and this is not something new for those who are familiar with the Toyota Production System. They call it Just-In-Time (JIT). Then why not to apply JIT for software development? Rephrased for software engineering, it would sound like “Let’s be pragmatic and do work exactly when it’s necessary”. Isn’t it what we call “continuous” in regards to continuous integration/deployment/delivery?

However, there is a big challenge in making the whole software development process “continuous”. It’s hard to say how many “spare-parts” we need in each concrete case and there are many aspects to consider like requirements, architecture, coding, testing, security, deployments, operations, usability, design. There are more challenges like planning, organizing, steering, and other management activities. Even when all those questions answered then how about reality? It’s not so often we have a chance to start fresh. What usually happens is that we have to work with what we have, reach goals, make progress.

Then why am I talking about this if the goal looks so unreachable? I saw how agile movement has been transforming the software development industry in the last two decades. We have The Principles of Product Development Flow book from Donald Reinertsen and Heart of Agile approach from Alistair Cockburn. I believe that in the upcoming years we will develop all the necessary practices to answer those questions. As a small contribution to this process, I share practices discovered and applied by teams I had a pleasure working with.

With my next post, I will focus on collaboration. With all complexity of software development processes, making it continuous increases the need for cooperation, collective decision making, and access to information. With the practices mentioned above, I’ve developed an approach that can be applied to disciplines like usability, architecture, testing, and security. This approach enables teams to utilize knowledge and experience of all interested parties. I call this approach “Open Contribution”.

For the time being, you could think about what part of your software inventory is easy to eliminate. Be it backlog items for future sprints, code changes that stretch your quality engineers or architectural decisions which could be postponed. Where do you see a quick win?

References:

• Eric Ries, The Lean Startup (book)
• Joel Spolsky, Software Inventory (blog post)
• Donald Reinertsen, The Principles of Product Development Flow (book)
• Alistair Cockburn, Heart of Agile (website)
• Just-In-Time: Toyota Production System Guide (blog post)

Continue with “Open contribution, or how to make decisions together”