Continuous Delivery | LeanOrange

Archives For Continuous Delivery

Hypothesis Driven Development(HDD)

February 8, 2013 — Leave a comment

We came across this picture while writing the Agile C’MON Man post. The irrational exuberance in this picture gave us a chuckle, but it also reminds us of an engineering group driving product development. As we articulated in the previous post, engineering driven product development can lead to BUFD. At the same time, we articulated the lack of business driven product development is due to ill equipped product management. In this post we will lay out a high level business approach to product development.

We think this is the new frontier for Agile and software development. The Lean Startup and David Joyce’s talk, 21st Century Portfolio Management, are great resources to start shaping how we need to think about driving product development. The fundamental principle that these two resources drive home is learning. Our ability to deliver higher value products hinges on our ability to learn. These resources also champion the fact that learning on the business side does not end after a business case has been delivered, nor after requirements captured, nor after a team has showcased working software at a demo. No, learning needs to happen with real customers. Therefore, we need to consider how we are going to learn throughout the whole lifecycle, including customer consumption.

Learning_Adoption Learning is not a new concept, especially when we talk about feedback loops in SDLC’s. However, the difference here is the measured approach to learning. We should not just ask what should be built, but why it should be built. Therefore, we should wrap measurements by which value returned can be measured and validated. It is this process of being intentional about quantifying results based on predetermined measures that helps accelerate learning. Documenting measures that align to our assumptions, force us to gain a deeper understanding of why our customers want what they want.

Experiments – You may have heard these forward leaning thinkers refer to this process as “running experiments.” At face value, this conjures up thoughts of lab rooms and scientists, but we’re doing software development…right? Well think about it. If we’re making assumptions and documenting what to measure after a capability has been delivered, it’s safe to say that this sounds like a hypothesis. If we build out that hypothesis and then measure the results, we essentially are running an experiment So it’s not that crazy after all.

Recently, a new “xDD” (x Driven Development) has hit the radar. Hypothesis Driven Development(HDD). Its so new, that there isn’t even a Wiki page for it! Mind blowing…I know! Whether you call it HDD, Lean Startup, 21st Centrury Portfolio Managment, or whatever, we think this is an area business product developers can gravitate towards to build better products. If you have thoughts to share on this topic, we’d love to learn with you! Please comment or DM us to continue the conversation.

In Business Driven, Continuous Delivery, Delivering Software, Lean Agile

The Death Spiral explained – Lean Laundry

January 10, 2013 — Leave a comment

LaundryPile A funny thing happened while I was writing our previous blog on Lean Laundry. I realized that my wife and I’s laundry mismanagement put us in death spiral mode. “Death spiral” mode is a common phenomena in software development that leads to the demise and failure of software projects. It is specifically prevalent on large scale software development efforts.

If it hurts…do it more often!

This is a principle in the Continuous Delivery book. Basically, if delivering software is hard, do it more often…not less often. Over time delivery events will become routine.

My wife and I were doing the exact opposite. Doing laundry had turned into a weekend long event. I kid you not. We have literally done 10-12 loads of laundry over a weekend. Because this sucked up so much energy and time, it drove some wonky behavior. You would think we would be more motivated to do laundry more often to keep up with the demand. However, it was quite the opposite. Sounds like software projects…eh? 😉

Laundry death spiral

The pain of doing laundry drove us to add buffer capacity in the form of an extra laundry basket. However it was only a matter of time before this overflowed and we were right back where we started, only worse. We were in the death spiral!

Bigger piles of laundry were leading to bigger piles of laundry and laundry inventory was everywhere. Piles of folded clothes could be found in random places from the last big batch of laundry. The worst of all was that the number of unmatched socks constantly floated around 25-30 pairs. This necessitated the need for a dedicated unmatched sock sorting bag to collect the large inventory of sock “defects.” Sound like a defect backlog? 😉

Software death spiral

While our personal laundry death spiral is a bit comical, it is a microcosm of software development projects. However, building software is exponentially more complex and can snowball out of control if not dealt with! The software death spiral goes as follows:

Software features, like laundry, begin to pile up for one reason or another
Deploying them becomes more complex and painful leading to more infrequent deliveries.
Infrequent deliveries lead to bigger releases.
Customers begin to stuff more features per release knowing that it will be longer to realize value. Releases get bigger.
Scope creep occurs with last second customer requests. Customers know if they don’t push for it, they will have to wait for the next big release to come around.
IT adds buffers and resources to manage the side effects of big release SDLC’s.
- Defect backlog(s) – think unmatched socks
- Organize functionally to gain functional efficiency for big batch processing
- Heavy weight vetting and requirements processes to manage those *pesky* customers
This continues until that vast majority of development work are defect backlog items
Customer(s) finds a different IT provider

Solution

