Enterprise Agile Development and DevOps Cause Major Upheavals
The concept of DevOps is gaining traction within the IT departments of many companies. What is DevOps? It’s the idea of a cross-functional team composed of people from development and operations. The team develops the software and support the resulting software application and associated infrastructure.
The DevOps approach is popular with companies offering cloud-based software. These firms usually perform frequent software updates and need to have development and operations closely aligned. Even simple software defect repairs need to be deployed according to an agreed-upon plan and timeframe.
DevOps also helps when you have a complex platform built on many software components, either custom built or off-the-shelf. When you have web servers, application servers, databases and other supporting software components, there will be many software update cycles to manage.
DevOps is just the beginning.
The enterprise agility problem extends beyond development and operations. What about program management, user experience, product management, quality engineering, software distribution, user documentation, and customer support? It takes many people with many skills to launch and maintain enterprise software.
There are organizational and cultural barriers to implementing enterprise DevOps or any form of enterprise agile development. If you’re serious about being agile, you’ll have to face them.
Corporations have spent years refining their command-and-control structures. Agile development and delivery is different. All that existing structure won’t have to be tossed but it will need a major overhaul.
I wrote an article for the ToolsJournal called “10 Tips for Succeeding with Enterprise Agile Development” In a series of posts over the next few weeks, I’ll expand on the ideas presented there.
Enterprise agile development, including DevOps, will cause lots of upheaval. Most companies seem to attack it in a piecemeal fashion hoping that many small changes will get them to where they want to be. It won’t work. I hope this series of posts helps.
1 Comment
Leave a comment
Intro
Recent Posts
Categories
Archives
- June 2013 (7)
- May 2013 (13)
- April 2013 (13)
- March 2013 (13)
- February 2013 (12)
- January 2013 (12)
- December 2012 (7)
- November 2012 (11)
- October 2012 (12)
- September 2012 (8)
- August 2012 (11)
- July 2012 (13)
- June 2012 (12)
- May 2012 (13)
- April 2012 (13)
- March 2012 (13)
- February 2012 (12)
- January 2012 (13)
- December 2011 (12)
- November 2011 (12)
- October 2011 (13)
- September 2011 (14)
- August 2011 (18)
- July 2011 (13)
- June 2011 (18)
- May 2011 (19)
- April 2011 (16)
- March 2011 (21)
- February 2011 (20)
- January 2011 (22)
- December 2010 (21)
- November 2010 (16)
- July 2010 (2)






+1 to “DevOps is just the beginning”. I’ve been using the term “User-Centered IT” to refer to alignment across marketing, design, dev, qa, ops, and support. The point is to get all parts of the org and all activities working in concert with each other and thinking in user-centered terms (e.g., whether the servers are up or not, is the site working the way the user expects). Techniques like service design and behavior-driven development can create shared understanding of who the user is and what they need/want/expect.