The Agile Executive

Making Agile Work

Posts Tagged ‘Rally

Depth in Seattle

with 2 comments

To summarize it in one word, the October 1 Rally Agile Success Tour (AST) event in Seattle, WA was deep. Broad spectrum of topics – from CMMI  and SOX to Lean and “Lean+”; very knowledgeable participants; insightful panelists; plenty of hard Agile data; questions on real needs; dialogues that led to unexpected findings; and, 1-1 meetings focused on actions that could/should be taken after the event. Just like the recent AST event in Boston, MA, there was vibrancy in the air.

Getty’s Jeff Oberlander quantified the progress they made on fairly large scale releases (~900 user stories), shortening time-to-market (TTM) from 24 month to 4 months. He indicated this impressive change in time-to-market occurred in parallel with improvement in quality. Reader of this post might want to take a look at Chapter 1 of Agile Project Management by Jim Highsmith for a quantitative analysis of the correlation between the two (TTM and quality).

The impressive results reported by Jeff were supported by the classification given by Liberty Mutual’s Steven Johnson. Steven observes three kinds of projects, as follows:

  • Grass roots initiatives. Such projects typically lead to: {New TTM = 2/3 Old TTM}.
  • Organized pilots. Such projects typically lead to: {New TTM = 1/2 Old TTM}.
  • Overall R&D transformation. Such projects typically lead to: {New TTM = 1/3 Old TTM}.

From what I know of David Rico’s forthcoming book The Business Value of Agile Software Methods, the results reported by Steven are consistent with David’s findings.

Boeing’s Ryan Kleps focused on the impact of Agile methods on developer satisfaction. He presented the following data from a survey conducted in Boeing:

  • 30% improvement in satisfaction with respect to tools
  • 25% improvement in satisfaction with respect to involvement
  • 10% improvement in satisfaction with respect to trust

Interestingly, Ryan indicated that various “pirates” were starting to do Agile at Boeing as a result of the higher level of satisfaction noted above. We did not have the opportunity to cross-correlate data from Boeing with data from Liberty Mutual. My intuitive sense is that Ryan’s “pirates” and Jeff’s “grass roots initiatives” are synonymous.

thePlatform’s Reena Kawal and Microsoft’s Stein Dolan provided insights that are not often reported. Reena analyzed the much improved ability to assess trade-offs from a customer perspective. Stein highlighted how effective emulation can be in enabling teams to deal with code that has not been written yet. Their thoughts were vividly complemented by the 4X100 relay race metaphor given by Ryan: only 1 sprinter “works” at any point in time, while 3 are “idle”. Yet, there is no faster way to get the baton to the finish line…

One part of the event that was particularly gratifying to me was the role playing during the breakout session entitled “Socializing Agile with Your Executives.” Stein and I played the role of mean executives who do not get Agile. Participants in the session who played the role of the inspired Agile champion beat us up pretty effectively. As a matter of fact, one of the participants – CyberSource’s Tom Perry – gave the report from this breakout session to the whole audience when we reconvened. He delivered a very effective “why you should do Agile in spite of all your misgivings” message.

As indicated in a recent post, the AST “train” stops in Chicago, IL on the 15 of October. We are quite likely to address specialized topics that have not been brought up in previous events. The makeup of the panel in Chicago is unlike any of the nine panels I have prepped so far…

Toward Vertical Approach to Agile

leave a comment »

Yesterday we held a great Rally Agile Success Tour (AST)  event in Seattle (which I will describe in a subsequent post). On the 15th we will be doing the AST event in Chicago. This post is about an intriguing element of the forthcoming Chicago event.

Every one of the 9 events we held so far (click here for sample video clips from the events) was unique in some ways. The demographics in Atlanta, GA were not like those in Boston, MA. The issues brought up in Los Angeles, CA were different from those in Washington, DC. The panelists in New York, NY addressed a set of topics that did not come to the fore in the Santa Clara, CA event. Each event was characterized by locality of reference – topics, discussions, breakout sessions and 1-1 meetings that were of relevance and importance in the context of the local Agile community.

Having worked with the Chicago panelists in preparation for the forthcoming event, my sense is that we will immerse the participants (and ourselves, of course) in a set of Agile/Lean challenges that could be quite different from those we addressed in other cities. Some very unique companies are represented in the panel we will hold in Chicago.

I actually consider Chicago on the 15th a potential pivot in deepening our understanding of the way Agile applies to various verticals. We are progressing from a horizontal approach to applying Agile toward a more vertical assimilation. The differences between the two might be subtle, but they are all important for the success of the Agile champion.

Written by israelgat

October 2, 2009 at 11:37 am

Posted in Events

Tagged with , ,

I Believe I Set a New World Record

with 2 comments

Coming back yesterday from the Rally Agile Success Tour (AST) event in Boston, I picked my car at the Austin-Bergstrom airport from the spot in which I parked it a few days earlier.


Today, flying to a Cutter Consortium consulting gig in Salt Lake City, I found the very same spot at the airport available to me. I am actually fairly certain the spot sort of smiled with familiarity at me. I, of course, returned the smile.


Quite a record, even if I have to say so… is there a message here somewhere?!

Written by israelgat

September 20, 2009 at 7:09 pm

Richness and Vibrancy in Boston

with 2 comments

A blog post can’t do justice to the richness and vibrancy of the dialogs that were produced by 80 participants in the September 17 Rally Agile Success Tour event in Boston. You had to be there in order to fully savor the experience. If you are a Boston Agilist who missed this gathering, the event in Chicago gives you an opportunity to catch up without needing to fly all the way to the forthcoming events in Seattle or London.

Agile metrics reported during the event were very impressive.  AOL’s Jochen Krebs indicated acceptance of user stories improved from 20% to 90% in one year! Sermo’s Rob Sherman provided the following three year data:

  • 2007: 10 releases; 26 patches
  • 2008: 29 releases; 32 patches
  • 2009: 67 releases; 0 patches

(“0 patches” is not a typo – year-to-date “patches” at Sermo have primarily been about laying the required infrastructure for forthcoming releases to be deployed, not about bug fixing).

The quantitative data was nicely complemented by qualitative insights. ITG’s Heather Kanser’s work on the Virtuous Cycle of Agile and Constant Contact’s Rick Simmons contrasting Informational Metrics v. Motivational Metrics demonstrated ahead-of-the-power-curve thinking. 

One other thread that came to the fore during the event was Agile Business Service Management (Agile BSM). Think of it as the fusion of Agile methods for software development with state of the art practices for managing IT from a business perspective. Embryonic that this trend is, the potential impact is huge. We will discuss this emerging trend in forthcoming posts.

It is a pleasure writing this post!

Written by israelgat

September 20, 2009 at 6:59 am

How Hard Should the Agile Champion Push?

with 5 comments

A question which often comes up in the course of the Rally Agile Success Tour is about the balance to strike between conviction, passion and politics. By virtue of his/her interest in the topic, the Agile champion is often more knowledgeable than his/her superiors on what Agile really is and which strategies are best suited to roll it out. A thoughtful push toward Agile values, principles and practices may lead to major improvements in the way an organization practices Agile. In contrast, an overly hard push might lead to regression in the state of Agile affairs. Moreover, it could easily lead to a breach of the psychoilogical contract between the Agile champion and employer.

Reading The Bureaucratic Phenomenon – a book recommended to me by Forrester’s Tom Grant – I found the following nugget:

The power of decision making within a bureaucratic system of organization is located exactly at the points where the stability of the internal “political” system is preferred to the achievement of the functional goals of the organization.

The specific nature of the bureaucracy with which one has to cope changes, of course, from one company to another.  No matter what kind of bureaucracy the Agile champion has to cope with, the observation cited above applies. The Agile champion can successfully push hard as long as he/she does not cross the fine line between achievement of functional goals and “political” stability.

Written by israelgat

September 13, 2009 at 11:12 am

Hand Crafted Sausages – a Metaphor from Josh Kerievsky

with 2 comments

Reflecting on the Rally Agile Success Tour in Los Angeles, I discussed the “sausage syndrome” as one of the more painful issues between the Agile champion and his/her executive(s):

The “sausage syndrome”: “Don’t bother me with details how you do the software – just get it done” seems to be the attitude of numerous “business executives.”  I must admit I still don’t get it. Software is becoming pervasive on an unprecedented scale. And, software is becoming bigger and bigger component of just about any product in which it is embedded. Ditto for software as part of the business process. What is your recipe for success if you (as an executive) don’t get down and dirty on such a major component of your business?!

Joshua Kerievsky and I discussed the metaphor during an elevator ride in Agile 2009. Josh’s pointed out how delicious hand crafted sausages are. Moreover, he emphasized how intentional and thoughtful a good chef is about the ingredients going  into such sausages.

I used this metaphor in a teleconference I had earlier today with a CEO contemplating a large scale rollout of Agile. He chuckled and enquired about the right kind of beer to go with the sausages. Caught empty handed (was “Pilsner” the right answer?!), I promised an answer no later than my next elevator ride with Josh..

Written by israelgat

September 2, 2009 at 8:38 pm

