The Agile Executive

Making Agile Work

Posts Tagged ‘Michael Cote

Make the Hairs on the Back of Your Neck Stand Up

with 9 comments

Cote sent me the recent CIO Magazine article entitled ERP’s Paralysis Problem and the Repercussions for Business Everywhere. The article discusses the findings from a December 2009 study conducted by IDC and sponsored by ERP vendor Agresso, as follows:

A couple of verbatim responses from respondents should make the hairs on the back of your neck stand up: “Capital expenditure priorities are shifted into IT from other high-payback projects” just to perform necessary ERP changes, noted one respondent. Said another: “Change to ERP paralyzes the entire organization in moving forward in other areas that can bring more value.”

To make doubly certain the message gets across, the article finishes with the following “nocturnal” paragraph:

As the sun finally sets on the first decade in the new millennium, it’s high time we say good night to ERP. A new day will be starting soon, and the blemished legacy and failings of ERP’s nearly four-decade-long reign will be a distant memory.

Maybe. While ERP systems no doubt have their own particular twists, the sorry state of affairs described above is true of various industries that have developed complex software systems over prolonged periods of time. Just in the past few months I have witnessed such situations in banking and health care. In previous life I had been exposed to more of the same in other industries. The software decayed and decayed but technical debt had never been reduced. Consequently, the cost of change, any change, today is horrendous. As Jim Highsmith‘s chart below indicates, “once on the right of the curve, all choices are hard.”

in-can-you-afford-the-software-you-are-developing

In Estimating Software Costs, author Capers Jones quantifies five-year cost of software application ownership (for the vendor). He examines three similar applications, each of nominal size of 1000 function points, as a function of the sophistication of the corresponding projects. The respective life cycle costs are as follows:

  • Lagging projects: $2,316,000
  • Average projects: $1,860,000
  • Leading projects: $1,312,000

Jones goes on to issue the following stern warning:

All known compound objects decay and become more complex with the passage of time unless effort is exerted to keep them repaired and updated. Software is no exception… Indeed, the economic value of lagging applications is questionable after about three to five years. The degradation of initial structure and the increasing difficulty of making updates without “bad fixes” tends towards negative returns on investment (ROI) within a few years.

Enough, indeed, to make the hairs on the back of your neck stand up…

Advertisements

Predicting the Year Ahead

leave a comment »

Cutter Consortium has published predictions for 2010 by about a dozen of its experts. My own prediction, which examines the crash of 1929, the burst of the “dot-com bubble” in 2000 and the financial collapse in 2008, is actually quite bullish:

I expect 2010 to be the first year of a prolonged golden age. Serious as the various problems we all are wrestling with after the 2008-2009 macro-economic crisis are, they should be viewed as systemic to the way a new generation of revolutionary infrastructure gets assimilated in economy and society.

In addition to the techno-economic view expressed in the Cutter prediction, here are my Agile themes for 2010:

  • Agile moves “downstream” into Release Management.
  • Agile breaks out of Development into IT (and beyond) in the form of Agile Infrastructure and Agile Business Service Management.
  • SOA and Agile start to be linked in enterprise architecture and software/hardware/SaaS organizations.
  • Kanban starts an early adoption cycle similar to Scrum in 2006.

Acknowledgements: I am thankful to my colleagues Walter Bodwell, Sebastian HassingerErik Huddleston, Michael Cote and Annie Shum who influenced my thinking during 2009 and contributed either directly and indirectly to the themes listed above.

Agile Across the Enterprise: Prioritizing Value in Support and Training – Guest Post by Anne Gentle

with 6 comments

If I could choose a subtitle to Anne’s guest post, I would pick How to Produce a Book in Five Days. While this subtitle does not take into account preparatory work prior to the five days, it captures the essence of the revolution in social publishing. The  intensive collaborative authoring that takes place during book sprints leads to hyper-productivity that transforms the economics of various classes of books.

A thread of particular interest in the post is the path innovation took. Anne walks us from Cote‘s simple question “Why does it take three days to get a PDF out for review?” all the way to producing over 250 pages of documentation in a book sprint. Her story is a great proof point that Experimentation Matters.

Here is Anne:

