Culture | LeanOrange

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?

In Continuous Delivery, Culture, Delivering Software, Enterprise Agility, Technical Agility Enterprise Agility, Enterprise Alignment, Scaled Agile

Don’t sub-prime your project

July 20, 2012 — Leave a comment

Recently, a client ran into a roadblock…a major roadblock! For several months I had petitioned and warned leadership that investing the right talent to deliver results was putting the project at risk. However, no action was taken.

Essentially leadership took out a one year ARM hoping that they could deliver before the interest rate reset…i.e. team members to be repurposed towards other portfolio priorities. However, with the lack of the right talent the project made little progress. Month after month, the talent deficit accumulated into real project debt – software architecture, engineering disciplines, and team morale suffered tremendously.

Now management and the business are expecting the payment to come due(delivery). However they sub-primed the the project. With the expected due date coming up we’ll either need to refinance the project(add more time and/or resources) or foreclose.

So what? Irregardless of your process(Agile or not), when bootstrapping your projects, set your projects up for success. Put a solid down payment down to invest in realizing the project vision. Also, throughout the project lifecycle, actively engage the business and IT management…i.e. the decision makers. Transparency and active participation from stakeholders are key to Agile project success. Use this case study as an example where consistently disengaged decision makers caused project failure because they were unwilling to have the courage to make tough choices when the clear path to success was staring them in the face.

Reminds me of this sad Agile PM video: goo.gl/jYSWB

In Culture, Delivering Software