Archive for June 2009
Auctioning on eBay: 2-Hour Remote Pair Programming Session with Kent Beck
Here is Kent’s own description of the offering:
I have spent thousands of hours remotely pair programming with clients. We cover a broad range of topics, from software process to software design to tool development to application development to theory of programming to economics to… well, pretty much anything we want to talk about that’s related to programming. This is your opportunity to pair program with me remotely for two hours. I am fluent with Java, Eclipse, and Smalltalk, but I am used to pairing on unfamiliar technologies. We can work on testing, design, implementation, review, or whatever other technical topic you would like. I have found that the technology for pair programming can be a bottleneck. It’s easy to spend an hour just getting set up. For purposes of this offer we will use VNC for screen sharing (you host the server) and Skype for audio/video. The programming session will take place within two weeks of the sales date at a mutually agreeable date and time. I look forward to programming with the winner of this auction.
Software Capitalization in Atlanta
Yesterday’s Agile Success Tour event in Atlanta was characterized by quite a strong interest of various participants in software capitalization. While the topic came up in previous success tour events, it was more pronounced in Atlanta. A subtle shift seems to be taking place: from technical aspects of rolling out Agile to business aspects the Agile champion needs to be aware of and prepared to address.
In the course of exploring software capitalization, participants in the Atlanta event brought up related questions about “the business of Agile.” For example:
- Cost accounting for Agile
- Return on the Agile investment
- Agile Portfolio Management
- Governance of the Agile project/initiative
Some of the participants were quite thoughtful about the dividing line between project-level Agile implementation and Enterprise-level implementation. They grasp that scaling Agile changes the nature of the questions one wrestles with. A few of them are actually considering top-down approaches to implementing Agile. They do not necessrily subscribe to rolling Agile in a bottom-up manner. They devote quality time to wrestling with Agile scaling issues prior to starting the first Agile project.
I am hesitant to draw general conclusions based on a single event in a particular city. For example, I wonder whether the emphasis on capitalization might be related to the concentration of Supply Chain Management firms in Atlanta.
As the Success Tour “train” continues its journey (next stop: Washington, DC on July 23) we will soon have additional data points. Stay tuned…
The June 25 Agile Success Tour Event in Atlanta
Having finished my prep meetings with panelist in the forthcoming Rally Agile Success Tour day in Atlanta, I anticipate the event will be really rich in content. The panelists will bring up various actionable insights in quite a few Agile/Lean areas. Here is a sample of some of the more intriguing topics that will be highlighted by them in the course of the event:
- Agile metrics
- Return on investment considerations
- Painless cost accounting in Agile
- The “All In!” rollout strategy
- Sustaining the Agile momentum over a prolonged period
- Succeeding with insanely distributed teams
- Requirement Driven Agile Development (RDAD)
- ‘Secret sauce’ for large scale Agile initiatives
The dynamic nature of the event will no doubt lead to many additional topics and insights. Much of the content in the recent Rally event in Santa Clara was generated by participants sharing their explorations, experiences and thoughts with one another. It is a very effective way to learn.
The event is characterized by a high concentration of decision makers: 44% of participants will be in the VP/CXO/Owner category; 40% in the Manager/Director category. It will be meaningful to you whether you are an Agile champion or an Agile decision maker. As a champion, you will get immersed in the issues your executives are wrestling with. As a decision maker, you will acquire deeper appreciation of the operational, financial and business advantages Agile methods enable.
Please introduce yourself to me in Atlanta If you are a reader of this blog. It is a great opportunity to “touch” each other!
Nuggets from Salt Lake City
Cote has captured my reflections on Agile Roots in the podcast entitled Agile Roots, Agile Operations & Agile Clouds. This post highlights a few nuggets not covered in the interview, as follows:
- Attendance in the conference (>200 folks) was driven only by word of mouth.
- If you ever hear the old excuse “This feature cannot be decomposed to fit in the iteration,” send the person saying so to Alistair Cockburn’s workshop Nano-Incremental Development, a.k.a. Elephant Carpaccio. Amazing what can be squeezed into a nine-minute iteration!
- The nine-minute limit on iteration length might seem artificial. However, as part of his workshop, Alistair indicated top programmers tend to break the tasks they are working on to slices no longer than thirty minutes.
- According to Jeff Patton, Jim Highsmith has recently revised his quip “Barely sufficient process” to “Barely sufficient is too much.”
- Sue Mckinney indicated average size of the development team at IBM’s Software Group has dropped from 500 to 50 over the past few years.
- Reece Newman pointed out that both Brian Marick and I are actually talking about a social contract for Agile. Brian in his response to the question “”If anarcho-syndicalism was crushed during the 1920’s in the United States and its principles inspired the Agile Manifesto as well as Agile software development, why hasn’t the Agile movement been crushed?” Me in the post A Social Contract for Agile. To quote Reece:
Although the content of the Social Contract in Brian’s answer differs from your Social Contract for Agile, the idea of a Social Contract is present in both your blog and Brian’s answer.
- Brian Marick observed that Ruby programmers often tend to work in an Agile manner. In various cases the Ruby programmers were not even even aware of Agile as a software method.
- Reece Newman pointed out that good tools tend to be “culture neutral.” Hence, they can induce behavioral changes without necessitating explicit culture change pushes.
- Last but not least – expect Agile Roots to be held again in 2010!
Agile Roots, Agile Operations, & Agile Clouds, Agile Executive Podcast 003
To listen to this podcast, download the podcast directly, subscribe to the blog/podcast feed in iTunes (or whatever), or click play below to hear it:
After having some coffee here in Austin, Israel Gat and I braved the Texas heat a little while longer to record a conversation about the recent Agile Roots conference, how Agile has spread in recent years, and some of the potentials that cloud computing plus Agile might bring.
We go over the Agile Roots conference that Israel was currently at: one of the themes, Israel says, was a sort of retrospective on the Agile Manifesto (put out in 2001). Also, as Israel points out many times, there was a good mix of people that made the “hallwaycon” enjoyable. Part of this, it seems was due to the somewhat unconference-y feel of the event: while it had a formalized agenda, there was room for less structured, unconference-style sessions and discussions.
Based on this, I then ask Israel to summarize what his and other’s people take was on where Agile is today. In my words, it seems like Agile thinking has, largely, gone main-stream. In fact, as I chime in, large corporate development tool vendors like Microsoft with VisualStudio and IBM with the Rational line are bringing in and using significant Agile principals and practices.
Next, we get into the “Agile Operations” conversation folks from Reductive Labs have been having of late. Esp. when cloud computing technologies (like virtualization, automation, and SaaS-think) are brought into the operations side of the house, Agile principals seem especially well positioned to take advantage of cloud technologies. This gets us into a discussion of how cloud delivered software (SaaS, pretty much) might help free up some time and resources in the traditional software delivery process, primarily, by not having to support many different versions, but also (some what paradoxically to that) allowing bette customizations per customer.
From here, I lay out the theory that with cloud computing, there seems to be some efficiency gains that make it possible for smaller teams to develop and sell software instead of having to hook-up with larger software companies to get efficiencies of scale. While this discussion, as Israel gets to, has been happening a lot in the startup world (startups need less capital up-front to buy hardware and such, and thus, need less funding), it hasn’t been reflected on much in the plain old ISV world. Israel lays out an interesting “out source (most) everything” model for software companies.
The Agile Regime Change – Guest Post by Tom Grant
Forrester’s Tom Grant shares with us his observations from the recent Agile Success Tour in Santa Clara, thoughts where the Agile movement is and lessons from history we all should pay attention to. His post is characterized by breadth of vision and depth of knowledge.
Tom is a Senior Analyst at Forrester Research, specializing in the technology industry’s challenges in product development and adoption. He has recently published research on the effects of Agile within technology companies, the use of social media as a new source of product requirements, and the roles of product management and product marketing. Before joining Forrester in 2008, Tom ran product management teams at big companies, such as Oracle, and small companies, such as Xythos.
Here is Tom’s post:
By all appearances, the Agile revolutions is entering a new phase, by moving along the same path that many revolutions follow. We’re now at the point where revolutionary movements succeed or fail, based on their ability to be pragmatic and inclusive.
Revolution and pragmatism
In the 18th and 19th centuries, political thinkers and practitioners in the Old and New Worlds pondered the differences between the American and French Revolutions. How did the leaders of the American Revolution replace a distant monarchy with a benign republic, with violence limited to a traditional war among field armies? Why, in contrast, did the French revolutionaries eventually exchange their king for an emperor? And why did the Revolution turn its violent wrath on civilians?
Many pointed to the enlightened pragmatism of Jefferson, Washington, Madison, and other American revolutionaries. The leaders of the American Revolution made profound political changes that took human nature into account, without trying to change it. Madison, for example, argued in the Federalist papers for a form of government that took into account the “propensity of mankind to fall into mutual animosities,” instead of trying to cure people of these nasty tendencies.
In contrast, the radicals who eventually gained the upper hand in the French Revolution had a more ambitious agenda. For example, the Jacobins sought to “cure” citizens of their attachment to religion. Unfortunately, they didn’t replace one deeply personal source of inspiration and solace, the Church, with anything comparable. Not surprisingly, when the revolution regime fell under internal and external attack, the Jacobin leaders were unable to mobilize the support they needed, and the revolution collapsed.
The historian Charles Caleb Colton made this point succinctly: “Thus the American Revolution, from which little was expected, produced much; but the French Revolution, from which much was expected, produced little.”
Agile and pragmatism
Last week, both Israel Gat and I attended Rally’s “Agile Success Story Tour” (he as a presenter and moderator, me as an audience member). The success stories themselves had a clear, obvious common thread: Agile success depends on adapting methods to fit the organization, which encompasses a lot more than just the development team. For example, George Morris of Roche stressed how important it was to manage the “impedance mismatch” between Agile and non-Agile teams. Doug Miller of Thermo Fisher Scientific argued that, to accommodate concerns like FDA regulations, his team needed to treat Agile and Waterfall as a continuum, not a binary choice.
These narratives of Agile success did not involve comparisons between the virtues of Scrum over XP, analyses of the right build environment for Agile development teams, or many of the other familiar topics from the last several years of Agile discussions.
Just a new constitution re-defines how politicians and civil servants should behave, Agile introduces new practices, such as continuous integration, daily Scrum meetings, and test-driven development, that prescribe new behaviors for development teams. However, as shown in these success stories, the Agile revolution depends on more than just a new constitution. For any new regime to succeed, it must bring the rest of the country, or the organization, along with it.
From the particular to the general
Of course, you may wonder if any single success story, no matter how compelling it sounds, is really representative. That question has more than just academic interest, if you’re trying to repeat the same experiment successfully.
Fortunately, the broader data support the success stories presented at the Agile Success Story Tour. For a recent Forrester study about Agile in the technology industry, “From Agile Development To Agile Engagement,” we surveyed a broad range of tech industry professionals—some in development, others not. Among other results, we found that the vast majority of implementations mix Agile with other techniques, and don’t treat Agile as a strict orthodoxy.
Since we spoke to more than just the members of the development team, we also had a chance to spot how Agile changes the relationships between Development and other groups. The “impedance mismatch” that Roche’s George Morris reported is by no means a unique experience. Without a deliberate effort, the relationship between Development and other groups does improve to some degree. The amount of improvement depends on how close to the development process the other group is. On average, the relationship between Development and PM, for example, improves more than the relationship between Development and Sales.
In other words, Agile in its original form, new techniques for product teams to follow, is a mixed blessing. Improvements happen, but not necessarily everywhere they need to. As the technology industry has matured, vendors have gradually learned that, for innovation to succeed, the customer-facing groups, such as Sales, Professional Services, and Support (not to mention partners), have to work in closer sync with the Development team. Throwing code over the wall is a formula for failure. Throwing code over the wall faster is not a formula for success.
The people who move the Agile revolution forward from this critical juncture should ponder what Edmund Burke said about the English political system, in contrast to the French Revolutionary regime: “Our patience will achieve more than our force.”
Four Principles, Four Cultures, One Mirror
Click here for the slides of my keynote presentation today in Agile Roots. The following key points are made in the presentation:
- The Agile Manifesto principles are considered timeless.
- Application of Agile can create cultural duality/conflict. The core culture of the organization that rolls out Agile is not necessarily aligned with the Agile culture.
- Successful application of the Manifesto principles needs to build on the strength of the specific core culture – Control, Competence, Cultivation or Collaboration – in the organization rolling out Agile .
- Schwaber’s 75% failure rate estimate corresponds to attempts to change the core culture of an organization as part of the Agile rollout.
- Success does not necessarily beget success in Agile rollouts. The interplay between scale and culture poses serious challenges to scaling Agile successfully.
- The Agile infrastructure places a practical limit on the scope of the Agile rollout. Constituencies that are not able to use a joint Agile infrastructure are not likely to collaborate.
- The fine points of one Agile method versus another are far less important to the success of an Agile implementation than cultural subtleties of the target environment in which Agile is applied.
- Good Agile tools are likely to induce behavioral changes without necessitating major cultural pushes.
The “All In!” Approach to Agile Rollout – Austin and Atlanta
The June 18 “Ask and Expert” session of Agile Austin poses a unique opportunity to to discuss the pros and cons of the “All In!” approach with Erik Huddleston– an Agile champion who has successfully implemented Scrum in this manner. Bringing Scum to Inovis in 2007, Erik opted for an “All In!” implementation instead of the more customary team-by-team rollout. The Inovis case study is one of the very few authoritative sources on this gutsy approach.
If you can’t attend the clinic in Austin on the 18th, you might want to watch out for his forthcoming Agile Success Tour panel session in Atlanta, GA on the 25th. Erik’s insights will be posted here and here a few days after the event.
“What is Our Recipe for Success?!”
A pattern started to emerge for me as I was listening to various participants in the Rally Agile Success Tour in Santa Clara. Agile champions these days often operate in the context of aging business designs. Opportunities the Agile champions highlight to utilize Agile for higher productivity, better quality and faster time-to market are often lost amidst a vicious cycle: sooner or later aging business design are accompanied by value outflow; the severity of the value outflow problem consumes most/all executive cycles; consequently, the message about the various ways in which Agile could help turn things around are not heard. It is a sad irony: at the time Agile is needed more than ever, openness and receptivity toward improving operations and attaining competitive advantage through new (software) methods tend to decline.
Here is a simple question you could ask executives in your company if/when your Agile message does not seem to get heard:
What is our recipe for success?!
The point in posing this question is straightforward: start a dialog aimed at identifying the linkage(s) between the benefits of Agile and the strategy or grand strategy a company is implementing. No matter what business your company is in, chances are software plays a big part in whatever it does. Any business process in your company depends on software. Services your company offers require software in one way or another. Quite a few products your company brings to market are likely to contain embedded software. Compliance requirements your company needs to adhere to inevitably depend on software. These days we all witness pervasive software in the true sense of the term.
The possibility exists that the question “What is our recipe for success?!” might be be misinterpreted as flippant. If you are worried about such misinterpretation, ask your Agile consultant to bring up this question. It is an absolutely appropriate, indeed necessary, question for him/her to pose in the course of designing an effective Agile roll-out. The roll-out itself might (or might not) be focused on R&D. However, the plan for so doing must factor in business circumstances and imperatives. The recipe for success question is part of “deciphering” the business context to enable R&D to be truly aligned with the business.
Recommendations from Santa Clara
So much was going on simultaneously in Rally’s Agile Success Tour event in Santa Clara! More than 140 participants, an eclectic panel, 6 breakout sessions, numerous 1-1’s and, of course, a ton of spontaneous interactions. This posts in many ways represents my own “thread” within this very gratifying event. My Rally colleagues will no doubt supplement this post by commenting on the various activities and interactions in which I was not able to engage.
The number one question I was asked in the course of the event was about the difficulties quite a few software development champions encounter in the course of attempting to coalesce successful Agile projects into comprehensive initiatives at the corporate level. Team successes with Agile sometimes remain isolated islands of excellence within corporate “oceans.” The proven ability of a capable Agile champion to carry the day in specific project does not necessarily lead to adoption of Agile as part of an all-encompassing corporate doctrine. Just like the Geoffrey Moore entrepreneur who demonstrates success in the early days of his/her start-up but does not quite make it big time, the Agile champion often struggles to cross an adoption chasm and make his/her way to “main street.”
Colleagues Ryan Martens, Dave West and Tom Grant discussed how to apply Agile in combination with Lean to elevate Agile from the project level to the corporate level. There is no need to repeat their good work (click here for example) in this post. Instead, here are the tactical suggestions I gave in Santa Clara to various Agile champions who looked for recommendations how to elevate Agile:
- A statement of Agile benefits is not sufficient. It must go hand-in-hand with an assessment of the risks (plural!) associated with the Agile expansion. See A View from the Executive Suite for details of the recommended approach.
- Statements of Agile benefits and corresponding risk mitigation approaches are not sufficient. As Peter Drucker quipped, “Companies make shoes!“ To be relevant at the strategic level, the Agile program must be tied into the top initiatives a corporation carries out.
- Statement of Agile benefits, risk mitigation and strategic relevance are not sufficient. These statements must be accompanied by a clearly articulated approach to managing the cultural aspects of extending and expanding Agile. If at all possible, opt for for building on the strength of the current culture. It is much more difficult to try to change a culture. Moreover, it take a long time to transform a culture. See my forthcoming presentation Four Principles, Four Cultures, One Mirror in Agile Roots for details.
I will allow myself to repeat my recent assessment from the NYC event as it applies so well to the Santa Clara event:
I came out of the Santa Clara event convinced that we as a movement have a great opportunity on our hands. What we -Agilists – do works quite well. The need clearly exists to elevate Agile to the enterprise level. We will be solving a real problem in so doing.