Archive for June 2009
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.
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…
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!
- 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!
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.
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.”
- 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.