Sunday, April 29, 2012

Making the Case for DevOps

At the ADP East conference, Jez Humble made the case for continuous delivery and DevOps.

He described a simplistic view of an organization where you’ll have a business department that comes up with a new product and hands-off requirements documents to the development department. After a couple of years, the development team finally completes the application and hands it over to the operations department so that they can provide the application to the customers.

This cycle from conception to production takes a couple of years and the success criteria are based on on time, on schedule and on budget. Very few organizations go back to analyze the total life cycle cost of the product vs. the real customer value it is generating. According to the Standish group, about 60% of features delivered end up being never or rarely used. Since the business does not have a mechanism of delivering quickly and validating their ideas through early customer feedback, they instead try to forecast and predict the future by guessing what their customers will want. And since acquiring funding is hard and in order to ensure project success, they end up cramming the requirements documents with all sorts of features that cover all imaginable scenarios. This increases scope which in turn delays the project and further lengthens the conception to production cycle.

Agile addresses this problem by focusing on delivering working software early and often and avoiding the big batch death spiral approach to software development. However, even by adopting Agile, the organization needs to align the goals of these 3 departments. The business is being measured on innovation; development is being measured on throughput while operations are being measured on stability. These are competing goals that can impede Agile adoption as departments treat each other as rivals instead of partners.

Well what if these goals where reversed? What if development is being measured on producing stable, production ready applications while operations is being measured on throughput? In my next post I’ll explore how Jez believes DevOps makes this happen by addressing culture, collaboration, automation and measurement. Stay tuned…

Adapted from  Enterprise DevOps: Breaking Down the Barriers between Development and IT Operations @ADP East 2011

Tuesday, April 24, 2012

Hard Choices - A Technical Debt Simulation

At the April DC Scrum User Group meeting, I presented the technical debt simulation game "Hard Choice". The game was developed by the Software Engineering Institute to help players understand the impacts of technical debt. Players need to balance investing effort to gain an advantage or paying a price to take shortcuts.

The game is a board game and the goal is to accumulate as many points as possible. Players accumulate points by finishing before others and by collecting tool cards. Along the way players can take shortcuts by crossing bridges. After crossing a bridge, players are penalized on each subsequent roll of the dice. To get rid of the penalty, players need to skip a turn. The games generated a lot of good discussion afterwards. Some of the comments were:

1. Taking debt late was better than taking it on early. But it got worse in the second round.
2. Not all debt was the same. Some bridges were better shortcuts than others
3. Knowing were others were on the board impacted the decision of whether to take a short cut or not
4. After taking a couple of short cuts we were barely moving
5. Not taking shortcuts made me loose!
6. I finished 1st but did not win

Overall, the game was fun and well designed. The discussion afterwards was very insightful.