Just like the solution to our laundry death spiral, the solution to software death spirals lies in Lean thinking. Shallow, uncommitted backlogs and frequent deliveries are two practices that will drive a ton of positive behavior momentum. With enough momentum you can reverse a the death spiral.

Shallow backlogs

Laundry – Use small laundry baskets equal to washing machine capacity.
Software – Keep product backlogs shallow and uncommitted. This maximizes flexibility and decreases wait times. Afterall, committed backlogs are just queues!

Frequent Deliveries

Laundry – Wash laundry when one of the small basket fills up.
Software – Deliver to production when a small batch of work has been completed. End of sprint delivery is a good goal. After that, check out Continuous Delivery principles and practices to enable smaller releases.

In Continuous Delivery, Lean

Delivery as a Service (DaaS)

November 9, 2012 — Leave a comment

How many times has your team spent time futzing with build scripts and managing test environments or monitoring systems? This is a reality for development shops today. While this activity is absolutely essential to maintain stable assets, it does not scale well. As large organizations continue to demand more software solutions, we must think of different ways to manage, build, and deliver our assets. 20 different teams tinkering with Jenkins could get ugly fast. Not to mention the backlash effect of instituting a Jenkins change control board(JCCB)! 😉

What if scaled application developers didn’t have to worry with this headache? What if they just plugged their code and tests in and voilà…it works? 😀

Well, drum roll…ladies and gentlemen, I introduce to you Delivery as a Service(DaaS). DaaS represents the ops interface that developers interact with. This allows developers to remove themselves from the mundane tasks associated with building and maintaining a delivery architecture. Modern tooling, Lean Agile thinking, and mature engineering practices have made this possible.

DaaS is made possible by the thinking behind Continuous Delivery. Jez Humble and David Farley wrote a fantastic book in 2010, called Continuous Delivery, that outlined how to build more reliable systems by potentially delivering every application change to production fast, really fast. The success and maturation of Continuous Delivery systems is changing the mindset of traditional development. Companies such as Etsy, Netflix, and Flickr are pioneering the engineering practices required to build and deploy at scale.

With the help of these innovators and the work of the Scaled Agile community, we’re making sense of developing and delivering at scale. The Scaled Agile Framework calls out a program level team that would provide DaaS called the System Team. We think that a lot of innovation will occur at this level within SAFe over the next two years. If anyone has any experience with Continuous Delivery/Deployment at scale, we’d love to collaborate.

It’s an exciting time to be pushing code!

In Continuous Delivery, Delivering Software, Enterprise Agility, Scaled Agile

Selling Continuous Delivery

September 10, 2012 — Leave a comment

Whenever I have introduced the idea of Continuous Delivery to IT organizations, I usually get mixed reactions. The developers are excited, ops are skeptical, and PM’s usually look at me like I have a thumb sticking out of my forehead. For some reason the idea of potentially shipping software at any moment is too extreme for those that manage software products.

However I think one of the biggest values continuous delivery systems buy organizations is the constant production readiness of your application. Regardless of whether you hit the deploy button or not, having confidence that your application is in a production ready state at all times should be a huge comfort factor for everyone in the organization.

I think those that are resistant to continuous delivery systems most likely focus too much on the delivery part of continuous delivery and not enough to the underlying engineering practices needed to make it a reality. These practices are what brings a tremendous amount of stability and predictability to your release process. If we deliver the message from that standpoint, we are more likely to get buy in from those that are tend to be adverse to change.

In Continuous Delivery, Culture, Technical Agility

Enterprise Alignment

August 30, 2012 — Leave a comment

Alignment

In our consulting experience we have found many clients are excited to drink the Agile “kool-aid’ but for one reason or another fall short of a successful transition. There are many reasons failed transitions but one pattern that we have observed is a lack of “Enterprise Alignment.” So what do we mean by “Enterprise Alignment.”

An organization’s Enterprise Alignment is wrapped around three areas: technical architecture, business process, and culture. We have found that change initiatives fail when these three areas do not map to the overall goal of an Agile transformation.

For example, if an organization’s Agile transformation goal is to deliver business value fast, then all three Enterprise Alignment areas should align to that goal. Perhaps the technical delivery architecture take on continuous delivery characteristics, the business process would be focused on the flow of business priorities, and the culture would reflect a disciplined focus on shipping software.

Organizations fall short when they partially align themselves around these goals. They may have the technical architecture in place to enable fast delivery of software but are still operating on quarterly release schedules. Conversely the business process may be flowing the highest priority MMF’s or MVP’s to the development teams but the technical delivery approach is geared towards releasing batches of features through manual, late night deployments. Finally organizations may have the technical architecture and business process in place to flow features to production but lack the cultural discipline and collective ownership needed to consistently ship high quality software to production.

When considering an Agile transformation ask yourself, does my organization have the executive tolerance, courage, and leadership necessary to align the technical architecture, business process, and culture around the Agile transformation goal?