Real Agility Program – Leadership Transformation Team

One of the main components of our Real Agility Program for enterprise Agile transformations is the Leadership Development track.  This track is a series of monthly leadership meetings with one of our consultants to help them establish their Leadership Transformation Team.  This team is based in part on the concept of a guiding coalition from John Kotter’s work (see “Leading Change“), and in part on Edgar Schein’s work on corporate culture (see “The Corporate Culture Survival Guide“) as well as our own specific experience on successful Agile transformations in organizations.

The very first thing, of course, is to establish who should be on the Leadership Transformation Team.  There are six major categories from which the team must find representatives:

  1. The Executive Sponsor, for example the CIO
  2. Business Management, for example an SVP of Sales or Product Development
  3. Process Management, for example the head of the PMO or Compliance
  4. Technology Management, for example VP of Technology or Development
  5. Human Resources, for example a Director of Staff Development and Training
  6. and Apprentice Agile Coaches / Agile Champions

In total, the number of people on this team should be no more than 12, but smaller is better.

Once established, this Leadership Transformation Team must execute on three core responsibilities in perpetuity:

  1. Urgency and Vision: constant, strong, repetitive, prominent communication of the reasons for change and a high level view of how those changes will happen.
  2. Lead by Example: use of an Agile approach to run the Leadership Transformation Team’s work – we recommend OpenAgile for the process, but Kanban may also be used.
  3. Empower Staff: focus on removing obstacles by making structural changes in the organization, helping staff master standard Agile processes and tools, and eventually, creating innovative Agile approaches customized for the organization.

This leadership support is a critical success factor for an Agile Transformation.  One of the first steps in our program for this team is to help with the creation of the team’s plan for the transformation.  This plan can be derived from an number of sources including assessment work, but includes a number of standard items that must eventually be addressed for a successful transformation.  At a high level, these include:

  • Hiring, performance evaluation and compensation
  • Reporting relationships
  • What to do with project managers, business analysts, testers and certain middle managers
  • Key metrics and processes for measuring progress
  • Technology and physical environment
  • Vendor relationships and contracts
  • Compliance, regulation and documentation

Many of these items are multi-year change efforts that need to be closely guided and encouraged by the Leadership Transformation Team.

One final point about the Leadership Transformation Team needs to be made: the work they do must not be delegated to subordinates.  If something is part of their three core responsibilities, it must be handled directly by the members of this team.  Therefore, the team members need to allocate a significant percentage of their time to the effort.  Usually 20% is sufficient to get started.  The proportion may wax and wane slightly over time, but if it gets too low, the Leadership Transformation Team will lose touch with the transformation and the risk of it going bad increases substantially.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Pragmatism, Fundamentalism and Transformation – the Three Modes of Scrum

Most organizations don’t get the potential benefits of Scrum.  In fact, I would guess that out of all the people who have come through my Certified ScrumMaster or Certified Scrum Product Owner classes, fewer than 5% have gone back to their organizations and seen the 4 to 10 times growth in productivity that Scrum can enable.

Why?

Pragmatism – Arrogance and Defeatism

Pragmatism as applied to Scrum is the approach of taking only the “good things that are possible for us” from Scrum and using those in a team or an organization.  This might mean doing the Daily Scrum meeting, but giving up on many of the obstacles raised there because they are too hard to overcome.  Another common example of this is creating a team of technical people who contribute time to the Scrum Team and possibly to other priorities instead of the idea of creating truly cross-functional teams with all members fully committed to the Scrum Team.

This pragmatism often results in some benefits: better communication among team members, shorter feedback loops with users and customers with the team, or a stronger focus on business value for the scope being worked on by the team.  It might amount, in practical terms, to a 15-25% productivity improvement.

But, really, it sucks, and it’s not Scrum.

