The Agile Executive

Making Agile Work

Posts Tagged ‘Agile

Preface from The Concise Executive Guide to Agile

with one comment

ICS_black_stacked.jpg

The good folks at the IEEE Computer Society are just about ready to publish my e-book The Concise Executive Guide to Agile. It will be available for purchase in the Computer Society store in May. A Kindle version will follow in June.

Here is the preface from the guide:

Preface: Connecting the Agile Dots

“The closer one listens to it, the more distantly one hears it.”[1] These insightful words about Schubert’s Unfinished Symphony apply equally well to the art of Agile software methods. The nuts and bolts of Agile methods are not likely to be very relevant to the executive. Instead, he or she needs to stand back and focus on the mindset, values, and principles that make Agile methods so powerful, and on harnessing their power to create business value.

It is the objective of this guide to provide the know-how for approaching Agile in a concise manner that requires minimal investment of time and effort by the reader. It does so by summarizing most Agile topics in a page or two with minimal use of geek jargon. Detailed coverage of a topic is left for follow-on reading in the selected references that accompany each topic and in the Further Reading appendix.

The guide targets executives as the primary audience. It gives them the principles they need to comprehend and apply in order to become effective with an Agile initiative. These executives are not necessarily software engineering experts. They come from any function that Agile affects — R&D, Marketing, Sales, Program Management, Professional Services, Customer Support, Finance, or IT. Nor are the executives restricted to companies whose business is software; they are as likely to reside in companies that embed software in their products or utilize software in implementing business initiatives. Nowadays one can hardly think of a company that would not be included in at least one of these three categories.

Four broad topics are covered in The Concise Executive Guide to Agile: rationale for Agile, implementing it, fitting it into your company, and scaling it to the enterprise level. The rationale explains why Agile is so appropriate for our time, summarizes the state of the art in Agile, and sets realistic expectations with respect to its business value. Implementing addresses critical “real life” issues such as risk assessment and mitigation, off-shoring and outsourcing, governance, and sustainability of the Agile initiative. Fitting connects Agile to the hard realities of introducing a new software method into an environment in which various processes already exist — multiple software methods as well as planning and budgeting processes. Scaling is primarily about the numerous benefits to be attained through end-to-end implementation, such as enabling new business designs that fully utilize the power of Agile.

In the course of covering these four topics, the guide puts special emphasis on the operational, financial, and business benefits of Agile methods. The overarching message is clear and simple: Agile is the most productive technology your business is not using.


[1] Giuseppe Sinopoli. “Dream and Memory in Schubert’s ‘Unfinished.’” Program Notes to his recording of the symphony with the Philharmonia Orchestra, Deutsche Grammophon 410 862-2, 1984.

Advertisements

Written by israelgat

April 12, 2010 at 4:35 am

Definition: Agile Methodology

leave a comment »

Agile Methodology is actually a bit of a controversial termVarious authors consider Agile a method, as distinct from a methodology. Others, prefer methodology over method. For example, using the Merriam-Webster dictionaries, Alistair Cockburn makes the following distinction between methodology and method in Agile Software Development: The Cooperative Game :

  • Methodology: A series of related methods or techniques
  • Method: Systematic procedure

Alistair views Agile as a methodology in the sense defined above. For example, he discusses Crystal as a family of methodologies. The reader is referred to Alistair’s book for a an excellent analysis of the various aspects of methodologies. As a matter of fact, Alistair tracks down the confusion between method and methodology to certain inconsistencies between various versions of the Oxford English Dictionary.

On the other hand, best I can tell from various conversations with him, Jim Highsmith seems to prefer the term Agile Method. This preference is reflected in Agile Project Management: Creating Innovative Products. It is possible that Jim’s preference is due to writing his book from a project management perspective.

Rather than getting in-depth to the method versus methodology controversy, I would simply cite two definitions I find useful in capturing the essence of Agile methodology, or method if you prefer.

An interesting metaphor for Agile has been used by Jim Highsmith in a 2009 Cutter Advisory:

