The Agile Executive

Making Agile Work

Archive for February 2009

Every Thirty Minutes

with 3 comments

Colleague Jim Van Riper drew my attention to a point Kent Beck made in a recent presentation: Flickr deploys every 30 minutes.

The point Kent makes fits nicely with two themes that have been discussed in this blog:

Between fast development and fast deployment I am starting to think in terms of software as water. Software could and should continuously flow on demand from the R&D lab to the customer. Such uninterrupted flow in the feedback loop between developer and end-user makes Agile extraordinarily powerful.

Advertisements

Written by israelgat

February 13, 2009 at 8:58 am

Posted in Benefits of Agile

Tagged with

When Quality is Not an Option

leave a comment »

Jesus, this outfit needs some budget

Every cure to a problem begins with one obvious step: stop doing the thing that’s causing the problem. No general cure-all or best practice can directly address that first step perfectly for every singe instance. In the world of Agile development, organizations are often plagued with dysfunctionality that must be addressed before Agile methods can achieve the stupendous results those organizations are lusting after.

As I’ve watched people discuss and, more often, argue about Agile over the years, I’ve noticed that these folks often begin their quibbling over this first step: one side of the argument will assume the disfunction in the organization has been – or even can be – taken care of and is, thus, shocked that Agile would not work, while the other is focused on the existence of the disfunction and the impossibility of removing it.

As you can guess, I have no pat answer for how you clean up that problem: that’s the whole point.

It always strikes me that Agile methodologies work very well with functional teams: in fact much of the management side of Agile goes towards identifying (with the goal of getting rid of) dysfunctional team members and processes. Still, you don’t see much on the topic of “Agile firing.”

Other, pre-Agile approaches, however, tend to be the opposite: they’re built around helping an inefficient, dysfunctional base achieve “success” at software delivery. There’s some semantic difference on what “success” means there: for Agile it usually means high quality, for more cynical methodologies it can mean cashing the clients’ check, meeting KPIs, or otherwise CYA’ing instead of “doing the right thing.”

Those are broad generalizations, of course, but I’ve rarely found an agile solution that doesn’t involve making things better rather than dealing with the less than ideal team you’ve been given. Alistair Cockburn‘s work is an interesting exception here where-in he spends quit a bit of time assessing the quality of teams and then trying to match-up methodologies that will work with what you have rather then let you excel with what you wish you had.

The danger here is to think the conclusion is to ask if yourself if Agile will work in your dysfunctional organization. Clearly, if you have a dysfunctional organization, whatever it is you’re currently doing doesn’t work, by definition. But, the trap in that situation is thinking that Agile will help you avoid the difficult task of maturing and getting good enough to even start benefiting from becoming Agile.

Written by Coté

February 12, 2009 at 3:05 pm

“Where to Turn in a Downturn Economy?”

with 2 comments

Jean has a nice post in the Agile Blog on team dysfunctions and Agile. Her recommendation on the subject is crisp:

If you are looking to Agile and how it can cut costs for your organization, consider the power of your teams. Work to engender trust and promote an ability to have constructive conflict. Empower your teams and amplify the learning that teams bring to organizations.

I will allow myself to go one more step. IMHO Agile exposes team dysfunctions and organizational pathologies. This is the reason Agile is so powerful on the one hand, and why it might meet strong resistance on the other.

Written by israelgat

February 11, 2009 at 11:54 pm

iBetaTest

leave a comment »

Colleague and friend Sebastian Hassinger drew my attention to iBetaTest – a new service that brings together application developers and beta testers.  It is a fascinating concept no matter what software development method you use. Once it spreads beyond iPhone applications it could have quite an impact.

Written by israelgat

February 10, 2009 at 9:07 pm

Posted in Testing

Tagged with ,

Active Releases

with one comment

A Continuum

The traditional way of examining software from a life-cycle perspective is phase-by-phase. The software is developed; deployed; monitored; maintained; changed; and, eventually retired.

True though this description is, more and more executives these days actually view it all as one continuum. An application is developed, and  then deployed and maintained as part of some business process. At a certain level it might not really matter to a business executive what the software life-cycle is and which party carries out what phase. The thing that matters is that some service is performed to customer satisfaction. One could actually do complete  Business Process Outsourcing, chartering  a third party to take care of all the “headaches” in the continuum – from coding a critical software component to repairing a delivery truck to answering calls like, “My shipment has not arrived on the promised date.”

This post looks inside the continuum to comments on the implications of increasing the number of releases. Aspects related to, IT operationsIT service management and the customer as a strategic partner will be discussed in subsequent posts.

Number of Active Releases

The delivery of value to the customer is a fundamental tenet of Agile. The whole Agile development process is geared to that end. Customer value, however,  is realized when the customer is able to start using the product . As deployment cycles for enterprise software can be quite long, time gained through Agile development is not necessarily of immediate value to the customer. For customer value to materialize, the deployment cycle needs to be fast as well.