For teams and organizations that are new to it (three years or less), this is like an individual going to a dojo to learn Karate and, after the first session, telling the Sensei, “hey, this was really interesting but I can’t stretch that way so I’m going to do the kick differently – don’t worry, it’s better than what I did before – let’s move on to other things that I can do!”.  In other words, it’s arrogant and defeatist.  Regrettably, a lot of arrogance and defeatism goes by the much more palatable label of pragmatism.

You can’t make up what you want to do and call it “Scrum”.  Scrum has a definition (which has changed somewhat over time) and if you do something different from the definition, please call it something different.

But please, don’t mistake my comments for a call to…

Fundamentalism - Inoculation Against Scrum

It’s less common, but some people go here.  They learn Scrum the one true way and decide that come hell or high water, they will make their team do it that way!  Scrum this way is rigid and cultish.  Nevertheless, done this way, Scrum can still have some (temporary) benefits, similar to the pragmatic approach.  The challenge here is that it’s not usually sustainable and the people who participate in this type of Scrum are often “immunized” against it.  They’ve had a bad emotional experience with Scrum due to the inflexible, intolerant approach to implementing it.  Justifiably, those people don’t want to repeat the negative experience and so they actively avoid Scrum or even bash Scrum publicly.

It really is a process very much like how our antibodies work in human health: we are exposed to a microbial disease which itself may temporarily succeed in propagating in our body, even long enough to get us to infect someone else.  But after our immune system fights it off, we are ready for the next attack, will recognize it and repulse it far more quickly so that it can’t spread.  Trying to spread Scrum by doing it as an invasive take-over of an organization is very likely to cause the same sort of reaction among the people in the organization.  And anyone who comes along a little while later, even with a much more appropriate way of doing Scrum will likely be quickly rejected by the long cultural memory of the Scrum antibodies!

So where does that leave us?  There really is only one option for doing Scrum, allowing it to flourish, and getting amazing long-term results:

Transformation – The True Potential of Scrum

Remember that Scrum is based on the values and principles of the Agile Manifesto, and that Scrum itself has five values:

  1. Commitment
  2. Courage
  3. Focus
  4. Openness
  5. Respect

Taken all together, these values and principles constitute the spirit of Scrum.  They are the belief system.  They are the energy behind the framework.  This means that as a team uses Scrum, it must recall these values and principles and try to put them into practice through Scrum.  Not just the team, but the team’s stakeholders also need to be aware of these values and principles and also try to put them into practice.

For example, if you are a functional manager for someone who is on a Scrum Team, it is tempting to ask that person to do work that is not actually part of the Scrum Team’s plan. This is a distraction and causes both the individual person and the other Team members to lose focus.  Losing focus delays or prevents the creation of a high-performance team.  Therefore, as a functional manager, it is much better for you to “cover” for your subordinate, not distract them, and in every way allow that person to focus on their work for the Scrum Team.

Transformation doesn’t come just from adopting a set of values and principles, nor does it come from using a framework of processes and artifacts.  Transformation requires love and passion.  Transformation occurs when all the members of the Scrum Team, and their stakeholders start to develop intense personal bonds and become passionate about the potential of using the Scrum tool.

I really like the “hammer analogy“.  When you first use a hammer, you will likely find it annoying and painful to use.  You hit your thumb, your muscles get tired, etc.  But after getting better at using it, you start to see its potential: the hammer is an elegant, effective tool.  In a small way, you love the hammer, in part because of the results you can get with it.  Perhaps you have experienced this if you have ever tried to finish an unfinished basement: after you successfully put up your first stud wall, you think, “wow, I love doing this.”  That sense of accomplishment gives you the passion to continue to use the hammer.  So it is when using Scrum…

you allow Scrum to transform you and your organization not the other way around.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Advice Book

