DevOps - achieving end-to-end agility

DevOps – achieving end-to-end agility

DevOps is a new buzz word around IT and businesses that have or are embracing agile software development. I’ve been doing DevOps since way before it was ever called DevOps, so let’s talk a bit about why this is such a hot topic now.

I believe there is one primary driver to all the hype and attention that DevOps is getting: pressure to shorten release cycles.  There are other considerations and reasons for taking on a DevOps initiative but getting products and updates released faster is a big win for most organizations.  Here is why shorter release cycles matter.

·      Time to market – the sooner we get something in the hands of our customer, the sooner we generate revenue and test the market

·      Reduced risk - frequent, smaller releases are less risky because there are less changes to the code and quality is easier to control

·      Reduced cost – less friction between development and operations leads to greater efficiency

·      Customer satisfaction – shorter feedback loops allows for new features to be more in tune with what customers want

·      Increase market share – there is competitive advantage in being able to release features faster than your competition

Sign me up! Why isn’t everybody focusing on this?  Because, like most things that sound so great, they can be very difficult to achieve.  Moving from releasing software every 6 – 12 months to releasing software weekly, daily or even multiple times a day, is a huge shift and requires significant organizational changes, new tools and processes, and cooperation/collaboration from lots of folks who may not have worked all that closely before.

I find the attention on DevOps fascinating because I come from an IT Operations background.  I came up through the ranks as a System Admin/Engineer/Architect and then Manager.  I was a gatekeeper for software development teams and was responsible to make sure they didn’t release software that would either kill the infrastructure (crash the servers), or cause some horrible security risk that put valuable, confidential information at risk of being stolen or corrupted.  I was viewed as the speedbump on the information superhighway because I had all my checklists and validation steps and rollback plans and disaster recovery considerations. They pretty much hated me.

About 10 years ago, I switched teams.  I moved into software development, making video games for EA Sports.  After all of the years of trying to get developers to consult with me early and often so we could anticipate what they were doing and be ready to launch when they were ready to launch, now I was on the other side and knew how to collaborate with Operations. Did this magically solve all the problems and smooth the way to quick and stable releases on shortened cycles?  Hell no. I was just one guy trying to get lots of other people to play nice together. There were years of distrust, disrespect and policies and processes in place that made the relationship between Development and Operations difficult.

So, if this rocky relationship between Development and Operations has been a pain point for decades, why is it now the focus of such attention?  Because the motivation is much greater (see my list of benefits above), the tools have improved dramatically, and there are plenty of organizations that have proved it can be done.  DevOps will quickly move from being a competitive advantage for those that achieve it to a competitive disadvantage for those that don’t.  It is that simple.

I’m reminded of an old saying.  “There are those who make things happen, those that watch things happen, and those that wonder what happened. Who will you be?” DevOps is one of these opportunities.  You need to make things happen and it isn’t easy so you better get started.

My first piece of advice on getting started with DevOps is to begin with the understanding that the solutions are mostly about people.  You need to get people working together from multiple disciplines. If there is distrust or disrespect between groups you must solve that before you can solve anything else.  You need senior level sponsorship so all involved understand the desired outcomes and their importance to the organization. Of course, you need to understand the challenges within your organization because every organization is unique and no consultant, not even me, can come in and tell you what to do.  A good consult, should be able to jump in, roll up their sleeves and work with you get the wheels in motion.  There’s probably some “low hanging fruit” around test automation, and improving tools and processes for continuous integration, build and release management, configuration management, etc. Get some early wins so people see progress and gain confidence in the plan and achievability of the goals.

Now, go start your DevOps initiative, and may the force be with you!

Agile - Responding to Change

Agile – Responding to Change

This is part 4 of 4 of my continuing series that looks at each of the high-level principles from the Agile Manifesto, today we tackle the concept of responding to change over following a plan. My position on this may be a bit outside the purist agile teachings. I like plans and predictability and I don’t think they are necessarily in conflict with agile software development or organizational agility.  Keep reading and I’ll explain why I say this.

I’ll use video game development as an example of why planning and plans can be important.

If you want to launch a game and generate significant revenue and profit you cannot do so without a great game but you also need considerable business savvy, excellent timing, great marketing, and a bit of luck.  You need to plan, execute against that plan, and adjust to shifting market factors and consumer sentiment during development.  That’s right. You have to “respond to change”.

See how I did that?  I took business planning, which might seem to be the polar opposite to agile development and connected it back to the principles from the Agile Manifesto.  The trick is to do enough planning to make sure people are working on the right activities in the right timing and sequence. At the same time, we need to be constantly reviewing our assumptions, testing our theories, listening to stakeholder feedback, and be willing to change the plan when new information reveals that a new direction or strategy is needed.

That said, don’t give up the dream. If you have built your team, and your plan, around a grand vision for something huge and world changing, do everything you can to protect that goal. You may have to take a different path to get there than the path you initially started with but keep the dream alive.  I’ve seen great game concepts get so watered down in compromises during development, often caused by trying to stick to the business or marketing plan, that the game released was nothing close to the vision that all involved were so excited about in the beginning.  That is what can happen when you choose to follow the plan rather than responding to change. 

Now I want to also talk a bit about predictability.  Deciding to build a product requires an investment.  Business leaders don’t like to make investments without some predictable profit (return on investment – ROI). Predictability is about our ability to predict something in the future – a product launch that results in some tangible value returned to the business.

We make predictions all the time. We predict the weather and make decisions about whether to where a jacket or take an umbrella when we go out.  Our confidence in the weather forecast for today is directly proportional to our confidence in the measures and interpretations of those measures that the local meteorologist has made.  We may even look at a 5 or 10-day forecast and make some decisions about activities we want to plan on the coming weekend. Failing to respond to change would be not checking the daily forecast as that outdoor activity gets closer and adjusting the plan if the weather forecast has changed.

So, we want predictability for our long-term weather forecasts but we know we have to monitor and adjust. There are too many variables for forecasts beyond a day or two to be reliable. Long-term business or project planning faces the same challenges.  We want to be able to predict the future, but when we are honest with ourselves, we know that things change so fast that we must constantly be vigilant and check to see what has changed. Like the meteorologists, we must have metrics.  We must understand our customers, the market, the product we are developing, the health and productivity of the team, our operational capacity to launch and support our products, and the financial health of our business.  All of these measures help drive confidence in our predictions for what will happen next week, or next month, or next quarter.  The further out we look, the less confident we are in our ability to predict with any real accuracy what will happen.  That is why we should respond to change and not just follow the plan.

In conclusion, we’ve now covered all 4 of the principles from the Agile Manifesto.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

We’ve set the stage for more articles to talk about how we put these principles into action. In future articles, I will cover topics around Scrum, Lean, Kanban, XP, DevOps, Metrics…  Stay tuned and please share or comment.  Feedback is appreciated.