Visualize a house structure with a roof, a foundation, and three pillars… The roof is business goals — the rationale for implementing agile methods and scaling to larger agile projects. The foundation is agile values or principles — principles that need careful interpretation as to how to apply them to larger teams. And finally, the three pillars: organization, product backlog, and process/practice.

The simplicity of the metaphor makes it quite effective in communicating what Agile is in a concise way without losing the richness of the various elements in Agile.

Using Scrum as an example, colleague David Spann gives the following down-to-earth summary of the key structural components of Agile in a 2008 Cutter Executive Report:

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.

Needless to say, the structural elements will change from one Agile methodology to another. However, examining an Agile methodology through the {roles, ceremonies, artifacts} “lens” is an excellent way to summarize an Agile methodology. Furthermore, it enables easy comparison between the ‘usual suspects’ of Agile – Crystal Methods, Dynamic Systems Development, Extreme Programming, Feature Driven Development, and Kanban. The reader is referred to The Business Value of Agile Software Methods: Maximizing ROI with Just-in-Time Processes and Documentation for detailed comparisons between the various methods/methodologies.

John Heintz on the Lean & Kanban 2009 Conference

with 23 comments

Colleague John Heintz has kindly compiled the summary below for the benefit of readers of The Agile Executive. John is well known to Agile Austin folks as well as to out-of-town/state companies to which he consults through his company. You can get a glimpse of his Agile/Lean thinking by reading his blog.

Here is John’s summary of the conference:

The Lean Kanban conference last week in Miami was astounding. David Anderson did a fantastic job, and everyone who contributed had great presentations.

I am humbled and emboldened at the same time. I’ve been involved in Agile since 1999 and Lean since 2004, so I thought this was going to be familiar to me, old hat.

Here’s my confession: I’ve pretty much ignored Kanban, writing it off as just slightly different than what good XP or Scrum teams practice anyway.

Wow, those small differences make a huge impact. I am very glad I decided to go to the conference, some internal hunch finally winning.

Here’s what I thought Kanban was before last week:

  • A Big Visible Board
  • A Prioritized Backlog
  • Close communication, minimizing hand-offs
  • Rules about cards on the wall

No Iteration/Sprint boundaries (I’m thinking more efficient but maybe losing something important…)

That’s all well and good and true enough. Easy to justify writing it all off with “I already know enough to help teams make a big difference”. In fact, Kanban can be boiled down to one single rule:

  • Limit the number of things in work to a fixed number.

But, if that’s all there is too it, why then did I hear things like these:

  • Kanban is easier to introduce to teams than Agile/Scrum/XP
  • “People who never say anything were offering ideas” (I’m pretty sure I heard this three time the first day…)
  • The team felt comfortable dropping estimates/retrospectives/standup questions/…

Wait, you say, this was the first conference and obviously full early adopters! Of course people are going to succeed because they self-selected for success. Good point, but that’s not everything that’s here. For example, Chris Shinkle’s presentation was a case study of rolling out Kanban to many teams who hadn’t asked for Kanban.

So between furiously scratching down notes[1], listening and tweeting[2], I started to think to myself:

  • Why does this make such a difference?
  • Easier to create thinking and reflective teams! Isn’t that cultural change?

I had the pleasure of wrestling this “why” question out with several people, especially Alan Shalloway.

The first answers people gave me were entirely unsatisfying:

  • David Anderson’s reply tweet: “Kanban is easier than Scrum because you don’t change any roles or workflow and you don’t teach new practices.”
  • Alan Shalloway first response: “Kanban cuts out the noise and reduces thrashing.”

Sure, sure, but none of those (good) things seem likely to create: cultural change, engaged teams, or reflective individuals. Those answers are technical, details, and generally not the “emotionally” important things needed for change. Mind you, I’m not really well versed in cultural or emotional change, but being the stubborn person I am, I kept digging.