Hi Everyone!  I’m writing a compilation book of the best articles of Agile Advice (as well as some that may not have been so popular, but which I think are important).  I was wondering what you all think are the best articles from our archives so that I can be sure to include them!  The best way to vote, since there are soooo many articles about Agile, Scrum, OpenAgile, Management, Org Change etc. etc. is to simply write a comment on the articles you think are the best and worth including in a book!  You can comment on any of the articles: feel free to brows through the archives, go by subject, do searches, etc.  As well, if you have any suggestions for specific blog posts that you always wish I had written, please comment in the section below.  I will be including three brand new articles in the book that won’t be published here as stand-alone articles.  If there are enough interesting suggestions for articles in the comments here, I will also choose up to three ideas to write about for special inclusion in the book and if you made the suggestion, I will including a credit to you for the question (if you want me to, otherwise you are free to remain anonymous).  I’m hoping to get the first draft of the book out by the end of January since I’ve already put a lot of work into it, and that draft will be available for free here online for a limited time.  The final draft will be self-published and I will provide links here to those who want to purchase it.

Thanks for your loyal readership and thanks in advance for your votes and suggestions!

- Mishkin.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

What’s in your Agile Transformation Backlog?

Michael Badali, a good friend of mine, has asked a great question on LinkedIn: What is your Backlog for Agile Transformation?.  From his question:

While I think that Band-Aid off quick is more likely to be successful than Band-Aid off slow, often Agile Coaches & Leaders are put in the position of Kaizen instead of Kaikaku. When asked for a detailed waterfall plan and schedule on how to become Agile… I generally refuse and create an Agile Transformation Backlog – a prioritized list of things that need to be done to become Agile. Please share your prioritized list of things that need to be done to be Agile.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Transformation and the Chasm

In his book “Crossing the Chasm“, Geoffrey Moore describes the difficulty of creating a popular new product due to a conceptual “chasm” between the first people who adopt a new product and those who come later.  He describes five types of people in relation to how they adopt new products:

  • Innovators – always actively seeking out and trying cutting edge new products.
  • Early Adopters – excited to try new things, but after the worst “bugs” have been removed.
  • Then there is the Chasm – many products fail here.
  • Early Majority – willing to try new things but need strong testimonials or real-world proof.
  • Late Majority – require time-tested proof before they will adopt a product.
  • Laggards – resistant to change and hesitant to adopt anything without strong personal incentives.

This product adoption behavior also applies to new ideas in general, and of course, to Agile Transformation [Agile Transformation vs. Agile Adoption] in particular.

Implications of the “Chasm” Model

