Archives For Enterprise Agility

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!

Scaled Agile Framework

October 28, 2012 — Leave a comment

big picture

Last week we attended the Implementing Scaled Agile Framework (SAFe) course in Chicago. It was a power-packed four day course that covered the issues involved when scaling organizations to deliver software.  In our humble opinion, it was the most comprehensive and practical course we have taken to date.  While the course is still a beta course, it is chalk full of real world results and techniques that anyone working in large scale product development can take home and apply immediately.

One of the “ah ha” moments for us was when we discovered the practical application of Lean principles throughout SAFe.  Sometimes principles are hard to understand without applying them to a real context.  For instance, the instructors stated that SAFe is an instance of Lean just as Scrum is an instance of Lean.  Much of SAFe is based on Don Reinertsen’s book, Principles of Product Development Flow.  If you have ever read or tried to read his book(a more likely statement) you know that its a book of principles.  Because of this, it is sometimes hard to gather a deep understanding of the principles.  Dean Leffingwell has done a tremendous job making these principles real in SAFe.  Connecting economic and variation exploitation principles to SAFe helped us understand Reinertsen’s book.

Its also important to note that Dean and company have truly built a framework, not a methodology, based on those that have gone before us.  As Dean stated many times, we’re standing on the shoulders of those who have gone before us.  The framework will be criticized, and it should be.  Healthy debate is good for the progression of ideas.  However, after spending four days understanding the principles and practices of SAFe, I would suggest critics understand the principles and practices involved with the framework before ridiculing it.

SAFe confronts the brutal facts that scaling software agility is hard, really hard!  We can’t use the same practices at the team level and apply them to all areas of the enterprise and expect the same results.  Our industry’s current history has proven that this will not work.  It’s time to open our minds again, and stand on the shoulders of those that have gone before us.

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?