One of the Agile Manifesto’s basic balance equations is valuing working software over comprehensive documentation. This line of the Agile manifesto can be confusing to some supporting roles in an Agile development enterprise. As technical support staff, trainers, and content creators, what are we doing to fit into this Agile methodology, and what’s working well? Let’s explore some old habits that need to die, and some new rituals to fill that space.

Nowadays, Google’s search power offers software users access to documentation through forums, mailing lists, even through blogs and wikis maintained by the developers and authors themselves. These new conversational methods for documentation, support, and education have opened new opportunities for those groups to add value to software adoption. Ways to provide additional value to the working software include helping people learn the software, troubleshoot the software, or do their job with the software. Education, uptake, and support are all integral to the overall value of a software product.

Value proposition

First, a discussion on the value added by good websites, updated and relevant training materials, and a helpful support staff.  Those departments want to avoid the continual cost center perception. To do so, they find ways to add to the bottom line, such as:

  • increasing sales (enterprise) or increasing adoption (open source)
  • keeping users happy and satisfied
  • adding contributors to the community, whether helpful troubleshooters or prolific coders
  • decreasing support costs (in time and money)
  • converting participation into value
  • increasing positive perceptions of the software

In my experience, these values are universal to both enterprise software and open source software. Let me share my story.

Wikis are an Agile tool

I have been a technical writer on Agile development teams, and working in tightly collaborative environments has taught me a lot about adding value in the customer’s perception. I still remember being challenged by Michael Cote when we were at BMC Software. He asked, “Why does it take three days to get a PDF out for review? Why aren’t technical writers using wikis for documentation?” Those questions prompted quite a bit of research that finally resulted in my book, Conversation and Community: The Social Web for Documentation.

I had a lot to learn to answer Cote’s questions. What to do? I decided a wiki apprenticeship was the answer. At the time, wikis seemed to be the realm of open source software. I was nervous about approaching an open source project with so little experience in open source to draw from, but when a former BMC director sent out a call for help with the One Laptop per Child project, I responded. They had a draft started and we put it on the wiki.laptop.org wiki to start with, as a too-long single article on the wiki. Soon after, FLOSS Manuals approached OLPC to see if they would like to have FLOSS Manuals host the wiki on their wiki site at www.flossmanuals.net. Adam Hyde, the founder of FLOSS Manuals, had built a wiki tool that allowed multiple chapters to be output as HTML or PDF. When I saw what the tool could do, I jumped at the chance. We copied and pasted the entire manual into the FLOSS Manuals site. Yes, copy and paste. But it got the content into a platform that enabled much more agility for the content.

Book sprints are one Agile method

After that initial content seeding, we discussed holding a book sprint to create a better book for more audiences, especially since SugarLabs had formed an organization separate from OLPC to work on the operating system separately from the hardware. A book sprint, much like the Agile sprint term, is intensive collaborative authoring in a week’s time. We run sprints as a five-day event, and use real-time collaboration tools, and sometimes bring all the authors in to a single location and have a bullpen of sorts. Lots of planning goes into a book sprint prior to the actual sprint, such as identifying sources of content that can be repurposed for the sprint, agreeing to the audience for the resulting documentation, and writing an outline for the deliverable, whether it’s intended to be a textbook, a curriculum workbook, an online help system, or a website.

After a sprint planning session on the Sunday of the sprint week, authors are ready to start writing immediately because the outline for the book is set in the wiki. Often we outline with Post-it notes on the wall to start, a familiar sight to many Agile practitioners.

Monday, Tuesday, and Wednesday are heads-down writing days from about nine in the morning until an enforced stop time at six each day. Just like a stand-up meeting, we use a daily conference call to stay in touch with the handful of remote contributors and find out if anyone is stuck or has questions. Thursday is a day for assessing how much we have so far, and what final tasks should be done to make the sprint a success. Thursday night we intentionally plan for a fun event, as the writers certainly have experienced an intense effort like no other and need to have some fun and allow for a release of built-up pressure! Friday is a clean-up and review day, and the final PDF is uploaded to Lulu.com for creating a bound book. We can also export the wiki content to HTML, and either embed it on a website or ship it with the software product itself. In the book sprint for OLPC and SugarLabs, we produced over 250 pages of documentation. You can learn more about book sprints (including examples of the budget for this sprint) by reading the free chapter from my book, or by reading the book about Book Sprints hosted on FLOSS Manuals.