Here’s where Alan and I got, please add any insights[3]:

  • My hypothesis: Kanban has concrete reflective tools: like “should WIP be 4 or 5?”. Very reflective, but not very abstract or hand-wavy. People can’t often use abstract reflective tools like Retrospectives.
  • Paraphrasing Alan Shalloway: Kanban reduces the fear of committing to a per story estimate – a significant risk in some teams. Less fear can lead to cultural change.
  • (not sure who): Kanban changes the focus away from blaming an individual to examining why stuff is stuck on the board. (I hear Deming…)

—-
On to the actual trip report. Here is an abbreviated transcription of the proceedings of the conference. (Very abbreviated!)

  1. Alan Shalloway started the conference off with no small announcement: the formation of the Lean Software and Systems Consortium. He also mentions that this consortium will be creating a body of knowledge and promoting a distributed certification process. Certifications will be a very interesting topic, my initial reaction was negative. Now I’m just skeptical 😉 I’ve got a hunch that TWI, a hidden influence of Lean, may hold some of the secrets for a successful certification method. We’ll see how this plays out.
  2. Dean Leffingwell gave a keynote on a Lean and Scalable Requirements Model for Agile Enterprises. Very clear from executives down to team activity: maps from Themes to Epics to Features to Stories. This immediately cleared up some questions I and a client were having.  My favorite quote: “If you don’t know hot to get the story out of the iteration – don’t let it in” referring to acceptance tests.
  3. Peter Middleton presented material from “Lean Software Strategies“, co-authored by James Sutton who presented next. Peter is a professor at Queen’s University in Belfast and was the first person to really talk about the people issues. Much of what Peter related was how various practices caused people problems: recruiting and training goals (10 per week) would require recruiters and trainers to push even unqualified people into the company. That led to poor service, high-turnover, and greater costs.
  4. James Sutton has a small personal goal: to save the middle class. His presentation did a good job ranging over various Lean and Systems thinking topics, connecting the dots to Agile. Key quote comparing Lean and Agile: “Getting Prepared” vs “Getting Started.
  5. Sterling Mortensen presented a case study of introducing Lean into the Hewlett Packard printer development division. He said HP was already the “best of breed” and still became much more efficient and effective. My favorite quote: “Stop Starting, Start Finishing“. Sterling also said the “One” metric was continuous Flow. I’m not sure I understand that all the way; I’d been working under the assumption the One metric was customer to customer cycle time (from concept to cash.)
  6. Amit Rathore gave a personal case study of Lean in a start-up, http://runa.com. Amit showed many examples and talked really honestly about his experience. My favorite quote: “not released equals not done”.
  7. Corey Ladas presented on his book Scrumban and his experience at Corbis (with David Anderson) and other projects. I bought a copy of his book out of his backpack and made him sign it.
  8. Jean Tabaka presented a thoughtful presentation on Lean, learning, ignorance, and people. Her narrative helped me further realize how Lean, and Kanban, play into the personal issues of learning and reflecting.
  9. Alina Hsu presented a case study of using Lean to organize the work of procuring a COTS (commercial off-the-shelf) software solution, not development. She had some great things to say about how delays cause major cost overruns. One thing that reduced the delays she mentioned was to change how agreement was reached. The team defined consensus as “I can live with it”, with the rules 1) I won’t go into the hall and try to subvert it, and 2) I won’t lose any sleep. These definitions help teams make decisions faster and reduced waste.
  10. Alan Shalloway presented on a model for understanding Lean and moving it beyond Toyota. He organized all the various concepts down into Lean Science, Lean Management, and Lean Education. Connecting this back to the Lean SSC announcement in the morning he said the consortium working to create value in those three areas.

