The Agile Executive

Making Agile Work

Posts Tagged ‘Web Operations

Extending the Scope of The Agile Executive

leave a comment »

For the past 18 months Michael Cote and I focused The Agile Executive on software methods, processes and governance. Occasional posts on cloud computing and devops have been supplementary in nature. Structural changes in the industry have generally been left to be covered by other blogs (e.g.  Cote’s Redmonk blog).

We have recently reached the conclusion that The Agile Executive needs to cover structural changes in order to give a forward-looking view to its readers. Two reasons drove us to this conclusion:

  • The rise of software testing as a service. The importance of this trend was summarized in Israel’s recent Cutter blog post “Changing Playing Fields“:

Consider companies like BrowserMob (acquired earlier this month by NeuStar), Feedback Army,  Mob4Hire,  uTest (partnered with SOASTA a few months ago), XBOSoft and others. These companies combine web and cloud economics with the effectiveness and efficiency of crowdsourcing. By so doing, they change the playing fields of software delivery…

  • The rise of devops. The line between dev and ops, or at least between dev and web ops, is becoming fuzzier and fuzzier.

As monolithic software development and delivery processes get deconstructed, the structural changes affect methods, processes and governance alike. Hence, discussion of Agile topics in this blog will not be complete without devoting a certain amount of “real estate” to these two changes (software testing as a service and devops) and others that are no doubt forthcoming. For example, it is a small step from testing as a service to development as a service in the true sense of the word – through crowdsourcing, not through outsourcing.

I asked a few friends to help me cover forthcoming structural changes that are relevant to Agile. Their thoughts will be captured through either guest posts or interviews. In these posts/interviews we will explore topics for their own sake. We will connect the dots back to Agile by referencing these posts/interviews in the various posts devoted to Agile. Needless to say, Agile posts will continue to constitute the vast majority of posts in this blog.

We will start the next week with a guest post by Peter McGarahan and an interview with Annie Shum. Stay tuned…

Advertisements

Velocity 2010 – Where Have All The Business Executives Gone?

leave a comment »

velocity2009_logo

By now I have “touched” and been touched by dozens and dozens of participants in the O’Reilly Velocity conference. I did not meet any business executive (other than various CEOs/CMOs who pitched their companies from the podium).

No doubt, the O’Reilly Velocity conferences (this is the third one) are geek events. Having said that, IMHO these conferences are extremely important to the business executive. If you don’t attend you miss up on four value propositions:

  • Getting a sense of what the future in web operation holds.
  • Grasping what forthcoming advances in web operations mean to your business design. See for example my post Ops Driven Dev from earlier today.
  • Understanding the needs of a growing demographic sector that your business might not be able to access today.
  • Getting to know the kind of developers and sysadmins that probably work in the trenches of your company.

You owe it to yourself to consider attending Velocity 2011 if terms like “sysadmin 2.0”, “darkmode” and “devops” and do not resonate with you. I can’t give you “your money back” guarantee if you are not satisfied with the conference, but I will gladly pick the bar tab when we meet there.

Written by israelgat

June 24, 2010 at 3:02 pm

Ops Driven Dev

with 6 comments

In The Agile Flywheel, colleague Ray Riescher describes how velocity in dev drove corresponding velocity in ops:

Scrum set the flywheel in motion and caused the rest of the IT process life cycle to respond.  ITIL’s processes still form the solid core of service support and we’ve improved the processes’ capability to handle intense work velocity. The organization adapted by developing unprecedented speed in the ability to deliver production fixes and to solve root cause problems with agility.

From what I gleaned yesterday in the O’Reilly Velocity conference I believe the tables are turning. Ops, or at least web ops, will soon drive development.

The reason for my saying so is quite simple: the breadth and depth of forthcoming web analytics unveiled in the conference. This is not “just” about Google making website performance part of their ranking algorithm. Everything related to web performance will soon be analyzed mercilessly under the “make the web faster” mantra. Dev will need to respond to analytics from operations with an unprecedented speed. For most practical purposes analytics run in ops will dictate the speed for dev.

The phenomenon actually goes beyond performance aspects. To be able to implement changes quickly, dev will need to be very good in ensuring the quality of fast changes. While quality has many dimensions to it, the most applicable one is test coverage. There is no way to change the code quickly without a comprehensive automated test suite.

The first step toward dev meeting the required speed is described in the post How to Initiate a Devops Project:

For a devops project, start by establishing the technical debt of the software to be released to operations. By so doing you build the foundations for collaboration between development and operations through shared data. In the devops context, the technical debt data form the basis for the creation and grooming of  a unified backlog which includes various user stories from operations.

I would actually go one step further and suggest including technical debt criteria in the release process. The code is not accepted unless the technical debt per line of code is below a certain pre-set level such as $2. The criteria, of course, can be refined to include specific criteria for the various components of technical debt such as coverage, complexity or duplication. For example, unit test coverage in excess of 70% could be established as a technical debt criterion.

Once such release criteria are established, the metaphorical flywheel starts turning in an opposite direction to that described in The Agile Flywheel. With technical debt criteria embedded in the release process, the most straightforward way for dev to meet these criteria is to use the very same criteria as integral part of the build process. The scheme for so doing in given in the following chart:

One last recommendation: don’t wait till Velocity 2011 to start on the path described above. Velocity 2010 already provides plenty of actionable insights to warrant starting now. Just take a look at the web site.

Written by israelgat

June 24, 2010 at 7:55 am

An Update on Agile Business Service Management

leave a comment »

A previous post in this blog defined the demarcation line between The Agile Executive and BSM Review as follows:

If software development is your primary interest, you might find my forthcoming posts in BSM Review go a little beyond the traditional scope of software methods. If, however, you are interested in software delivery in entirety, you are likely to find good synergy between the topics I will address in BSM Review and those I will continue to bring up in The Agile Executive. Either way, I trust my posts and Cote’s will be of on-going interest to you.

Since writing these words, I realized how tricky it is to adhere to this differentiation. The difficulty lies in the “cord” between development and operations. Development needs to devise algorithms that take into account operational characteristics in IT. Operations needs to comprehend the limits of such algorithms in the context of the service level agreements and operational level agreements that had been negotiated with their customers (either external or internal). The mutual need is particularly strong in the web application/web operations domain where mutual understanding, collaborative work and joint commitment often need to transcend organizational lines.

Given the inherently close ties between development and operations, here are some BSM Review articles and posts that are likely to be of interest to readers of The Agile Executive:

It is a little premature at this early stage to project how BSM Review will evolve. My hunch is that forthcoming articles in BSM Review on cloud computing, large-scale operations, leadership, risk mitigation and technology trends will be of particular interest to readers of this blog.