Archives For Scaled Agile

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.