Think About Pilot Teams, not Pilot Projects – Guest Post by Alan Atlas

with one comment

Rally’s Alan Atlas shares with us his insights on picking a pilot project for Agile. His post nicely complements the account Sue McKinney and Pollyanna Pixton gave about their approach to bootstrapping Agile at IBM (click here). It also touches on some of the points made in our post The First Decision to Make. Whether you agree or disagree with Alan, his thoughts are always intriguing. You will find additional insights by Alan in The Scrum Mechanic.

Alan has been professionally involved in high tech for nearly thirty years. His career spans top technology companies such as Bell Labs and Amazon as well as various intriguing start-ups. He brought to market numerous products, including OSF Motif and Amazon’s S3. His passion for Scrum has recently led him to make a career switch into full-time Agile Coaching and Training with Rally Software.

Here is Alan:

Picture this: You’re an Agile Coach and you arrive for the first day of your new, monster engagement at a large enterprise that has hired you to help them become Agile. You’re very excited as you walk into your first training session with a select group of employees. As you start the training, you are greeted with questions from your happy, excited audience. “Can we get this over with early?” “I don’t want to be here. My manager said I had to come.” “What is this all about, anyway?” “I have a friend who got fired for advocating Scrum. I don’t want anything to do with it.” “Why am I here?”  Is this any way to start an Agile transformation?

A necessary step in Agile adoptions is picking where to start. Consultants often help management or transition teams with the selection of so-called pilot projects. Project teams are then notified that they are the lucky winners in the Scrum Lottery. The result can be a (not entirely incorrect) feeling amongst employees that they are being forced to become Agile, which can lead to the scene I just described.

This command-and-control (C&C) approach can easily erode trust, destroy motivation and handicap an adoption program because it ignores the critical contribution that team buy-in and ownership can make toward successful implementation of the new development process.  At best, it leaves a mild bad taste in the mouths of the employees and gives them a good reason to believe that this Scrum thing is just another management flavor of the week. At worst, it removes the single most important success factor in Agile adoption: the active and enthusiastic participation of the team.

Is there a reasonable way to avoid the pitfalls of the C&C approach and still meet the legitimate needs of management? Can we start a transformation with excited, enthusiastic employees instead of sullen ones? Can management make a decision to ‘go Agile’ and still establish a collaborative relationship with employees? Can we take advantage of the inherent appeal of Agile methods to increase our chances of success? I think the answer to all of these is, “Yes!”

Agile’s people-based approach tells us to view the world from a team-centric point of view and not a project-centric point of view. Applying this to our Agile transition itself, we realize that we don’t need to assign Scrum to projects. Instead, we can let teams choose to adopt Scrum (or not to adopt, to be fair). It’s the team that will make the Agile process work and lead to success, not the project itself. This approach will maximize the likelihood of success by finding the teams that want to make it work.

The way to ensure the success of early Agile transformation efforts and simultaneously to align management and employees without coercion is to provide teams with the permission and knowledge to make their own decisions, and then for management to support those decisions. Teams that choose to ‘go Agile’ will make it work. Teams that are told to ‘go Agile’ might or might not make it work.

Implementing this isn’t hard. Start by making introductory Agile training available to the target organization (a few two-hour classes spread throughout a week is a good start for all but the largest organizations). Announce that teams are welcome to try Scrum, and tell them how to request further team training and coaching (don’t neglect to make sure their immediate management is on board). There might be reasons to give priority to certain teams and possibly to delay others, but in general the teams that want to do Agile should be allowed to do it. The company is now supporting and leveraging teams that want to transition to Agile and allowing those that don’t want to change to continue as they are. This in itself is an important message to all that the Agile philosophy is being taken seriously by management.

The result of using this approach is that there is no bad taste among employees, the most enthusiastic teams self-select to participate in the new experiment, nobody is forced, and management demonstrates its willingness to support employees in the new endeavor.

No managers were harmed in the filming of this scenario. :-)  Seriously, we put the focus on teams without negating any of the needs of the enterprise. The ability of teams to get further training can still be managed. The identities of the teams can be known so that there can be followup assessments, monitoring, and support. In the cases where it is necessary, teams that have interdependencies or other complexities can be staged appropriately. The biggest and most important difference between this scenario and the more traditional C&C scenario is that here the teams that are excited and interested about Agile become the first in the water.

Using this method for starting your transition doesn’t change anything else about your organizational Agile initiative. You still have all of the cultural, technical, engineering, management, organizational, and human issues to deal with. It just gives you a way to pick the starting point in a more positive and Agile way.

Written by israelgat

August 19, 2009 at 7:01 am

Q3 Agile Success Tour: Boston, Seattle, Chicago and London

