The Agile Executive

Making Agile Work

Archive for the ‘The Agile Leader’ Category

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

Authenticity

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 ,

A Social Contract for Agile

with 10 comments

How do you make Agile work in spite of layoffs? The following war story is pertinent.

During the 1967 war between Israel on the one side and Egypt, Jordan, and Syria on the other, my paratroop battalion carried out a helicopter raid on the Egyptian artillery in Um Katef. The raid was quite successful in neutralizing Egyptian artillery fire which was playing havoc with the Israeli infantry. We incurred, however, quite a few casualties as a result of firing bazookas at Egyptian ammunition trucks. The resultant explosions created an inferno that proved lethal to Egyptians and Israelis alike. We retreated when the Egyptians sent in reinforcements to reign us in. We carried back our wounded in dunes in which you sink to your knees even if you are not carrying anything. Also, we carried back our dead. The dead continued to be part of us in spite of not being with us anymore.

The relevance of a paratroop raid some 40 years ago in the Sinai desert to Agile practices in software circles today might appear to be tenuous.  This post takes the view that the two – paratroop units and Agile teams –  are actually quite similar from a leadership perspective. It is next to impossible to get soldiers over the top if they suspect they might be left behind on the battlefield if they were wounded or killed. Likewise, empowerment, collaboration and the willingness to experiment go down the drain when an Agile team expects “casualties” in the form of forthcoming layoffs.

Flying at the Teeth of Layoffs

The design for the 2005 roll-out of Agile at BMC Software did not put in place any planning in advance on how to deal with the impact of possible layoffs on Agile assimilation. Everyone knew, of course, that layoffs might and do happen in the software industry. However, Agile was kept in a different mental “drawer” from the one in which possible layoffs were kept. Planning-wise the two were not really connected.

When we had to carry out layoffs in 2005, we encountered severe cognitive dissonance:

  • On the one hand, the excitement in the business unit about Agile was tremendous. We were witnessing the psychological aspects of Deming‘s System of Profound Knowledge in an unprecedented manner. Skill, pride, confidence and collaboration were building up faster than you could say “Agile”.
  • On the other hand, the layoffs put a damper on all four elements – skills, pride, confidence and collaboration. Folks who worried whether they might be next in line to be laid off were not able to place the Scrum team’s accomplishments ahead of the credit they sought for themselves. The determination to learn more and deeper about Scrum slackened as employees bided their time in anticipation of the next round of layoffs. Obviously, pride and confidence went down the drain.

Reciprocity

Preserving the Agile momentum in the face of layoffs required striking a new balance between what employees were getting out of Agile versus what the company was expecting to accomplish through Agile. I actually viewed it as a kind of balance of payments problem. It was quite clear what the company was already getting out of Agile, and even clearer that the long-term payoffs from successful implementation of Agile could be very significant indeed. We did not, however, have a good answer then for worried employees who asked: “What is in it for me?” A record breaking Scrum implementation 12 months down the road is not too meaningful for an employee who suspects he might not be with the company in 6 months.

It so happened that in 2005 we started seeing job specifications that either asked for or mandated Agile skills. This gave us the clue to a meaningful reciprocity in the face of potential layoffs. By investing aggressively in Agile training we would not “only” improve productivity, we would also enhance marketability of our employees. We would be providing a better safety net for them.

A Social Contract for Agile

My sense in 2005 was that the social contract between employers and employees in the software industry was broken. Without a working social contract, the friction and antagonism can bring a system down. For example, in 1942 – the turning-point year of WWII – 833,000 days of coal mining were lost due to strikes in the British coal industry.

The preliminary thoughts I had on the subject in 2005 turned into a mini social contract. The mini social contract is an agreement between an executive and his employees on the rules of the game that are mutually satisfactory. The mini social contract I used evolved over the years. Here it is in its latest form:

Team, my overarching organizational objective is to preserve our team and its institutional knowledge for our corporation and its customers for years to come. We will achieve this goal by enhancing our software engineering prowess to the level that the resultant benefits will outweigh the repercussions of the current financial crisis. The state of the Agile art should enable us to attain hyper-productivity which will serve as the best antidote to layoffs. In the event that we fail to accomplish hyper-productivity and our assignments fade away, you will find the Agile skills you developed much in demand in the market. Whether you will or will not be with the company in the future, I acknowledge your need to develop professionally as Agile practitioners and commit to invest in your education/training.

Impact of the Social Contract

Applying the social contract produced four effects:

  1. It legitimized discussions on a taboo topic.
  2. It reduced fear while increasing hope.
  3. It was a hard proof point to the folks in the trenches that I as an executive was one of them. This is a most critical aspect in the executive-employee relationship in software companies.
  4. It led to fruitful exchanges with Agile practitioners in other companies who were wrestling with the very same issue. These exchanges helped us improve the social contract.

Criticism of the Social Contract

I got some flak from colleagues on the commitment to invest in Agile training. The concern was that such a commitment, even if it is given as a gentleman’s word, is too open-ended. Proficiency in Agile, it was argued, is quite relative. Hence, when could one state that the contract was “fulfilled” with respect to commitment to invest in Agile training and coaching?

The Fine Line Between Management and Leadership

The criticism of the social contract cited above should not be rejected out of hand. Obviously, one does not want to create expectations that might not be fulfilled.

Quite simply, committing to Agile training and coaching actually illustrates the fine line between management and leadership. As the quip goes – “Leaders do the right things; managers do things right”.  Committing as an executive to Agile training and coaching across the board might appear to be not doing things “right”.  Making this kind of commitment, however, is in the very nature of leadership. And, frankly, it is also doing things “right” for executives who have the best interest of the company at heart.

Where do You Lead From?

We were taught to lead from the front in the paratroop corp. Over the years, I have learned one other important aspect of leadership: leading from within. To me, the social contract is leading from within.

Written by israelgat

February 3, 2009 at 5:32 pm

Agile Considerations for CXOs

with one comment

“I don’t care about Agile; I care about money!” These words, said to me not too long ago by an executive with whom I was discussing the roll-out of Agile in his division, are the impetus for this post. Whether you are or are not in R&D, Agile can have a significant impact on you and on your company, including the bottom line.

To keep things simple, listed below are a few “front lobe” considerations for CXOs – CEOs, CFOs, CIOs, CMOs, COOs and CTOs. The listed considerations are neither “good” nor “bad” – they are what they are. They are rendered here for the thinking when an Agile topic comes up in the domain(s) you are responsible for.

Some of the considerations for CXO’s are linked to posts, articles or books that already address the subject to some degree.  As additional related posts will get rolled out on this blog, they will be linked to the bullets below. In other words, the Agile Considerations for CXOs post will evolve, serving as a quick index for an eclectic list of Agile CXO considerations.

CEO

CFO

CIO

CMO

COO

CTO

Written by israelgat

January 23, 2009 at 4:28 pm

Posted in The Agile Leader

Tagged with , , , , , ,

Customer Intimacy

with 4 comments

In the Myth of Excellence, authors Crawford and Mathews examine customer-vendor interactions and relations. Interactions are evaluated by the following attributes:

  • Access/Ease
  • Experience
  • Price
  • Product
  • Service

The customer-vendor relation is assessed on the following four level scale:

  • Consumer Underworld
  • I: Consumer accepts the company (Operate at Par)
  • II: Consumer accepts the company (Differentiate)
  • III: Consumer seeks the company (Dominate)

Combining these two “dimensions”, Crawford and Mathews present a 4X5 table, as follows:

Myth of Excellence

As can be seen in the table, the customer Experience at the Consumer Underworld level is dehumanize me, disrespect me, ignore my needs. In contrast, the Experience at Level III is establish intimacy with me by doing something no one else can.

Between the Customer and the R&D Lab

Quality of software and responsiveness  by customer support are often a matter of furious exchanges between the customer and the software vendor. Escalations to the executive level in order to get better response on various software defects and deficits are quite common. On many occasions, an escalation becomes the battle of the spreadsheets. The customer steps into a meeting armed with a long spreadsheet of defects that have not been fixed in a timely manner.  Typically, the customer also presents a long spreadsheet of unfulfilled requests for enhancements (RFE’s) that were promised, implied or expected. The vendor typically comes to such a meeting with as long spreadsheets demonstrating how responsive and diligent the service to the customer has been. Even with good intentions on both sides, such meetings are often loaded with defensive routines. Frequently they become adversarial. Some even conclude with a forceful customer statement such as “I want my money back”.

The mirror image of such customer escalations is the chronic complaint in the R&D lab about lack of good requirements. By the time the needs of multitudes of customers have been translated and aggregated to produce a market requirements document, a lot has been filtered and some has been distorted. Furthermore, as product managers are often stretched very thin, developers and testers interpret requirements only as best as they can. The loss of direct touch between customer and vendor can lead to results such as those reported by the Standish group in their 2002 “Chaos” study:

Standish Group

A Model for Including the Customer in the Agile Process

The state of affairs described above has multiple causes which will be explored in depth in forthcoming posts. Whatever the causes might be, direct connection between the customer and the developer/tester can help reduce mutual pains. The method for so doing is straightforward:

  • Customer participates in Release Planning
  • Customer participates in the bi-weekly demo.
  • Customer participates in Release Retrospective

Regular participation in these three activities amounts to 100-150 hours per year. The advantages to the customer of making this time commitment are significant:

  • Influence product direction
  • Gain deeper understanding of the product
  • Develop relations with members of the vendor’s project team
  • Gain experience in Agile methods

For the software vendor, customer participation along the lines recommended above is as beneficial, enabling the vendor to:

  • Get over the us versus them mindset
  • Raise the probability of doing the right product and doing the product right
  • Gain precious insights how the product will be used
  • Win over an evangelist: a customer employee working in such a manner with a software vendor’s Agile team tends to be proud of the product and his contributions to it

Back to The Myth of Excellence