Companies that use Agile successfully can be quite different with respect to deployment practices. Here is a quick comparison of BMC Software, PatientKeeper and Google:

  • The successful implementation of Scrum at BMC Software led to producing 3-4 releases of the BMC Performance Manager per year.  However, time to deployment by various customers varied greatly.  Hence, a relatively small number of releases was active at any point in time.
  • With PatientKeeper,  Sutherland exploited the hyper-productivity of his Agile teams to produce a relatively large number of releases. When a customer needed a “release” it was downloaded via VPN and installed in fairly short order. Some 45 active releases of the software existed at any point in time.
  • Companies such as Google expedite deployment by using Software as a Service (SaaS) as the delivery mechanism. Google has only one actively deployed release at a time, but produces many fast releases.

As one increases the number of releases, a reasonable balance between velocity of development versus velocity of deployment in the continuum must be struck. To streamline end-to-end operations, velocity gains in one should be matched by gains in the other.

It does not Really Matter if you can Tell the Egg from the Chicken

One can speculate on how things evolve between development and deployment. Whether Agile software development leads to improvement in deployment, or Software as a Service “deployment” induces faster development processes. The Agile philosophy is well expressed in either case. In either direction, the slowere speed area is considered an opportunity, not a barrier. A Software as a Service Operations person who pushes for faster development speed lives the Agile philosophy even if he knows nothing about Agile methods.

Written by israelgat

February 10, 2009 at 2:58 pm

Between R&D and Sales

with 3 comments

In Selling is Dead, authors Miller and Sinkovitz describe the ascendancy of a class of professional procurers who are not easily manipulated by the old  sales tricks in the book. The proverbial sales rep with the Rolex watch who takes his customer to lunch is deemed ineffective by the authors. Instead, the sales rep needs to be a business person who sells.

The thinking articulated by Miller and Sinkovitz is quite relevant to Agile methods. In rolling out Agile in R&D, you need to be very mindful of the way your sales force sells your product.

Product Management versus Development

Various Agile case studies point to initial, and sometimes sustained friction between product management and development. Ditto for various Agile forums. For example, the subject was the source of a lively discussion during this week’s Agile Austin presentation. “Best practices” on how Agile developers should handle product managers in the “real world”, and vice versa, were traded…

The development versus product management conflict usually centers around prioritization and delivery in the context of an impossible backlog. And, it can get nasty about misunderstandings as to what was promised or implied versus what was actually delivered. Poorly articulated, poorly understood requirements tend to aggravate the situation, particularly when the product management team is spread too thin between inbound tasks and outbound assignments.

A Matter of Optics

The product management versus development conflict is really a symptom, not a root cause. The real issue is rooted in the philosophy of sales.

The availability of one feature or another is not usually an issue when selling is focused on value. Important though a certain feature may be, the selling is really about how the customer will derive value from the business process in which the software is embedded, not from the software per se. For example, a bank could satisfy a compliance requirement by way of a management application that monitors logs. Monitoring the log to itself has some value from an IT perspective, but the greater value is in the process ensuring regulatory compliance based on the data provided by the log monitoring application.

Failure to elevate a transaction to the value level usually results in client and vendor dealing primarily on the basis of features and functions. The sales process often deteriorates to the bill of goods level. The process focuses on what the software is, as distinct from what the software can do for the customer. The customer tends to hold the feet of the vendor to the fire with respect to each and every feature.

Two Strategies for Agile Roll-Out

The Agile roll-out in R&D needs to take into account the maturity of your sales organization:

  • If the sales organization primarily sells features, you need to focus the Agile roll-out on effective interaction of development with testing. Start testing as early as possible as an integral part of development, and possibly as the driver of development under the test driven development paradigm. Basically, you are betting on improving the engineering process to the point in which you are over-delivering.
  • If the sales organization is largely selling value, focus on the integration of Sales (and customers) in your Agile process. For example, integrate Sales in your release planning, in the bi-weekly demo and in the release retrospective. In certain cases you might even include Sales in some iteration retrospectives. In this scenario you are betting on the core principle behind Agile: Do only the most important things at any point in time.

In either case, extricate your product management team from the “cross fire” between R&D and Sales. Product management is simply the adaptor for the impedance mis-match between Agile principles and sales maturity.

Written by israelgat

February 5, 2009 at 3:37 pm

Scaling Agility: From 0 to 1000

with one comment

Walter Bodwell delivered an excellent presentation on the subject in Agile Austin last night. The presentation is quite unique in seeing both the “forest” and the “trees”. Walter addresses the operational day-to-day aspects of Scrum in the trenches in parallel with providing insights on the roll-out at the executive level. Highly recommended!

Written by israelgat

February 4, 2009 at 9:25 am