with 2 comments

Various posts in this blog (click, for example, here, here, and here) brought up noteworthy threads from the Q2 Rally Agile Success Tours events in Santa Clara, Atlanta and Washington, DC. The Rally team and I are gearing up now for the following Q3 Success Tour events:

  • September 17, 2009 in Boston, MA
  • October 1, 2009 in Seattle, WA
  • October 15 in Chicago, IL
  • October 29, 2009 in London, UK

I have started teleconferencing with the panelists in these four cities. It is clear even at this stage of the preparations we will have an eclectic mix of panelists and various intriguing topics that might not have been fully addressed during Q1 and Q2. For example, organizing your reality and Agile can’t be localized are two of the topics that will be discussed in the Boston event.

As I did during Q1 and Q2, I will report here highlights from the events. Stay tuned…

Written by israelgat

August 9, 2009 at 5:20 pm

Posted in Events

Tagged with ,

Threads from Washington, DC

with one comment

Rally’s July 23 Agile Success Tour in Washington, DC was somewhat unique demographically. About 50% of participants work for the government. Moreover, many of the commercial enterprises represented in the event derive a significant amount of their revenues from federal government contracts. The Agile challenges encountered by these folks reflect practices that are not necessarily applicable to “pure” commercial environment. For example, one of the participants asked me about Agile for a project of 500 developers/testers in which her company is the prime contractor for 100 subcontractors! (Recommendation: must devise a business design enabling her company to profitably invest in laying a joint Agile infrastructure across all these subcontractors. Such infrastructure leads to standardization of the Agile data. Click here for details).

In spite of the different demographics, most of the Agile issues brought up in DC were quite similar to those expressed in previous Agile Success Tour events. The bureaucracy with which various Agile champions in DC need to deal with might be stricter (due to security/confidentiality aspects of much of the development carried out in DC), but the underlying needs and dynamics are not really different from those in other cities in which Success Tour events were held.

Here is a sample of enlightening threads I listened to or participated in during the event:

  • The business fabric has not quite caught up with Agile methods. In particular, Agile contracts are not yet where they need to be. The costs associated with “ECOing the contract” each time a change in requirements is made offset the methodical benefits of Agile. We need to find a way to “encode” Agile principles in contracts.
  • In pitching software methods to their executives, Agile champions need to go beyond the benefits of Agile. Risk and risk mitigation are of equal importance. See The View from the Executive Suite for detailed guidance on the subject.
  • The benefits of Agile have to be expressed in terms of the business of the business. One has to go beyond capturing “just” the operational benefits and address financial and business benefits. Peter Drucker’s famous quip “Companies make shoes!” applies. Click here for examination of the quip in the Agile context.
  • Innovation through affordable experimentation is an Agile benefit that is under-represented in many discussions Agile champions hold. See the new edition of Jim Highsmith‘s Agile Project Management for an excellent discussion of this critical benefit.
  • Agile is about uncertainty, not about complexity. To demonstrate the power of Agile, choose a project of high uncertainty. Complexity in such a project depends on your risk tolerance – it could be either low or high. Be aware that various issues related to complexity might manifest themselves on the surface as process issues. See Uncertainty, Complexity, Correctness for an in-depth discussion of the subject.

Next stops of the Agile Success Tour “train” are in Boston, Chicago, Seattle and London. Stay tuned…

Written by israelgat

July 26, 2009 at 6:01 pm

Scrum at Amazon – Guest Post by Alan Atlas

with 6 comments

Rally’s Alan Atlas shares with us his experience as the first full-time Agile trainer/coach with Amazon. His account is both enlightened and enlightening. He connects the “hows”, “whats” and “whys” of Scrum in the Amazon context, making sense for the reader of what took place and what did not at Amazon. You will find additional insights by Alan in The Scrum Mechanic.

Alan has been professionally involved in high tech for nearly thirty years. His career spans top technology companies such as Bell Labs and Amazon as well as various intriguing start-ups. He brought to market numerous products, including OSF Motif and Amazon’s S3. His passion for Scrum has recently led him to make a career switch into full-time Agile Coaching and Training with Rally Software.

Here is Alan on what he learned about Scrum transition at Amazon.com:

Agile practices were present at Amazon.com as early as 1999, but it wasn’t until the years 2004 – 2009 that widespread adoption of Scrum occurred throughout Amazon’s development organizations. Amazon.com’s unplanned, decentralized Scrum transformation is of interest because it is different from the current orthodoxy regarding enterprise Scrum transitions, and its strengths and weaknesses reveal some fundamental lessons that can be applied to other enterprise Scrum transitions.