Examine the Customer-Vendor Interaction and Relations table pasted above. The inclusion of the customer in the Agile process directly addresses the Experience and Service attributes for Level III:

  • Experience: Establish Intimacy
  • Service: Customize the product or service to fit my needs

An indirect benefit that is likely to materialize is with respect to the Product attribute. An agile team that experiments on an on-going basis, using the bi-weekly demos as the “firewall” for containing unsuccessful experimentation, is likely to be quite innovative without accruing higher risk than acceptable. Hence, inspire me with an assortment of great products is an outcome that could be expected in the longer term.

Market-of-One

As pointed out in the recent Cutter Consortium essay,  experienced Agile teams can cater to the needs of their top customers by providing  Market-of-One. The very many advantages of so doing will be discussed in forthcoming posts.

Written by israelgat

January 20, 2009 at 9:36 am

Posted in The Agile Leader

The First Decision to Make

leave a comment »

The Choosing Between Two Disruptions post highlighted the fundamental predicament one faces with respect to large scale Agile deployment – Is an in-house Agile disruption initiated by you preferable to a market disruption through Agile which you will need to react to? I trust you will decide to give Agile a try even if you are concerned about a possible in-house disruption. This being the case, you will need to make numerous decisions about the way you will roll Agile. This posts deals with the very first decision to make with respect to so doing: Choosing the Agile learning paradigm which will be most effective in your company.

Learning and Thinking

Years ago, when I was a student at the Israel Institute of Technology (Technion), we had a quip about the learning paradigm: “In the second year you understand what you were taught in the first year; in the third year you get what you learned in the second year”. The quip captured the essence of the de facto learning paradigm that largely prevailed at the Technion back then. The Technion probably aspired for a very different learning paradigm, but circumstances in Israel during these years dictated a different pattern. As many of us were called to reserve army service for 30-60-90 days a year, we did not usually have enough time on our hands to think deeply about what we were studying. We absorbed a lot of information quickly in a somewhat mechanical way. Only over an extended period of time were we able to generate sufficient cycles to think deeply about what we were taught. This later thinking eventually led to understanding. We assimilated the curriculum with an average one year lag.

How will your Company Learn?

Business realities these days might force you to introduce Agile in a “Technion style” manner – you introduce Agile as a recipe. You do your best, of course, to explain the deeper thinking behind Agile, but you focus on the “How?” You bet the Agile roll-out on getting results through applying Agile practices. Once you have a couple of Agile success stories under your belt, people will naturally get curious about the underlying principles. They will rediscover them, assimilate them and propagate them.

The other way to go is to start with the deeper truths – software engineering laws, anomalies and trends that over the years led to the rise of Agile. You start with the “Why?”, bootstrapping your way towards the “How?”

The Reengineering Alternative

William E. Schneider’s book The Reengineering Alternative is a must read prior to making the decision how your company will learn Agile.

Schneider characterizes four core organizational cultures and provides the tools to self-determine your corporate culture and to assess the strengths and weaknesses that go with it. Each of the four core cultures – Control, Collaboration, Competence, Cultivation – has its own characteristic response to change. Choosing the learning paradigm best suited to your company is largely a matter of cultural fit.

For example, according to Schneider, the Control culture mandates change. Hence the “Technion style” approach discussed above could be quite appropriate if your company is of the Control ilk.

Time for Thinking

Reducing the pressure on a software team to the point at which thinking can be done in parallel with coding and testing is of immense value. Higher levels of quality and innovation are visible pretty quickly. Longer term, code adaptability and the ability to evolve the code pay off big dividends. These benefits are particularly important for teams who incorporate bleeding edge technologies in their product. You must have the time to think about such technologies and how to utilize them.

The pain of having an Agile project team gated on the availability of some feature from a Waterfall team can be significant. Painful though it may be, such a situation could actually be seen as a blessing in disguise. The team members have time to think. And, they have the time to refactor their code.

The Agile Leader

In addition to helping you make your first decision with respect to the Agile roll-out, Schneider’s book will give you a precious clue as to your role as an Agile leader:

A leader’s effectiveness can be measured by the degree the leader’s approach is integrated with the organization’s core culture.

A fascinating aspect of this sound advice is the culture within a culture situation. As Agile tends to create its own culture, the Agile leader often needs to align the Agile culture with a broader corporate culture. To succeed, the Agile leader needs to create such an alignment while protecting the Agile culture. Various means for so doing are described in the presentation Leading from Within.

Written by israelgat

January 19, 2009 at 4:14 pm

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

Leading from Within – Tonight in Austin

with 2 comments

Update: see presentation above, or download directly.

Tonight I’ll be giving a presentation at the Austin IEEE meeting entitled “Leading from Within.” It examines the “secret sauce” for enterprise level Agile deployment with special emphasis on the virtues of the Agile leader.

You can see full details, including a map to the location on the Austin IEEE site.

Written by israelgat

January 13, 2009 at 4:50 pm

Posted in The Agile Leader

Tagged with