And that was just the first day. Did anybody mention the conference day started before 8am and lasted till after 6pm? Oh, and everyone was glued into the room.

  1. David Anderson presented a keynote on the principles and evolution of Kanban. So much information! You’ll have to read his presentation and see the video on InfoQ, but just to provide a fragment from each I wrote down:
    • Principled recipe for success (including Balance Demand Against Throughput)
    • Metrics (like WIP is a leading indicator)
    • Agile Decision Filter questions
    • Lean Decision Filter questions
    • Kanban decouples input cadence, cycle time, release cadence
  2. Karl Scotland continued the detailed treatment of Kanban. Karl spoke about the Lean concept of Flow as expressed with Kanban – and even rename typical process steps to avoid any baggage with waterfall terminology. If you want to know more about how work actually gets done in a Kanban system, watch his presentation. His interesting names for for process steps are: Incubate, Illustrate, Instantiate, Demonstrate, Liquidate.
  3. Rob Hathaway presented a case study of his work building a game portal for a publishing business. He believed very strongly that teaching from principles (Value, Prioritization, WIP limits, Quality) led to success.
  4. Alisson Vale presented a tool… that enchanted everyone in the room. David Anderson himself said that Vale “has the highest maturity software team on the planet”. Now, tool support often isn’t the answer, and many teams get real value with a physical board – a tool isn’t a Silver Bullet. If a tool makes sense for you – this tool absolutely blew us away. I asked Alisson about buying or helping with the tool and he said they were considering open sourcing it! I offered my coding skills in extending it for my own clients to help reach that goal.
  5. Linda Cook presented a case study of using Kanban at the Motley Fool. Her presentation does a good job of showing how little is necessary to get a lot of value out of Kanban.
  6. Eric Landes gave a great case study about using Kanban in an IT development shop. His team went from struggling to turn requests around (41 days) to a rapid 9 day turn around. Again, his discussion of the team dynamics and reflection were interesting to how a tiny bit of Kanban can have a huge impact.
  7. Eric Willeke’s presentation was visually beautiful, but you’ll have to watch the InfoQ video to get the value out of it. It contained only two words in a quote bubble (from memory “Momma! Pirates!”) and was the backdrop for the story that he told. His story highlighted to me, again, that Agile doesn’t always stick but Kanban seems to.
  8. Chris Shinkle presented a multi-case study on rolling Kanban into a large software consultancy. Very interestingly, and contrary to much discussion before, Chris presented a practices first, principles later message. This again resonated strongly to me that Kanban practices are somehow special in encouraging people to reflect and reach for the principles.
  9. David Laribee presented an opinionated view on leadership and change using Lean. This quote stuck with me: “people support a world they help create”. His style of leading is to drive from “Values -> Practices -> Tools” and his presentation wove a story of Agile/Lean process change. Also, I really enjoyed his injecting reference to hardcore technologies: REST, Git and OSGi were fantastic to see in a Lean/Kanban presentation.

That was day two. I’d said we were all glued to the room before, now as I type this I realize our brains were coming a bit unglued at this point. Every presentation was top-notch, barely time for questions, breaks were cut short, and we came back for more as fast as we could. Oh, and apparently we collectively drank 2.5 times as much coffee as the hotel usually allocates for a group our size.

I’m not going to summarize the Open Space. Too many topics and changes in direction. You just had to be there 🙂

Cheers,
John Heintz

[1] I used the first 25 pages of a brand new notebook… for a 2.5 day conference… Every session had an overwhelming amount of information, and I’m glad InfoQ recorded video.
[2] My twitter account is http://twitter.com/jheintz, and you can follow everyone’s conference coverage at http://twitter.com/#search?q=%23lk2009.
[3] I’m going to keep following up on this topic in my personal blog: http://johnheintz.blogspot.com

Observations from Houston

leave a comment »

The Houston chapter of APLN arranged an Agile track in the April 30-May 1, 2009 PMI Houston Conference. I had the pleasure of participating during much of the the first day. Following are my major observations from the conference in chronological order:

General: Agile awareness was quite broad amongst participants irrespective of whether they do or do not do software. Just about every project/program manager I had the opportunity to speak with was aware of Agile and anxious to learn more. Many questions to the panel were about Agile. Some asked specifically about applying Agile beyond software. For example, one of the questions posed was:

What does Agile have to offer to a major oil company?

Metaphor for the Agile PMO: Jochen Krebs compares the functioning of the PMO to that of the information booth in Grand Central Terminal in NYC. Hundreds of thousands of people go through the station every day on their own – they are motivated to reach their train and they generally do find their way. If they need help they ask for it, trusting the information booth to give them pertinent and reliable data.