In my journey towards Agile value-add across the enterprise, I learned that wikis are much more likely to be used internally for collaboration, and that there are far fewer examples of wikis where customers and Agile team members are collaborating on training materials, tutorials, reference information, or strategy guides for enterprise software. To shift that adoption rate towards external collaboration, I’m interested in book sprint experiments in the enterprise, as well as additional collaboration methods. Along the way, I’m finding ways to transfer lessons learned in open source to corporate environments. I offer this story as one way that Agile methods applied to other departments and their processes can increase overall value to the software developed.

About the author: Anne Gentle works as a senior technical writer at Advanced Solutions International in Austin, Texas on an Agile development team. She just finished a book with XML Press about using social publishing techniques for technical documentation titled Conversation and Community: The Social Web for Documentation. She volunteers as a documentation maintainer for FLOSS Manuals, working on manuals for One Laptop Per Child and SugarLabs, both education projects dedicated to providing technology for children in developing countries. She writes a blog at justwriteclick.com and welcomes feedback and conversation there. As the mom of two young boys, she loves to be busy while upholding the value of an Agile principle of individuals and interactions (and sometimes refereeing battles over toys).

An Update on Agile Business Service Management

leave a comment »

A previous post in this blog defined the demarcation line between The Agile Executive and BSM Review as follows:

If software development is your primary interest, you might find my forthcoming posts in BSM Review go a little beyond the traditional scope of software methods. If, however, you are interested in software delivery in entirety, you are likely to find good synergy between the topics I will address in BSM Review and those I will continue to bring up in The Agile Executive. Either way, I trust my posts and Cote’s will be of on-going interest to you.

Since writing these words, I realized how tricky it is to adhere to this differentiation. The difficulty lies in the “cord” between development and operations. Development needs to devise algorithms that take into account operational characteristics in IT. Operations needs to comprehend the limits of such algorithms in the context of the service level agreements and operational level agreements that had been negotiated with their customers (either external or internal). The mutual need is particularly strong in the web application/web operations domain where mutual understanding, collaborative work and joint commitment often need to transcend organizational lines.

Given the inherently close ties between development and operations, here are some BSM Review articles and posts that are likely to be of interest to readers of The Agile Executive:

It is a little premature at this early stage to project how BSM Review will evolve. My hunch is that forthcoming articles in BSM Review on cloud computing, large-scale operations, leadership, risk mitigation and technology trends will be of particular interest to readers of this blog.

Between Agile and ITIL

with 4 comments

You do not need to be an expert in Value Stream Mapping to appreciate the power of speeding up deployment to match the pace of Agile development. By aligning development with deployment, you streamline “production” with “consumption.” The rationale for so doing is aptly captured in the first bullet of the Declaration of Interdependence:

We increase return on investment by making continuous flow of value our focus.

As pointed out in previous posts in this blog, Flickr and IMVU seem to be doing an exceptionally fine job streamlining the flow of value: every thirty minutes and every nine minutes respectively. A recent presentation in Velocity 2009 by John Allpsaw and John Hammond adds color how development and operations at Flickr cooperate to accomplish “10+ deploys per day.”

What does such fast pace mean to the business? In a nutshell, much of the guess work as to what features are really needed is eliminated when you develop, deploy and collect customer feedback in ultra fast manner. Consequently, the company’s business design is likely to be transformed. Click here, here, and here for more detailed discussions how the business design gets transformed.

Michael Cote, Andrew Shafer and I have been pondering  about aligning development and operations for quite sometime. On the one hand, we are painfully aware of the traditional desire to minimize change in IT operations. On the other hand, we are of the opinion Agile principles are quite applicable to operations. We often wonder whether the obstacles between Agile and ITIL are real or imaginary. We actually believe the {development –> operations} theme is an important instantiation of Dean Leffingwell‘s recent thoughts about applying Agile/Lean principles to other knowledge work.

The three of us – Michael, Andrew and I – decided to do a few podcasts to explore what stands between Agile and ITIL. The first of these podcasts will be published this month (July 2009).

Stay tuned…

Written by israelgat

July 7, 2009 at 7:19 am