The Agile Executive

Making Agile Work

Archive for the ‘The Agile Leader’ Category

The “All In!” Approach to Agile Rollout – Austin and Atlanta

with one comment

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.

Written by israelgat

June 13, 2009 at 2:04 pm

More on Kanban from John Heintz

leave a comment »

Colleague John Heintz posted today on the Kanban board he and one of his customers implemented in a few days. John describes the economy of so doing in the following words:

Some of the tools that we use include sticky post-it notes and Stikky Clips. (Note: We found the Stikky Clips at a teacher supply store, not a big office supply store.)

I am impressed: John seems to hit the ground running immediately after the LK2009 conference.

Written by israelgat

May 19, 2009 at 12:18 pm

Posted in Kanban, Lean, The Agile Leader

Tagged with ,

2020 Leadership

leave a comment »

Colleague and friend Pollyanna Pixton has started a 2020 Leadership group. To quote Pollyanna:

These economic times have surfaced new leadership challenges and we have become aware of the need for new tools to lead. Many of us are operating from our experiences, intuition, and wisdom. I would like to create a forum and community to share what we are finding that works and where we are stumbling. Perhaps we can learn together and develop some new tools for these uncertain and future times.

As a starting point, questions we might address are:
– How do we lead innovation and unleash the talent in our organizations?
– How can leaders give ownership (and not take it back) while delivering competitive products to tight market windows and changing marketplaces?
– What works for making better business decisions?
– How do we lead business agility and business transformation?

As appropriate, I will report on the deliberations of the 2020 Leadership group in this blog.

Written by israelgat

May 3, 2009 at 6:36 pm

Posted in The Agile Leader

Tagged with

When an Agile Project does not Seem to be Working

leave a comment »

Colleague and friend Paul Beavers suggested writing a post on this topic. To quote Paul:

… it is clear the [Agile] methodology often gets blamed for poor quality and poor general execution.  The root cause of these problems is not methodology but more the mere implementation of it.  It would  be valuable to read ideas on how to recognize things are not performing and how to keep leading an organization through the tough times. 

Recognizing when things are not working

The post Early Warning Signs highlighted various specific indicators one could use to foresee problems. Examining the same subject from a somewhat different perspective, Jean wrote about Twelve Top Agile Adoption Failure ModesChristophe Louvion has recently conducted a session on the topic 101 Things Leaders do that Kill Team Productivity.  It should be fairly easy to sense that something is not right by consulting theses three sources in conjunction with your own intuition.

A good practice to follow is establishing a base line with respect to the state of your software engineering practices before starting an Agile implementation. Collect and record the data for a metric or two. For example, number of bugs per thousand lines of code is a useful metric for quite a few purposes. When you suspect the Agile implementation might not be working, compare the historical data you collected with current data. You will be able to assess your progress (or lack thereof) on a relative scale instead of an absolute one.

What to do about it

IMHO self-awareness is more than 50% of the solution. It comes in two “flavors”:

  1. If the things that do not work are under your control, start addressing them with realistic expectations in mind. For example, it might take a few months to get an inadequate build process to the point is satisfies the requirements of your Agile process.
  2. When the things that do not work are beyond your control, your task is to make the right folks fully aware of the obstacles. It is a minute of truth for you as an Agile champion: you might need to convey some hard facts to various senior folks in your eco system. It is not too hard to do if you are wholeheartedly convinced Agile is the right thing to do. It is next to impossible to do if you are ambivalent about Agile.

One other thing to do is assess whether Agile is indeed a good fit for your business imperatives and corporate culture. Chances are you had already made this assessment prior to starting Agile. Reassess in view of the actual experience of the Agile initiative.

Written by israelgat

April 15, 2009 at 11:07 am

Addition to the Social Contract

with 3 comments

Readers of the post A Social Contract for Agile might recall the recommendations to the executive championing Agile roll-out amidst layoffs: Commit to invest in Agile training ; apply the training to employees who  might be affected by forthcoming layoffs just as you apply it to those likely to be kept with the company.

Having just read The Living Company by Arie de Geus, I am much impressed by his suggestion how to handle layoffs. He proposes the following line when employees must be laid off:

Yes, the institution is in dire times, and we have to so something about it. One of the things we have to do (having taken some care to reshape our cost structure everywhere) is to eliminate some jobs, including yours. Having said this, we still have an implicit contact with you. Are there other ways to develop your potential that do not stand in the way of developing the potential of the company?

These words of wisdom are anchored in an overarching view of the employer-employee relationship in an enlightened  class of companies de Geus calls river companies. I would contentd his words could be effectively used in any company on two conditions:

  1. The Agile executive is 101% sincere. He/she will do his very best to implement this modus within his sphere of influence. 
  2. The company understands and accepts that the benefits of the Agile executive doing so exceed any downside legal risk.

Written by israelgat

April 11, 2009 at 10:41 am


leave a comment »

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.

Written by israelgat

March 28, 2009 at 7:56 pm

Being Your Own Forcing Function

with 2 comments

A fascinating thread is becoming evident in many of my discussions with the penalists for the forthcoming Rally events in Denver, LA and NYC. I have de facto become a forcing function for panelists to take a good look at their Agile journey, to think deeper on the experience and to come to grips with difficult lessons. As I am careful not to interject my own thoughts in these pre-panel discussions, my forcing function effect is primarily a Google Calendar invite creating quality time for a vice president and some members of his staff to think aloud on their experience.

Suggestion: No matter how many Agile retrospectives you have already conducted, set a short meeting with your staff to brainstorm on your Agile experience in entirety. The action item from this meeting is creating a 10 minute presentation which summarizes your experience in a way that will be meaningful to other Agilists and executives. Once you got the presentation ready, post it in one public forum or another and solicit feedback.

It might sound naive, but I believe you will be nicely rewarded by being your own forcing function for this kind of reflection. It is that simple.

Written by israelgat

March 2, 2009 at 1:19 pm

Posted in Events, The Agile Leader

Tagged with ,