Motivation for adopting Agile: AOL’s transition from a single brand to multiple brands (e.g. AOL Food, AOL Music) was a major factor in their going Agile. Pretty much every brand has its own Agile project team now. (Click here for details on AOL’s branding strategy).

Going live: The product owner at AOL makes the final call whether to deploy (or to hold off on deploying) new functionality or contents.

Agile training: AOL invests 5 days of training/consulting/coaching in each team converting from waterfall to Agile. Training is given in the organic project teams (as distinct from open courses to which anyone can enroll). Newly converted teams are expected to operate on their own (i.e. without consultants) after three iterations.

View from the panel on primary reasons for project failure:

  • Lack of alignment.
  • Folks do no tell the truth. To succeed, one must be brutally honest.
  • Poor expectation management.

View from the panel on ingredients in the ‘secret sauce’ for project success:

  • The project/program manager has to be both humble and willful.
  • Acting on insights gained in the retrospectives is critical.
  • Must know the real status at any point in time. For example, what do the employees think on the subject? What do customers say?

Visualization: Deemed absolutely critical to requirements management in any project of scale. It is the antidote to explosion of requirements data and confusion about requirements (Tony Chen, Seilevel).

Reconfiguring the Business: Readers of this blog are already familiar with many threads in the Reconfiguring the Business presentation I delivered. Click here to read it in entirety. Needless to say, comments on the presentation will be much appreciated.

Written by israelgat

April 30, 2009 at 10:35 pm

Scaling Agility: From 0 to 1000

with one comment

Walter Bodwell delivered an excellent presentation on the subject in Agile Austin last night. The presentation is quite unique in seeing both the “forest” and the “trees”. Walter addresses the operational day-to-day aspects of Scrum in the trenches in parallel with providing insights on the roll-out at the executive level. Highly recommended!

Written by israelgat

February 4, 2009 at 9:25 am

Allocating Your Agile $$

leave a comment »

“50-50” is the rule of a thumb many audiophiles use for configuring a good stereo system. 50% of the budget goes toward the speakers; the other 50% toward everything else in the stereo system. The reason is quite simple: stereo systems succeed or fail on the merits of the speakers.

Whatever your Agile budget might be, a good starting point is to spend about 50% of the budget on training, consulting and coaching during the first year of Agile rollout. This figure will probably go down to about 25% during the second year;  precious little thereafter. Such budget allocation was used at BMC Software in its Agile rollout and operation between 2004 and 2008: about 50% of the total Agile budget in 2005; 25% in 2006; single digit percentages in 2007 and 2008.

First Year Agile Budget

Starting with 50% for consulting, training and coaching during the first year is rooted in the software engineer being a craftsman. A craftsman learns and develops through apprenticeship. He learns from the masters. The popular Program With the Stars sessions  in various software development conferences recognize the power of the apprecnticeship paradigm. A good review of the power of such a session in the Agile 2008 conference can be found in the Working Together… with Technology post by Andrew Shafer.

If you accept the premise of the software engineer as a craftsman, you need to invest  in consulting and coaching more than in training. A two or three day Scrum Training class for numerous product managers, developers and testers in your company is, of course,  a good start. However, it is the day-in day-out consulting and coaching that will make the training applicable. There is no substitute to a competent Agile coach saying in the middle of a stand-up meeting “Folks, what happened to our collaboration? We are not getting the benefits of the wisdom of teams.”

In addition to the coaching needs of the teams, you as an Agile executive will probably need some coaching by a sure-footed Agile executive coach. Topics should include the following:

  • Your role in the Agile roll-out
  • Deliverable you own in the Agile roll-out
  • Behaviors that are supportive of Agile
  • Identification of promising indicators for Agile roll-out
  • Identification of early warning sign for Agile roll-out going the wrong way
  • Synchronizing release trains across multiple software development methods
  • Impact of Agile on downstream functions

Don’t think about these coaching items as luxury you can’t afford. Rather, it is money well spent. It is the cost you as an executive need to pay for being on the Agile train. The train might leave the station without you if you do not invest in your Agile education.

Second and Third Year Agile Budgets

The rationale for reducing the investment in consulting, training and coaching in the second and third year is simple. Various Agilists in your company would become experts themselves. Needless to say you will continue to invest in their skills by sending them to a conference such as Agile 2009. Much of the consulting and coaching, however, should over time be done by your home-grown Agilists.

Consider it an early warning sign if the assimilation of expertise in your company has not generated Agile experts in your teams within a couple of years. You could, of course, allocate your Agile $$ in the second and third year on the 50-50 basis recommended above for the first year. But, chances are something is not working well with your Agile roll-out.  The norm in successful Agile roll-outs is to harvest a whole bunch of quotes like the following quip made in 2006 by a QA Director with BMC Software:

 There had never been a thought towards returning to Waterfall. We only think about how to be more Agile, how to do this better. No one wants to go back!

Written by israelgat

January 22, 2009 at 10:47 am

Your Battle of the Somme

leave a comment »

The 1916 Battle of the Somme is considered to be a disaster of the first order in the annals of British military history. By the end of the first day on the Somme, the butcher’s bill amounted to 60,000 British casualties. When the offensive tapered off after four and a half months of repeated attacks, the bill grew to 420,000 British casualties. “The thing is terrible”, said Lloyd George – Britain’s prime minister at the time – “and beyond human nature to bear, and I feel I can’t go on any longer with the bloody business.”

The contrast between the meticulously prepared battle plan on the one hand, and  the meager results the offensive achieved on the other hand, has been the subject of numerous studies since WWI. One of the most important factors that emerged in years and years of research is the lack of timely feedback. Front line troops did not have the means to report their situation to the immense military machine behind that was supposed to support them. As a result, combined arm tactics collapsed. For example, the rigid fire-plan for the rolling artillery fire dictated moving the barrage forward at a predetermined pace. The pace, arguably, had taken into account a realistic rate of progress by the infantry. As the British infantry in most cases got bogged down fairly quickly, after a short while it lost the benefit of close artillery support. Highly inspired that the British infantry was, courage under fire only led to astronomical casualties.

It is easy to attribute the blame to inadequate communication technology. After all, a few cell phones would have made quite a difference. Tempting that such attribution is, it ignores a deeper truth – the people over process truth.

The vast majority of British troops in 1916 consisted of “Kitchener armies” – citizen soldiers who came to the flag to replace the regular British army that got decimated in the first few months of the war. Though trained for battle during 1915 and the first half of 1916, the inexperienced troops were not trusted by the general staff that toiled to prepare a magnificent battle to end the war. The battle plan mandated  moving forward upright and in straight line, wave after wave. The perceived “danger” of the troops taking cover and not restarting the advance once they had laid down precluded any tactical initiative and flexibility.

Fast forward to software engineering today. I can certainly appreciate the complexities and risks involved in moving from Waterfall model to Agile software development. For example, your teams might not be sufficiently trained and coached in Agile methods. Naturally, you do not want to change the software process before a certain level of competence using Agile processes has been attained. At Digital Equipment Corporation we used to call it the monkey on the tree phenomenon. Tempting that a new branch on the tree might be, a monkey does not hop over from one branch to another if the prospect of falling down between the two branches is high.

Various obstacles to starting an Agile roll-out, let alone an enterprise level Agile roll-out, could indeed be standing in your way. I would, however, encourage you to pay special attention to your deeper feelings with respect to your “troops”. In your heart of hearts, do you really trust your troops? Do you believe requirements should be dynamically moved between release and backlog in response to the latest insights gained in the trenches? Do you expect product innovation to come from repeated experimentation at the individual team level? Is it acceptable to you to follow the technical intuition of a young and talented developer?

If you have not yet started training some of your product management, development and test resources in Agile methods, I suspect trust, and her twin brother control, might be the core issues you or your company are wrestling with.

Written by israelgat

January 16, 2009 at 11:50 am