An organization attempting to do an Agile Transformation [Kotter's 8-Step Change Model] should understand how to use this model to ensure long-term success.  This diagram illustrates the concepts (click on it to see it full size):

First, the organization should start the transformation by finding the innovators and early adopters.  These people can then be recruited to run the initial pilot projects.  They will be enthusiastic and will typically adapt themselves to the new behaviors and thinking patterns required by Agility.  If they are properly supported by managers, they will also be successful – at least within the bounds of a limited pilot environment.  Success here will mean that the pilot projects deliver value, use feedback effectively, and the participants (team members and stakeholders) will be happy with the results.

In this stage, it is best to avoid putting people on the teams who are from the early majority, late majority or laggards groups.  These people will tend to drag on the results of the pilot projects.  This is a common mistake in running a pilot program and leads to discouraging results.  One way to help filter between these two groups is simply to ask for volunteers for the pilot projects.  Innovators and early adopters will be much more likely to volunteer for a new initiative.

After the pilot projects have shown some good results, the next step is to go the general roll-out.  In this step, you are now working with the early and late majority.  These people need much more substantial support for a change of this nature.  They will require intensive training, and hand-holding in the form of coaching and mentoring.  This hand-holding can come partially from your innovators and early adopters.  Some of the participants in the pilot projects will have the desire to share their success.  From these, you need to carefully select and prepare a few who will act as internal coaches.  If you are a small organization or if you wish to do your transformation quickly, you will likely need to hire coaches from outside your organization as well.

The early and late majority require evidence of benefits and reassurance that risks are minimal or can be mitigated.  This evidence partially comes from your pilot projects.  However, this may not be sufficient.  There are two other important sources of evidence for this group: the leadership team and external experts.

The leadership team must be committed to the change to agility and can demonstrate this commitment by doing their own management work as an agile team.  The exact details of the agile process do not need to be identical to that of the staff teams, but it should be recognizably similar.  As well, this “Agile Transformation Team” must make itself very visible during the general roll-out.  This can be done with communication and by taking up visible residence in a central conference room or bullpen.  As well, this Agile Transformation Team must work diligently to remove obstacles that are raised by staff teams during the general roll-out.

The second source of evidence comes from external sources.  Published case studies are one valuable source.  However, there is a huge value in a visible management investment in external support from recognized experts.  This can be in the form of training, coaching, consulting as well as informal “lunch-and-learn” meetings, town hall meetings and the like.  When engaging experts, it is imperative that the Agile Transformation Team act on their advice otherwise the early and late majority will take that as a sign of hypocrisy.

The final stage of a roll-out is to deal with the laggards.  For the most part this is a do-or-die proposition for these people.  Either get with the program and engage like a committed employee or leave the organization.  If your organization is large enough, you will likely have observed some of these people leaving the organization in the general roll-out.

For some organizations, this transformation process can take many years.  An organization with thousands of people should expect to be working on the pilot projects for at least a year, the general roll-out for at least three years.  Often it will be longer.  Good luck on your agile transformation effort!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Outside of Software

The manifesto for agile software development (http://agilemanifesto.org) consists of 4 basic values:

1. Individuals and interactions over processes and tools?
2. Working software over comprehensive documentation?
3. Customer collaboration over contract negotiation?
4. Responding to change over following a plan

I’ve been thinking about how this manifesto applies outside of the world of software, for which it was originally created. These concepts are so engrained into various agile methodologies, which these days don’t explicitly refer to software any longer, that it begs the question: how does a team apply these four values to their work outside of software development; specifically, what would replace delivering ‘working software’? The other three values translate more fluidly to differing spheres of work. For example, whether in the field of business, sales, medicine, etc. placing greater value on all the items on the left over those on the right will produce a transformed culture and working environment. But what does ‘working software’ translate into in these various realms? Particularly relevant for non-profit organizations, the next possible question would be: what if we are not creating a ‘product’ or something that is ‘shippable’? What I’ve found to be the methodology which most aptly addresses this question is OpenAgile.

On its website: www.openagile.com it is noted that: OpenAgile is a learning system designed to help individuals, teams, and organizations build capacity for rapidly delivering value to their stakeholders. Rather than the focus being on a product, the aim shifts to learning and value. Yes, the ‘product’, if there is one (software or other), is important, but now there are even greater possibilities for the use of agile outside of software.

Though almost deceivingly simple, the principles animating OpenAgile are extremely profound. Through practicing the core foundational principles of truthfulness, consultative decision making, and systematic learning (through reflection, learning, planning, and action – all in light of guidance) the potential ability to ‘deliver’ something valuable is extraordinarily enhanced. Indeed, the greatest value could even be the learning that has taken place from the team or individuals themselves, the changed culture now animated by consultation engendering collaboration rather than competition, the regular and ongoing practice of truthfulness in a team resulting in accelerated transformation (potentially also allowing for that team to be more committed and driven to delivering a ‘product’) and the creation of a space where continual learning is the hallmark.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Planning Onion is Wrong

The concept is simple: there are six levels of planning in an organization, often represented as layers of a metaphorical onion. In the agile planning onion, strategy is the outermost layer. This is meant to indicate that it is the driver of all the planning in the inner layers, which have shorter time horizons, down to the daily planning that occurs in the Daily Scrum or the Daily Standup of the agile teams.

Culture is Missing

The agile planning onion is a reasonable metaphor, but it has a serious limit: culture is missing. Many of you will have heard the quote “Culture eats strategy for lunch [or breakfast]” (attributed to quite a number of different people – I’m not going to sort out who was the original). How do we represent culture on the onion? Is it a seventh layer on the outside? Maybe, but for most organizations, culture is not planned.

Single Loop Learning

The main problem with the planning onion is that it gives no indication that the planning cycles deal with anything but the product / business side of the work. This implication of single-minded focus gives us permission to limit ourselves to improving our products. This is learning, but it is limited. It is sometimes referred to as “single loop learning”. We make improvements, but never question our underlying beliefs, habits or goals. All improvement (and planning) is within the narrow guard rails of a product mentality.

Double Loop Learning

Culture both surrounds the planning onion, and cuts right through it (nice way to extend the metaphor!) The problem with a visual metaphor that does not include culture is it means that culture remains unconscious. As individuals we might, from time-to-time, find that the organization’s culture clashes with our own expectations, habits or beliefs. But other than this occasional dissonance, we are like onions in dirt – completely unaware of the dirt, yet completely utterly dependent upon it for growth (couldn’t use “fish in water” because that would have introduced a different metaphor – I’m trying for consistency).

In the best agile transformations, individuals, teams and organizations become aware of their culture and consciously work to change it. This is usually due to a strong clash between their current culture, and the behaviors, norms and attitudes of a embryonic agile culture. In Scrum, we find impediments and remove them. In OpenAgile we look for learning about product, process and people. This is, again, roughly speaking, double loop learning… it is learning about learning and applying this to our belief systems, our habits and our attitudes.

Transformation vs. Adoption

Those who share the agile planning onion model, probably don’t realize its limits. I would like to strongly encourage those who use this model to consider re-framing it in terms of culture and organizational learning, rather than planning. I’m terrible at diagrams – I hope someone out there will consider creating a new compelling Agile Learning Onion diagram to show that agile is about Transformation, not merely adoption of planning practices.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Assessing an Organization for an Agile Transformation Plan

Myself, Paul Heidema and a few other people we work with have now participated in several assessments of organizations who are either looking at adopting agile methods or improving existing use of agile methods. We have developed several tools for running these assessments. The following things are critical to the assessment process and the results we get:

Culture

The success of an agile transformation is primarily driven by connection that transformation makes with the existing culture of the organization. We know that doing an agile transformation includes cultural changes. The critical piece is understanding the culture so that you can determine what in the culture supports agility and what in the culture is going to hinder agility. A culture that focuses on individual accomplishment and freedom will not support agility well, while a culture that supports doing the best possible thing for customers will support agility. Of course, any given organization will have a mix of cultural aspects that both support and hinder agility. There are a number of methods for examining culture including an excellent corporate culture workshop described in the book “The Corporate Culture Survival Guide” by Edgar Schein.

Value Stream Mapping

A high level value stream map is an excellent tool for identifying both an overall need for improvement by making the current state of affairs visible, as well as pinpointing where big improvements can be made quickly. More often than not, when we do an assessment for an organization, we are finding that the efficiency of their process is at about 20-30%… in other words, 70-80% of all effort is expended on wasteful activities. This level of waste is often surprising for stakeholders. And of course, making that level of waste visible is a large motivator for the kind of continuous improvement that agile methods such as OpenAgile and Scrum make possible.

Agile Practices

Of course, even if an organization is not doing agile officially, there are often existing practices that can be considered part of the overall umbrella of agile. A comprehensive assessment that rates a team’s or an organization’s level of use of agile practices gives a good picture at a very practical level of what things you can build upon. For change to be successful, a significant factor is to tie new practices to existing practices. This is a great way to do this. There are lots of lists available of agile practices. We publish one fairly comprehensive list of agile practices on the Berteig Consulting site (it’s near the bottom of the linked page).

There are of course many other things that are done during an assessment, but these three form an effective foundation for any agile transformation plan.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail