Archive for March 2009
Authenticity
Readers of Software Craftsmanship might recall the association made in the post between Beautiful Software and the Cluetrain Manifesto. With the 10-year anniversary of the debut of the printed edition of the Manifesto, Simon Owens interviewed three of the four authors. The book and the interview are not about software development – they are about the Internet. Yet the profound relevance to Agile software development is nicely captured by Simon in one short sentence:
The writing stresses the need for authenticity above all else….
The imperative need to have authentic conversations with your Agile teams and key stakeholders is highlighted by Ken Schwaber in a recent interview on AgileCollab, as follows:
I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it… The intention of Scrum is to make [their dysfunctions] transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them.
Better heed the good counsel of the Cluetrain Manifesto authors and Ken if your Agile software is in trouble. Backlogs and burn-down charts are no doubt important. But, they are no substitute for authenticity.
Pains from Los Angeles
Click here, here and here for stroke-by-stroke coverage of the March 26 Rally event in Los Angeles by Zach. From my own interactions with participants during the event, I compiled the following list of the most painful issues between an Agilist 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?!
- Agile as part of the overall software engineering fabric: This issue is a close cousin of the “sausage syndrome”. Expectations of Agile are unrealistic as it is not grasped holistically as one layer in the overall context of the art of programming. We direly need a construct like the OSI Reference Model for software engineering.
- Agile and the real customer: Much of the emphasis is still on Agile in R&D. The real customer is not iteratively integrated in the development process. In spite of a ton of data to the contrary, we often drive the iterative development process under the fallacy that the customer problem is well understood.
- Agile in the business context: Discussion are usually focused on $$. Most Agilists do not seem to be well equipped to discuss Agile in the contexts of risk mitigation and compliance.
- Assimilating Agile: Little understanding that apprenticeship is a wonderful way to learn Agile. Precious few invest sufficiently in on-going Agile consulting and coaching.
I started the event stating that I feel like one foot in cold water, the other in hot water: we accomplished so much over the past few years, yet much more could and should still be accomplished. I finished the event with precisely the same feeling: a ton of enthusiasm for Agile in the trenches; the immense opportunity to harness this enthusiasm at the enterprise level is not quite happening yet.
Agile Q&A Service
One of the “services” we want to offer is a classic write-in question section here at The Agile Executive. Inevitably, with something like Agile, there are many questions, esp. from those who are transitioning to it or looking to apply it to new environments.
With the Q&A service, we’d love to have you, dear readers, write in your questions and concerns. We’ll take a whack at addressing them, pulling in other experts as warranted as well.
As an example, I recently had a fun, multi-modal (from a lunch of mole enchiladas to email) conversation about the role of code review in Agile Development.
How does it work?
All you need to do is email in your agile related questions to questions@theagileexecutive.com and Israel and I will answer select questions here.
The Language, The Issues
Colleague Clarke Ching asked me about the language I use in interacting with executives on Agile topics. To quote Clarke:
Obviously the language one uses with a developer is quite different from the language one uses with a program manager. Likewise, the language you [Israel] use in discussing Agile with executives must be quite different. What language do you use? In particular, what language do you use amidst the current economic crisis?
What language do you use amidst the current economic crisis?
I view the economic crisis as part of life. Having grown up in Israel, I still clearly remember:
- The 1956, 1967 and 1973 wars;
- Various economic crises;
- Any number of measures taken by the government to cope with financial crises. For example, devaluing the currency on many occasions.
We all survived and the country moved forward in leaps and bounds. We simply learned to accept dramatic changes as inevitable, to continue doing what we believed in. We, of course, changed tactical plans in response to disruptions such as a change in the value of the currency, but continued to do the right things strategically. Such turbulence, and possibly worse, has been characteristic of much of the world for many years now. Just think of Eastern Europe, Latin America or Africa.
Fast forwarding to 2009: I try to put the economic crisis in perspective. I have discussed the techno-economic cycle along the lines articulated by author Carlota Perez in her book Technological Revolutions and Financial Capital: The Dynamics of Bubbles and olden Ages. In my recent post Why Agile Matters, I stated:
- The fifth techno-economic cycle started in 1971 with the introduction of the Microprocessor;
- This cycle has been characterized by software going hand-in-hand with miniaturized hardware. We are witnessing pervasive software on unprecedented scale;
- Furthermore, software is becoming a bigger piece in the contents of just about any product. For example, there are about 1 million lines of code in a vanilla cell phone;
- Agile software significantly reduces the cost of not “only” software, but the cost of any product containing software;
- And, Agile software enables us to respond faster and more flexibly to changes – in the software, in the business process that is codified by the software, in the product in which the software is embedded.
In short, I speak about software as an important factor in the bigger scheme of things – the techno-economic cycle.
What language do you use in your conversation with executives?
I describe the benefits of Agile in the business context. For example, when I meet an executive of a major financial institution, I discuss with him/her issues of compliance and risk his company is facing. For a global financial institution I typically discuss the critical needs during transfer of trade from London to Wall Street. A lot of things need to work seamlessly in order to ensure smooth transition. If things do not work well within the short transition window, the implications are dire:
- Unacceptable risks. Billions of $$ could be lost if a global financial company cannot start trading on time in Wall Street;
- Severe compliance issues. The executive with whom I speak and his/her company could get in serious regulatory trouble due to a failure to reconcile trades and keep the required audit trail.
The ties of these business imperatives to Agile are straightforward:
- Higher quality code reduces the risk of a ‘glitch’ in the transition of trade from London to Wall Street;
- Should a financial institution suspect a glitch might happen, Agile usually enables Application Development and Operations to fix the code faster than traditional methods;
- And, using virtual appliance technology enables deploying the fix in minutes instead of months.
I usually cite the examples of Flickr and IMVU to demonstrate how fast one can deploy software nowadays. I make it crystal clear that I do not expect a global financial institution today to be able to deploy every thirty minutes or every nine minutes as Flickr and IMVU do. However, I stress that the software industry is clearly heading toward a much shorter cycle between concept or problem identification and deployment. I point out that he/she has an opportunity to be ahead of the power curve, to gain competitive advantage in the market through superior velocity in both development and deployment. Obviously, a faster introduction of a new hedging algorithm could make a big difference for a financial institution.
What do I typically hear from the executive in such a conversation?
The responses I usually get tend to reflect the alignment (or lack thereof) between the financial strategy and the operational strategy a company follows:
- The “cut costs by cutting costs” variety: the discussion revolves around the need to continue to carry out layoffs on a quarterly basis. In this case I stress the life cycle costs of software, asking the executive I am speaking with to answer a tough question: Can you afford the software you are developing? This question often leads the executive to reexamine the balance between the two strategies (financial versus operational).
- The “cut costs by systemically improving the underlying system” variety. The conversation with executives of this mindset usually converge quickly on what is most important to the business: time-to-market, quality or productivity. It is a small step from here to getting into the “hows” of Agile roll-out.
Request for Input
I will be speaking in the forthcoming Agile Roots Conference in Salt Lake City, Utah. The motto for the conference is Rooted in the past. Growing towards the Future. To properly express this motto in my presentation, I would like to embed a broad spectrum of threads and opinions from as many Agilists as possible. Any suggestions made by readers of this blog will be much appreciated.
Podcast in Agile Thinkers
I’ve just spent a fascinating hour talking with Agile Executive Israel Gat. Click here to download the mp3 podcast where you’ll hear about what Israel is up to now, the hugely impressive agile transformation at BMC (we’re talking >1000 engineers), what’s going on in the agile market place, amongst other equally interesting things.
Reflections From Denver
The March 18 Rally event in Denver has been covered elsewhere (see here for links to detailed posts on the subject). This post captures my more important takeaways from the event, based on the panel Q&A session, my own breakout session and various one-on-one interactions during the event:
- Scaling end-to-end: More often than not, Agile is still regarded as an “R&D thing”. Marketing, Sales, Professional Services and other corporate function somehow learn how to co-exist with well performing R&D Agile teams. However, it is an up-hill battle to instill Agile thinking in these functions. In particular, receptivity for developing new business designs based on the capabilities of Agile is very rare.
- Agile contracts: Formal Agile contracts between a company and an outsourcer seem to generally be more advanced than the informal contracts between the business and R&D within the corporation.
- Agile metrics: Reporting meaningfully on Agile projects is problematic due to lack of common language/terminology between folks in the Agile trenches and executives. While the issue is probably true for reporting on software in general, Agile poses harder challenge for executives who have not had the opportunity to assimilate the Agile mindset. The problem seems to be exacerbated due to the “Bobby Fischer syndrome”:
- Passion and objectivity: Bobby Fischer was insanely passionate about chess. However, he was very objective about evaluating his position while playing. Various execs fail to appreciate this distinction with respect to Agile practitioners. One can be very passionate about Agile without affecting his/her objectivity with respect to the development tasks to be carried out.
- Passion and beauty: Peggy Reed‘s passion for software is nicely captured in her quip about Beautiful Software: “Software that people love to be with can’t be done by outsourcing and automation.” Whenever I listen to Peggy I can’t help thinking about the software engineer as a craftsman.
- The real user: Surrogates like the “virtual customer” are being used most of the time. Consequently, innovation through experimentation suffers from lack of authentic feedback.
Different that the Denver event was from Rally’s previous event in Austin, the observations cited above generally apply to both events. As the forthcoming Rally events in LA and NYC pull in practitioners from industries that were not really represented in Austin nor Denver, I wonder what differences will manifest themselves in LA the coming week and NYC next week.
A Note on the Kanban & Retrospectives Post by David Andreson
David Anderson wrote an interesting post on Kanban & Retrospectives. David observes that some seasoned Kanban teams ceased doing “official” retrospectives. To quote David:
Some mature Kanban teams did drop the use of retrospectives. No one told them to do it. They just did. Retrospectives were not adding value in their lives and hence were seen as a wasteful activity that could be eliminated.
David carefully examines retrospectives in the Kanban context. His concluding recommendation is as follows:
Kanban can enable a team to reach a level of maturity where they may choose to eliminate retrospectives (or not.) It’s a choice! Every situation will be unique. The important thing is not to see elimination of retrospectives as wrong or bad or “not agile.” Equally, don’t rush in and eliminate retrospectives. Don’t proscribe retrospectives. Let the team make its own decision when it is ready and embrace the evolution of process that comes with continuous improvement.
I certainly understand where David is coming from and the sound logic of his reasoning. However, the question on my mind is whether core Scrum practices could be reduced without jeopardizing the method. The following excerpt from a recent Cutter Consortium post entitled Breaking the Facade of Truth: An Introspective View into and a Case Study About the “Apparent Truths” of Agile by David Spann nicely summarizes how minimalistic Scrum is:
Scrum, as a management methodology, is elegant in its design, requiring only three roles (i.e., product owner, ScrumMaster, and self-organized team), three ceremonies (sprint/iteration planning, daily Scrum/debrief, and sprint review meetings), and three artifacts (product and sprint backlogs and the burndown chart) — just-enough practical advice so agile teams do not overcomplicate the development lifecycle with too much ceremony and documentation
Can one meaningfully drop a core practice of a just-enough method?
Opinions please!
Software Craftsmanship
In her interview with me for Agile Blog, colleague and friend Jean Tabaka brings up the provocative subject Beautiful Software. I love the concept – it brings out the software craftsman in me:
Israel: I had a revelation many years ago when I first read the Cluetrain Manifesto: The End of Business as Usual. I realized then that I was a craftsman, not an assembly line worker. A true craftsman is proud of the intricacies of his/her work, striving for excellence and elegance while respecting the nature of the medium with which he or she is working. To borrow the title of a recent book, a software craftsman dreams in code. This sense of great discovery I had savored so long ago (while reading the Cluetrain Manifesto) was rekindled in me while I was listening to Peggy [Reed talking about Beautiful Software] .
Both Jean and I will be writing much more on the subject after the March 18 Rally event in Denver in which Peggy will give a panel talk on, well, Beautiful Software.