Here are the major forces that played in the transition.

Permission

Teams (including local management, of course) at Amazon have historically been given wide latitude to solve their problems (coupled with responsibility to do so without waiting for outside help) and are usually not overburdened with detailed prescriptive practices promulgated by centralized corporate sources. The emphasis is on creating, delivering, and operating excellent software in as streamlined and process-light a way as possible. Teams at Amazon have permission to choose.

Teams

The corporate culture at Amazon.com has always been surprisingly consistent with and friendly towards Agile practices. The 2 Pizza Team concept has been written about many times over the years (click here), and a close look shows that a 2 Pizza Team is basically a Scrum team without the Scrum. Teams at Amazon, especially 2 Pizza Teams, are stable and long-lived. Usually a development team reports to a single direct manager.

Knowledge

All it took to light the fire was someone who was willing to spend a little time educating interested parties about Scrum. Teams who learned about Scrum were able to make local decisions to implement it. Results were demonstrated that kindled interest in other teams.

Impetus

Over time, an email-based Scrum community formed. Scrum Master training was provided on an occasional basis by someone who simply wanted to do so. Basic Scrum education continued on an ad hoc and voluntary basis. Eventually enough teams had adopted Scrum that a need was seen and a position of Scrum Trainer/Coach was created. Having a full-time Trainer and Coach available made adoption easier and improved the quality of scrum implementations. By mid-2008 the community was able to support an Open Space Scrum Gathering within the company.

What was (and one assumes is still) missing was higher level engagement at the organization and enterprise levels. No executive support for Scrum ever emerged, and the transition was therefore limited primarily to the team level, with many organizational impediments still in place.

The success of Scrum at Amazon validates one easy, frictionless way to begin a Scrum transition.

  1. Establish stable teams
  2. Make Agile and Scrum information widely and easily available
  3. Give permission to adopt Scrum

The advantage of this approach is that it requires a minimum of enterprise-wide planning and it allows teams to select Scrum, rather than mandating it. All of the rest of an enterprise Scrum transition can be accomplished by simply responding to impediments as raised by the teams and providing management support for change. Based on experience, the impediments raised will include demand (pull) for coaching, scaling, training, organizational change, a Transition Team, PMO changes, and all of the other aspects of an enterprise transition that many organizations labor so mightily to plan and control. Leadership for this kind of transition can only be Servant Leadership from the C-level, which is exactly the right kind for an Agile initiative, isn’t it?

The only impediment to Scrum adoption at Amazon was lack of knowledge. Teams were in place, and permission was part of the culture. When knowledge was provided, teams adopted Scrum. The strength of this process was based on the fact that only teams that were interested in trying Scrum actually tried it. There was no mandate or plan or schedule for this uptake.  Nobody was forced to use Scrum. Teams made an independent, informed decision to try to solve some of their problems. Lean and Agile thinkers will recognize that this as a pull-based incremental approach and not a plan-driven, command and control, push-based approach.

What about the things that didn’t happen at Amazon? The transition stalled at the team level due to failure to engage either middle or upper management in a meaningful way.  Both of those groups are required to bring a transition to its full potential. Training for middle managers, in particular, is crucial, but will usually reach them only with executive sponsorship.  A Transition Team is crucial when organizational and enterprise-wide impediments begin to be unearthed. Support from a source of advanced knowledge and experience (trainer/coach) is key.

Was Scrum good or bad overall for Amazon? There is only spotty, anecdotal data to report. Certainly there are many stories of teams that used Scrum very successfully. The Amazon S3 project, which not only delivered on time after about 15 months of work, but nearly achieved the unusual result of having the entire development team take a week’s vacation leading up to the launch day. It was not the crunch-time, last minute, panic-drenched effort that is common with projects of this scope and complexity. There was the team that “hasn’t been able to deliver any software for 8 months” that, sure enough, delivered some software a month later at the end of their first sprint. Another team reported that their internal customers came to them some time after the team had adopted Scrum, asking that they implement a whole list of random features. “We know these aren’t your responsibility, but you’re the only team that is able to respond to our requests.” Finally, there was the platform team that had literally dozens of internal customers. When that team adopted Scrum, they organized their customers into a customer council of sorts and let them simply decide each month what the team would work on, for the good of all, in order of value to Amazon overall. But even if none of these anecdotes were available to tell, the mere fact that teams opted on their own to adopt Scrum implies that something about Scrum helped them be more successful and more satisfied professionally. If that were not true, then they would not have stayed with it at all, right?

Written by israelgat

July 20, 2009 at 12:20 am

Follow

Get every new post delivered to your Inbox.

Join 37 other followers