The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization

When I am speaking with executives, ScrumMasters and other leaders of change in organizations, I often present a simple 3-layer model to understand the relationship between the various moving parts in the Agile Framework:

  1. The Agile Values and Principles – These describe the culture and, in the Agile Manifesto, are the definition of the word “Agile” as applied to software development. I didn’t write the Agile Manifesto so I don’t get to re-define the word Agile.  To give an example: in the manifesto it says “The best architectures, requirements and designs emerge out of self-organizing teams.”  As a former enterprise architect at Charles Schwab, I struggled with what I saw as incredibly wasteful up-front architectural activities when I knew that developers would (sometimes) ignore my glorious ivory-tower plans!  Therefore, if you are still doing up-front architecture and forcing your teams to comply to that architecture, you aren’t Agile.  Therefore, as an individual, a team or an organization, you need to make a conscious decision to “BE” Agile or not… and if you decide not, then please don’t call yourselves Agile.
  2. The Agile Toolkit – There are many hundreds of distinct tools in the Agile toolkit including Scrum, OpenAgile and other “large” Agile methods, as well as the Planning Game, Product Box, Test-Driven Development and other “small” Agile techniques.  Any group of people trying to BE Agile, will need to use dozens or even hundreds of different Agile tools.  I call them tools because the analogy with construction tools is a very good one.  Scrum is like a hammer.  But you can’t do much with just a hammer.  Scrum is a great, simple tool.  But you always need other tools as well to actually get stuff done.  All the tools in the Agile Toolkit are compatible with the Agile Values and Principles.  Even so, it is possible to use the Agile Tools without being Agile.  A Scrum team that never gets together face-to-face is not an Agile team: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  (Video conferencing doesn’t count.)
  3. The Agile Organization – When you start using a tool, there is a learning period.  We start by being conscious of our incompetence and as we persist, we become competent… but it isn’t natural or habitual yet.  Eventually, with continued use, we become unconscious of the tool.  IDE’s and version control are like this in most organizations: we don’t even think about them!  But getting through that initial stage requires us to change; to develop new skills.  This process usually requires discomfort or pain (including psychological pain).  An organization attempting to BE Agile and to use many of the tools in the Agile Toolkit will need to make many changes and often these will be difficult.  For example, incorporating the Product Owner role from Scrum into your organization requires new role definitions, new performance evaluation practices and criteria, new compensation systems, new communication and reporting mechanisms, new authority and accountability processes, etc. etc.  All of the changes required are about creating Enterprise Agility throughout the whole organization, beyond just software or IT.  These extensive changes are often started in a very ad hoc manner, but at some point they need to become systematic.  This is an important decision point for executive management: are we going to be Pragmatic about our Enterprise Agile adoption, or are we going to be Transformative about our Enterprise Agile adoption.

All of this is summarized in this graphic:

The Agile Framework [PDF]

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 Three Fundamental Principles of Agile Estimation – The Third One Will Surprise You!

You probably already use an Agile Estimation technique such as the Planning Game or the Bucket System, but surprisingly few people understand the underlying principles of Agile Estimation.  This lack of understanding often causes confusion or stress for the people who try to use Agile Estimation techniques.  The discrepancy between traditional estimation techniques and Agile techniques is large and it is hard to bridge that mental gap without understanding the principles involved.  There are three fundamental principles of Agile estimation:

Principle One: Collaborative

Agile estimation methods are collaborative.  This means that multiple people work together to arrive at estimates for work in an Agile project or product development effort.  Traditional estimation techniques (such as those related to bottom-up or top-down) tend to focus on individuals estimating the work that they are responsible for doing and “trusting” those individual estimates.  Collaborative estimation means that most estimation is done by people in formally facilitated meetings where people are present in-person.

Collaborative techniques are generally used where there is some expectation that multiple minds are better than a single mind in discovering some new knowledge or solving a problem.  Teamwork and groupwork are based on this concept.  This idea of collaboration for problem solving is also applied to Agile Estimation and it has some interesting ramifications.

The most radical consequence of collaborative estimation methods is that there is no possibility to trace a particular estimate for a particular item to a particular individual person.  This lack of traceability is important to create a sense of safety on the part of participants in the estimation effort.  This safety is necessary to allow participants to be fully honest about estimates even if those estimates conflict with expectations of powerful stakeholders.  Another way of stating this principle is that no individual can be punished for a bad estimate.

Many Agile estimation techniques take this principle beyond just mere collaboration to the level of consensus-building techniques where everyone in a group doing estimation work must agree on the final estimate for each and every item being estimated.  This strengthens the idea of safety to the point where no participant in an estimation effort can ever say “I didn’t agree with that” and thereby leave other participants “on the hook” for a bad estimate.

Principle Two: Relative Estimation

Imagine you are shown a glass bottle with some water in it.  You can see the water sloshing around.  Someone asks you, “how much water is in the bottle?”  You might, at first, think about the overall size of the bottle and respond by saying “it’s 1/3 full.”  Or, if asked to provide a measure in units like millilitres or fluid ounces, you might mentally compare what you see in front of you to some container (e.g. a measuring cup) where you know the quantity.  In both cases, you are doing a relative estimate of the amount of water in the bottle.  You are comparing the amount of water to a known quantity.

Imagine a counter-example: someone walks up to you with a red pen ask asks you “what is the wavelength of the light being reflected from this red ink?”  If you are like most people, you have probably forgotten (if you ever knew) the wavelengths of light in the visible spectrum.  You have no basis for comparison.  You might take a wild guess, but it is just that.  Going back to our relative measure, you might be able to easily say if it is darker or lighter than another red colour, or you might even be able to tell what hue of red it is.  But those cases are, again, relying on our inherent ability to see relative differences.

So instead of ignoring this capacity, in Agile estimation techniques, we leverage it.  When estimating effort, we start by setting a clear baseline for what we are comparing: another piece of work.  The baseline piece of work is often given an “estimate” that is arbitrary and in some non-standard units.  For example, it is common to use “points” when estimating the effort for Product Backlog Items.

When doing relative estimates it is very important to ensure we are comparing “apples to apples”.  Both the piece of work to be estimated and the comparison piece should both be work items that are not yet done!  If you have already completed one of the pieces of work, you have prior knowledge that you don’t have for the work to be estimated.

This last point is subtle, but important.  If you have already done something, you know much more about it.  If you try to compare to something you haven’t yet done, you will be tempted to assume that the two things will be more similar than they may be when you actually get to work on it.  By comparing two pieces of work that you have not yet done, you become much more conscious of the risks of comparing, and that consciousness will help you make better relative estimates.

It is important to note that one side advantage of using relative units for estimation is that it makes it much more difficult to use estimates as a baseline for either measuring performance or for tracking schedule variance, both of which are essentially meaningless in a good Agile environment (which should be almost entirely results-oriented).

Principle Three: Fast

In Agile estimation we don’t care (!!!) about accuracy nor about precision of estimates.  Whoa!  Why is that?  Because estimation is waste.  You can’t sell estimates, and estimates don’t affect the “form, fit or function” of the thing you’re building.  Therefore, both Agile and Lean concur: do your utmost to eliminate that waste.  There are actually lots of Agile practitioners who think estimates are evil (and they have some good arguments!)

In order to do Agile estimation in a maximally non-evil way, we need to make estimation fast!  Really fast!!!  Many of the Agile estimation techniques allow you to estimate a product release schedule lasting as much as a year in just a few hours given a reasonably well-crafted Product Backlog.

There are really only two modestly good reasons for doing estimation in an Agile project or product:

  1. Estimates provide simplified information to the Product Owner to allow him/her to make sure the Product Backlog is ready for the next Sprint (ordered, refined).
  2. Estimates allow stakeholders, including the team doing the work, to generate high-level common understanding and expectations without dwelling on details.

As a business stakeholder, one can do a simple mental exercise.  Ask yourself, “how much money would I be willing to spend to accomplish those two objectives?”  Whatever your answer, I hope that it is a very small amount compared to what you are willing to spend on getting results.  If not, perhaps you haven’t really embraced the Agile mindset yet where “the primary measure of progress is working software” (the Agile Manifesto).

Bonus Principle: We Suck at Estimating

Most people doing estimation in traditional project management try to measure in units like person-days or dollars.  There is no doubt that these units are useful if you can get good estimates.  However, most of the people doing estimation are fundamentally and irredeemably bad at it.  How do I know?  Because they are not wealthy… and have thereby proven that they cannot predict the future.  If you can predict the future, even just in limited circumstances (like estimating effort or revenue), you can leverage that to generate almost untold wealth.  Given that, it is fruitless and wasteful to try to get better at estimating.  Instead, the principles of Agile estimation help us focus our attention on the right things: collaboration, comparative estimates and doing them fast so we can get to the real work, and most importantly: delivering valuable results now.  Understanding these principles helps teams overcome many of the struggles they have in using Agile estimation techniques.

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

Welcome to LEGOLAND

I was observing a workshop last week that had been put together to create greater cohesiveness in a large organizational team who needed to create a unified vision about their department.

Initially they were broken up into smaller groups to discuss some of the ideas, issues, and challenges they had encountered.  It was obvious how stressed everyone was.  People were speaking animatedly with louder than usual volume, there was a great deal of tension, and everyone seemed agitated and uneasy.

Then came the LEGO.  Mountains of it.  Not just some mismatched pieces either. The kind of LEGO that would have made any child squeal with joy.

LEGO

Each person was asked to create a model of what they thought their department was like at that moment, using the LEGO.  Then another model of what they each envisioned their department could be.  They were then asked to combine the ones they thought were best into a grand model for the department.

I immediately recognized this approach of play therapy used in child psychology, and I was curious to see how it would translate to adults in the workplace.

The effects were wonderful.  The room that was once filled with heated arguments and loads of stress, had transformed into complete calm.  Everyone was so engaged with building their models, they were quiet and relaxed, and whenever there were bursts of noise it was joyful laughter.

Then came the moment of truth, they had to present the large departmental model that they had all collaborated and contributed to making.

They spoke of their vision clearly without argument or dissent.  They shared the space freely encouraging others to speak on parts of the model they didn’t know in detail.  And when they finished their presentation, there was a long pause of silence where everyone was looking at the model, and in each person’s eyes, I saw pride for what they had accomplished together, and a deep sense of hope for the future where it was absent before.

I guess those colourful blocks really do have some magic in them.

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

Real Agility Program – Recommendations (Assessment and Playbook)

Recommendations IconWe have already written about how Leadership and Delivery Teams operate in a Real Agility Program.  It’s time to look at our Recommendations component: getting started on the right path for Real Agility.

Recommendations = Assessment + Playbook

In the assessment portion of the Recommendations component, we gather information about the current situation at an organization.  This includes everything from detailed practices, processes and tools, to strategies and organizational culture.  This assessment work is designed to help everyone understand the organization’s current gaps, and what strengths it has that will best support it to cross those gaps to Real Agility.  The Assessment includes an online portion, an on-site portion and an off-site portion.  The assessment work naturally leads to the development of the playbook.

The online assessment requires that each person throughout an organization complete an online survey about corporate culture.  It includes three major sections: existing challenges, sense of urgency, and level of teamwork.  This cultural survey is the foundation of understanding how to be successful with Real Agility.  Managers and leaders are also asked to complete an additional questionnaire about the current environment at the organization.  This includes high-level information about the structure of the organization, client and vendor relationships, and staff.  Additional surveys may also be administered to understand other aspects of the organization.  For example, in an organization that is struggling to use Scrum, we will often use the Scrum Team Assessment.

The onsite portion of the assessment combines in-person interviews and workshops with staff and managers.  Interviews explore aspects of the corporate work environment in more depth and include questions about familiarity with Agile methods, and obstacles that people might see to adopting Agile.  The workshops gather data around current challenges and strengths, success criteria for projects, situational analysis for teams, and existing metrics (or lack thereof).  Typically we need a meeting room committed to our consultants for doing interviews.

The offsite portion of the assessment is used for us to evaluate and analyze the survey, interview and workshop results.  We also use some time to review any relevant documentation such as process templates, org charts, governance requirements, etc.  We may also use some of this time for follow-up phone calls or emails to clarify aspects of the assessment results.  Finally, this offsite work is also where we do the bulk of the development of the recommendations in the playbook.

Several aspects of our assessment are based on the OpenAgile Catalyst Assessment Tools which are open-source and can be found online.  We also have a number of proprietary tools.

The playbook maps out a path to a successful Real Agility transformation.  It is a road map that helps leaders, managers and team members make good business decisions as they strive for Real Agility.  The playbook aids the organization to effectively and appropriately launch Real Agility teams: management teams, project teams, and operational teams.  The Real Agility Program playbook includes analysis of the assessment results, recommendations for work that the organization can do on its own and suggests outside assistance that enhances Real Agility results.  Two critical questions that are answered in the Playbook include:

  • What Agile method or methods should we be using and why?
  • What organizational change approach should we take and why?

We deliver the recommendations in the form of the playbook and an executive summary slide deck in an iterative and incremental fashion so that stakeholders can give us early feedback and so that we can adapt our assessment agenda as we go along.  The recommendations include ideas about organizational structure, staffing, governance changes, departmental relationships, tooling, and many other aspects of how an enterprise can best become and Agile enterprise.

Following the Recommendations in the Real Agility Program playbook results in huge time-to-market improvements, 200% (or better) productivity boost for delivery teams, and extremely satisfied customers and staff.

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

Leveraging the Team for Good PDPs (if you need them)

I am currently working with a relatively new Scrum team (5 Sprints/weeks young) that needs to rewrite their Personal Development Plans (PDPs) in order to better support Scrum and the team.  PDPs are still the deliverables of individuals required by the organization and likely will be for some time.  The organization is still in the early days of Agile adoption (pilots) and they are large.  So, instead of giving them a sermon on why metrics for managed individuals are bad, I am going to help them take the step towards Agility that they are ready to take.

The Plan:

  • Facilitate a team workshop to create an initial Skills Matrix;
  • work as a team to develop a PDP for each individual team member that directly supports the team’s high-performance Goal (already established)—
    • in other words, when considering an appropriate PDP per individual, the team will start with the team’s performance Goal and build the individual PDP from there;
  • develop a plan as a team for how the team will support each team member to fulfill his/her individual PDP—
    • in other words, all individual PDPs will be part of the team’s plan for team improvement;
  • Internally publish the plan (share with management).

I’ll follow up with another post to let everyone know how it goes.

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

Minor Update: Seven Essential Teamwork Skills

I was recently checking my Google Analytics for Agile Advice and the article I wrote quite a while back in 2009 about teamwork skills is even more popular than the front page of this blog!  I took a look at it and made some tweaks including providing some good references for more information about each of the teamwork skills.  Take a look: Seven Essential Teamwork Skills.  The only hard one was to find a good article about “sharing” as a teamwork skill.   If you know of one, please comment so that I can add it!  I’ll even be happy to take a link to an article you have written yourself.

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 Inception: Facilitating Innovation Towards Valuable Results

I recently had the opportunity to help facilitate a client’s “Innovation Challenge”.  Basically, the concept is to get a bunch of people in the room, give them a business challenge and see what they come up with.

I have to say that the format of the workshop that I used is heavily inspired by a training that I did recently called Specification By Example by Gojko Adzic.  I strongly recommend this seminar as well as the book.  Another strong influence is The Inmates are Running the Asylum… by Alan Cooper.  The workshop that I have developed is a sort of hybrid approach, with my own flavour added to the mix.  During an early iteration of the workshop, I didn’t have a title and one of the participants suggested “Agile Inception”.  I think that title works in a space where Agile is established and well understood (e.g. hopefully this blog).  At the same time, this workshop can be run with people who have no prior experience or knowledge of Agile and without even mentioning the word Agile.  This is also good in certain environments where people have developed an Agile allergy.

Anyhow, my goal for the day was to facilitate the building of shared understanding of the challenge itself as well as some ways that the organization could innovate around that challenge through conversation and collaboration.

From the opening remarks it became clear that the product at the centre of the “challenge” was actually in deep crisis:  a shrinking market combined with shrinking market share.  The product had generated approximately $18M in revenue in 2009, compared with $10.4M projected for 2014.  That’s half dead in some people’s books.  The clear Goal was to reverse that trend, starting with at least $11M in 2015.  They needed a powerful jolt of life-giving innovation energy to defibrillate their failing product’s heart.

There were no shortage of ideas about how the product could become better & more profitable.  In fact, there were many, many ideas.  Too many, perhaps.  Once we had established our working agreement for the day, we did a Starfish Retrospective exercise to make visible all of the things that the group wanted to keep doing, start doing, stop doing, do more of and do less of.  Many post-it notes were stuck on the board and we left them there as a reminder of all of the things that people were thinking about that could help us to consider how the product and ways of working on it could be improved.

Then we talked about the Goal.  True innovation—that is, tangible, innovative results with clear benefits—requires a group to focus on a single, clear, SMART (Specific, Measurable, Achievable, Relevant and Time-bound) Goal that everyone in the organization understands and is committed to achieving.  Often times, as was the case with the group on Thursday, taking time to establish shared understanding of the goal can seem redundant and tedious (“we already know what the goal is…”).  However, as we learned through the process of working in small groups to re-articulate understanding of the Goal back to the “customer” (the person paying for everyone to be there) this often requires some further conversation.  Indeed, when the groups presented their understanding of the Goal, there were gaps that needed to be filled by the “customer”.  It took less than 30 minutes to discuss, adapt and confirm the Goal with the customer.  The value of this investment of everyone’s time was tremendous.  The conversation made it clear that shared understanding had already been established to a degree and enabled the group to build on what was already there to make the Goal “SMARTer” in the minds of all of the participants.

A single, transparent business Goal helps us to innovate with focus—to create the right thing.  In addition, we need to develop a single Persona—the ideal, “imaginary” user of the product.  The larger group broke into smaller groups for the subsequent discussions.  The groups worked separately and generated a the details for a few personas.  All 3 personas added value to the conversation.  The Persona of “Lisa” was particularly compelling to the “customer” because she had a clear goal of her own and through innovation, her goal could be aligned with the overall business Goal to create a powerful, “new” product that just might reverse the downward trend.

The next step in innovating with focus in order to generate the best ideas possible: build shared understanding of how Lisa can pursue her goal through her experience of the product in order for the business Goal to be achieved.  In other words, Lisa needs a story.  Her story needs a beginning and an end (for now, until the next story) and all the stages of her journey need to be integrated into a coherent whole.

The last step was for the groups to brainstorm and come up with different ways that the product can deliver Lisa’s story in order to realize the Goal.

I wish I could say more about the really cool ideas that the group came up with, but I am erring on the side of caution when it comes to protecting my client’s competitive advantage.

To wrap up the session, we took a quick, anonymous gauge of how confident the participants felt about achieving the Goal.  Of the 13 participants, two gave their confidence a score of 8/10, six gave a score of 7/10, four scored themselves a 6/10 and one was a 3/10, for an average of 6.5/10.  Not bad, but clearly some work still to go.  So what’s next for them?

Next steps:
  • Get the technical folks involved in the conversation (ideally, they are there from the beginning)
  • Build an increment of their solution
  • Review
  • Continue the conversation and collaboration to build shared understanding 
  • Re-gauge the confidence score
  • Iterate  
  • Repeat 
  • The likelihood of achieving the Goal increases with every iteration

 

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 Real Agility Program – Execution and Delivery Teams

Execution IconIn a recent post, Mishkin outlined the Leadership Team component of the Real Agility Program.  While the Leadership Team track focuses on developing leadership capacity for sustained transformation, The Execution track focuses on launching and developing high-performance project, product and operational teams.  This track is the one that most of our clients use when they run Agile pilot programs and is a critical component of getting quick wins for the organization.

Groundbreaking works such as The Wisdom of Teams (Katzenbach & Smith), The Five Dysfunctions of a Team (Lencioni) and Drive (Pink) have served well to distill the essential requirements of high-performance teams.  Scrum, Kanban, and OpenAgile are proven frameworks that optimize the value of teams and create the necessary working agreements to help teams reach that high-performance state.

The Delivery Team track of the Real Agility Program creates new, cross-functional, multi-skilled, staff-level teams of willing individuals.  These teams are responsible for delivering value—business results and quality.  Individuals are committed to the performance of the team and the organization.  Teams develop the capacity to self-organize and focus on continuous improvement and learning.  A team is usually composed of people from various roles at the delivery level.  For example, and IT project team might be composed of people whose previous* roles were:

  1. Project manager
  2. Business analyst
  3. Software developer
  4. Tester
  5. Database developer
  6. Team lead
  7. User experience lead
  8. Intern

* These roles do not get carried into the new delivery team other than as a set of skills.

The track begins with establishing pre-conditions for success including executive sponsorship, availability of team members and management support.  Team launch involves a series of on-the-job team development workshops designed to enable the teams to create their own set of values, working agreements and high-performance goals.  Teams are guided in the creation of their initial work backlogs, defining “done”, estimation and planning and self-awareness through the use of a collaborative skills matrix.  The teams are also assisted in setting up collocated team rooms and other tools to optimize communication and productivity.

Qualified coaches assist the teams to overcome common issues such as personal commitment, initial discomfort with physical colocation, communication challenges of working with new people in a new way, management interference and disruptions and appropriate allocation of authority.  This assistance is delivered on a regular schedule as the team progresses through a series of steps in the Execution track process.  Usually, these steps take one or two weeks each, but sometimes they take longer.  A team that needs to get to a high-performance state quickly might go through the entire program in 10 or 12 weeks.  In an organization where there is not the same urgency, it can take up to a year to get through the steps of the track.

The coaches for this Execution track also help management to resist and overcome the strong urge to manage the problems of the teams for them.  In order to develop through the stages of team development, teams need to be effectively guided and encouraged to solve their own problems and chart their own courses towards high-performance.

The goal of the Execution track of the Real Agility Program is to help the team go through the stages of forming-storming-norming and set them up to succeed in becoming a high-performance team.  Of course, to do this requires some investment of time.  Although the Execution track is meant to be done as on-the-job coaching, there is a 5% to 20% level of overhead related to the Real Agility Program materials themselves.

See also the article on the Recommendations component of the Real Agility Program.

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

Updated: Agile Estimation with the Bucket System

I have added a pdf download of this article about Agile Estimation with the Bucket System.  It’s just a handy, nicely-formatted document that can be used for quick reference.  It is now part of the materials I give out for my Certified ScrumMaster training classes.

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

Real Agility Program – Leadership Transformation Team

Leadership IconOne 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.

See also our article about the Recommendations component of the Real Agility Program.

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

Two reviews of SAFe (Scaled Agile Framework)

SAFe (Scaling Agile Framework) is gaining in popularity.  Ron Jeffries recently attended a SAFe training session and has written a great review.  I particularly like what Ron says about the idea of being properly Agile:

SAFe will be successful in the market. People will benefit. They just won’t benefit nearly as much as they might if they set out to do things in a fashion that truly supports Agile Values and Principles.

SAFe is good. It’s just not good enough. It provides some benefit, but endangers an organization’s progress toward really high functioning. As someone who has been in the Agile movement since before it started, I do not like it. It’s fast food. You can do better.

 

Neil Killick seems to have even stronger opinions about SAFe, and is quite direct about them.  I like what he says in one of the comments on his blog post:

So you can go the SAFe path or the Scrum and Agile path. All you need to do i[s] figure out how big a cliff you want to deal with down the road.

I don’t personally have any experience with SAFe so I won’t make any big claims about it either way.  However, I do appreciate that the popularity of SAFe, like the popularity of Agile/Scrum* will probably lead to studies showing modest qualitative improvements of 20% to 40% increases in productivity.  Is this just the Hawthorn Effect at work?

When I help an organization with Agile principles and methods, I hope and expect dramatic measurable improvements.  Sometimes this results in people losing their jobs.  Sometimes this means people have nervous breakdowns.  It can be very painful in the short term.  SAFe, by it’s very name, seems to be anti-pain.  That doesn’t bode well.

Here are a few other interesting links to information about the Scaled Agile Framework:

Has SAFe Cracked the Large Agile Adoption Nut? – InfoQ

Unsafe at Any Speed – Ken Schwaber

Kanban – the anti-SAFe for almost a decade already – David Andersen

* There is no such thing as “Agile/Scrum” but that’s what lots of people call Scrum when they don’t do Scrum properly.

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

Reflections on Agile Business Leadership

From push system to pull system thinking

One of the disconnects holding teams back the most in an organization embarking on an Agile transformation is the lack of will and perhaps understanding of vision on the part of the business. The required shift in thinking is from a “push system” to a “pull system”. Historically and still culturally, most organizations, even those claiming to be ‘Agile’ are very much push systems. The business folks in client services – VPs, Directors, sales people, etc. seem to make time (deadline) commitments to clients on behalf of teams and then the teams are given the deadlines to finish the work. Sometimes, the deadlines are decided on in consultation with particular individuals on the teams and very rarely, if ever, with the actual teams themselves. In any case, the fact that the business is almost entirely deadline-driven is the centre of the push system. Deadlines push or drive everything else. Deadlines are fixed and often considered non-negotiable. Deadlines are a taboo subject – it is considered a waste of time to even discuss them because they just don’t and won’t ever move. The general attitude is that if we try to move deadlines, we put the entire business at risk because our clients will drop us and turn to one of our competitors who claim to be able to promise and keep deadlines. If we lose our clients, we lose business, we lose money and it potentially puts us all out of jobs. What this exposes is not only a push system driven by deadlines, but a culture that is actually driven by fear. The not-so-implicit message is that if you miss a deadline, you might lose your job, so you had better do whatever it takes to not miss the deadline. Or else. Push and pull systems and mentalities are like oil and water – they don’t mix. In Agile, there is no place for fear of failure. Rather, teams must be allowed to fail (miss deadlines) and learn from their failures (plan better).

Why quality, not time/cost or scope is non-negotiable

The “make the deadline or else message” is couched and clouded by other talk. The main excuse is to blame the client, as noted above. “That’s just the way our clients work, the way the market works”. Of course, such an excuse contains a kernel of truth. Without a true understanding and embrace of Agile, the idea of not meeting deadlines and the perceived consequences can be truly scary. Generally, there is an understanding from the business that the productivity of teams may drop somewhat as they progress through the storming stage. What this translates into is a difficult discussion with clients around delayed delivery. It is tolerable in that it is temporary. “Once the teams get up and running, we can go back to meeting our deadlines, and even be able to deliver early because Agile is supposed to be faster.” But the benefits of truly adopting Agile are much more powerful than this.

Understanding the true business value of Agile

What needs to be understood is the true business value for investing in Agile processes and practices – how it may add cost and time to the initial development Cycle, but how it saves both the business and the client tremendously on technical debt and support long-term. This needs to be understood and championed by the business in order for the organization to become liberated from its enslavement to the push system mentality. At the heart of such a mental liberation is the wholehearted adoption and commitment to the Agile/Lean principle that quality is non-negotiable. The investment in Agile processes and practices is essentially an investment not only in quality, but in continuous quality improvements towards the goal of being able to frequently deliver products of increasing relevance and quality (value). The ability to ship frequently allows for sustainable growth. All of this is made impossible by the deadline-driven push system mentality/culture of fear.

The urgent need for slack

One of the first things that a team needs in order to focus on continuous quality improvements is slack so that it can learn to learn. The first goal of the business leadership should be to facilitate scope and deadline slack for the team. This goal should also be fully and visibly championed by the business leadership. In order to develop the capability to facilitate slack, the business needs to gain knowledge around the purpose and importance of Agile processes and practices and be able to articulate a strong business case for them. The business leadership needs to develop the skill of educating the team, management and business leadership on the long-term benefits of an Agile transformation – the transformation from a push system to a pull system. The key stakeholders and business leaderships need to possess the courage to engage in difficult conversations with management and clients who may be upset by the short-term pain of delays and missed deadlines and protect the team from continued attempts to push work into the team. Perhaps above all, the business leadership needs to develop an attitude of learning – a humble learning posture that allows for the setting aside of preconceived notions, fears and prejudices around what it means to be a good business leader. A leader possessed of this posture demonstrates a learning attitude by stressing first and foremost the importance of creating slack for the team to learn to learn. It is a common pitfall for inexperienced business leaderships and stakeholders to expect Agile to provide solutions for their push system woes, woes that include the broken trust of clients from consistently broken (unrealistic, dreamt-up) deadline promises and the crippling effects of technical debt (the fallout of the former – when scope, time and cost are fixed, quality is compromised).

If the business leadership, with the support of the Process Facilitators and the Transformation Team, is able to foster the organizational will to create slack for the teams, then the teams will have the space they need to truly focus on continuous quality improvements. This is a critical milestone on the path to realizing the true, measurable benefits of Agile. Although the support of others is needed, the business leadership is in a unique position benefitting from an intimate relationship with both the needs of the business as well as the daily life of the team.

Why the business leadership needs to own the process

The first way that the business leadership creates slack for the teams is by championing the process. In OpenAgile, like all other Agile methodologies, there are key features of the process the purpose of which are to give space for new teams to begin to make the often seemingly inconsequential, yet ultimately critical first steps towards continuous quality improvements. One of the most obvious of these features is the Agile team meetings. In the early stages of team development, organizational understanding and will, the OpenAgile meetings (particularly the Reflection and Learning aspects of the Engagement Meetings in OpenAgile) can easily be discounted as an obstacle preventing the team from getting the “real work” done. What is often forgotten under the pressure of deadlines is the fact that in order for a team to be able to learn to make continuous quality improvements, it needs to develop the capability of systematic (frequent & regular) inspection and adaptation of the way that it works. It is easy to save on the short term pain of perceived non-negotiable deadlines (meeting deadlines at all cost = success) by compromising on investing in the process, especially when the team is still learning to learn and the effectiveness of the meetings is not yet apparent. When the team and the organization have an expectation of Agile as something that fits into the push system and allows for a team to function better within such a system, it can be hard to understand how spending time in a kind of meeting that the team doesn’t seem good at yet can be of any value. This is where the business leadership needs to stand firmly behind the process. The team needs the meetings – the space to reflect, learn and plan – in order to learn to become more effective at making continuous quality improvements – a critical feature of an effective pull system. Without the meetings, the team will never develop this critical capability and as a result, will never become an Agile team. Instead, the team will revert back to getting the “real work” done with all of the quality problems crippling the organization and which led to the decision to adopt an Agile framework in the first place.

Why the business leadership should care about burn-down

Another key feature of the process for the business leadership to understand and champion is the concept of burn-down as represented by the burn-down chart of an Agile team. Agile doesn’t care about how much work the team gets done. It assumes that the team is doing valuable work and getting things done – in other words, that the team is managing itself and working towards its goals and commitments. There are no tools in Agile for an individual, least of all the business leadership, to measure and manage how much work the team is getting done. Agile acknowledges the reality that real (sustainable) productivity cannot be forced on any team. Instead, a team grows its productivity at a sustainable pace when it is given enough slack to do so. The team makes a plan at the beginning of the Cycle based on what it understands about its capacity, works towards that goal throughout the Cycle and hopefully delivers valuable results at the end of the Cycle. By learning to apply the process of continuous improvement, quality and productivity go up hand in hand. That is the essence of the pull model. Through all of this, the team manages “how” it gets work done. The productivity of a team can be measured, but the burn-down chart is neither an appropriate nor effective tool for measuring the productivity of a team. Instead, burn-down provides one specific measurement and ONLY this one measurement: WORK REMAINING (in order to achieve the goal/commitment of the current Cycle). It does not and cannot tell you how much the team got done and even less so the whys and hows of the output and productivity of the team during the Cycle.

So what is the purpose of burn-down and why should the business leadership even care? If it can’t be used as a tool to measure the productivity of the team (in other words, if it can’t be used to manage the team) then what importance can it possibly have? These are typical questions of teams and individuals that are coming from a traditional project management, i.e. command & control, i.e. “push” system mentality. Understanding the purpose of burn-down depends on the ability to make the shift from the push system paradigm to the pull system paradigm. In a push system, burn-down is nice but somewhat irrelevant. For an organization committed to an Agile transformation (towards a pull system of self-managed teams) it is an invaluable launch pad for powerful conversations that live at the heart of continuous quality improvements.

Commitment to the business requirements come from the Agile teams

When a team decides on a plan for a Cycle of work, the plan is a commitment. This is a critical step in the Agile process. It is only after a unanimous commitment from the whole team that the team begins to work on the plan. If any individual team member feels hesitant about the work in the plan, tasks and potentially even Value Drivers should be removed until everyone is comfortable making a commitment. When the business leadership is telling a team what the plan is, then it is not the team’s plan and therefore it cannot be a team commitment. This is not only an inappropriate use of authority, it is also breaking the Agile process. Moreover, when a plan and therefore a commitment is forced onto a team, the team cannot be held accountable for failure. Worse yet, the team will never learn to plan. If a team is not able to plan, then it is not able to make commitments. If the team is overwhelmed by an overly-ambitious, management-forced plan, it will not learn to evaluate its capacity and apply that knowledge to long-term planning and project estimates. It will not learn to make meaningful quality improvements and reflect on its progress. It will not learn to self-manage or self-organize. The purpose of burn-down is to establish commitment velocity. In other words, the amount of work that the team can truthfully expect to complete during the Cycle when it is making the Plan. The difference between the number of tasks in the Cycle Plan and the number of tasks remaining at the end of the Cycle gives the team its commitment velocity. Commitment velocity is always based on minimum historical velocity. The team uses commitment velocity to make a Cycle Plan containing no more than the number of tasks represented by its commitment velocity. This allows the team to spend just the right amount of effort and time on planning and allows the team slack to focus on the truly Agile work of learning and continuous quality and process improvements. Over-planning, especially when it is wedded to over-committing or even worse, non-committing (a common push system mentality pitfall forced onto teams by the business leadership) leaves the team in a state of dependent on daily micro-management and can completely halt the progress of a team. Not to mention that this is a flagrant violation of Agile values (truthfulness, responding to change over following a plan) and principles (sustainable development). Such compromises to foundational Agile values, principles and processes may produce desired results in the very short-term, but the long-term costs can be crippling to teams and organizations. The wasteful activity associated with team dependency on micro-management is what often leads organizations to the accumulation of technical debt that places them in dire competitive disadvantage and desperate need for Agile transformation in the first place. If an organization misses out on this golden opportunity, teams can become demoralized and innocuous to the Agile practices and the promise of an Agile transformation can quickly erode.

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

Leaving your title at the Scrum team room door and pick up new skills!

Each member of an organization has a title or designation that may reflect their responsibilities or profession.  These titles may include BA, Tester, Developer, QA, PM, and others.  It is normal to be proud of our accomplishments, achievements and titles.  Unfortunately in a Scrum team these titles can limit the individual and adversely effect the team.  These same titles can label the individual as that role (example – as a tester) and only that role.  Within a Scrum team we certainly need the skills, knowledge and abilities that come with that title/role, but we do not want to limit that person to being viewed as only that role.  Each of us is the sum total of our experience, education, values, upbringing and history.  All of this is of value to the team.  We should encourage every member to fully participate on the team, to willingly share their expertise, to contribute to non-traditional tasks and to feel they are valued as a complete person rather than a specifically titled individual.   So if the goal is to leave your title behind, then it is implied you can also pick up other skills.
So how can this be accomplished.  One way is a Skills Matrix.   This is a chart that can be posted in the room to identify the skills needed and the people on the team.   On the left column you list all the team members.  Along the top you list all the various skills you need on the team.  Then each person reviews their row, looking at each skill, and then identifies how many quadrants of each circle they can fill in, based on the range below the chart.  The range is from no skills through to teach all skills in a given column.  After filling the columns and rows, now the work begins.  By using pair programming (an extreme programming method) and other methods like self-study and taking additional courses, the team member can begin to learn other skills.  The objective is to have at least two persons on each team who possess each of the skills at the level of performing all the tasks of a specific skill.  The goal is not to have every one do everything but to have a least enough people with specific skills to cover sicknesses and vacations so that required tasks are performed.  This is a method to capture the full extend of each person’s current knowledge, skills and abilities and expand on it.
Skills Matrix
Since they are hard to see, here are the labels for the number of quadrants:
0: no skill
1: basic knowledge
2: perform basic tasks
3: perform all tasks (expert)
4: teach all tasks
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: Cheating at Work

I just finished reading an excellent article about a UCLA prof who, for his game theory class, allowed the students to cheat

I strongly recommend reading this because this points to one of the big cultural barriers to using Agile methods effectively: we are focused on individual performance instead of the outcomes of a group (team) of people!

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 Planning Game – An Estimation Method for Agile Teams

The Planning Game [PDF] – printable reference.

Purpose: estimate the effort for User Stories (Product Backlog Items, Value Drivers)

Prerequisites: all items have a value estimate, each item is written on a separate note card, full team membership is known and available for planning, each team member has a set of planning game cards

Process:

  1. The team goes through all the items and chooses the one which has the lowest effort. Write the number “2″ on this card (usually in the bottom right corner).
  2. The team looks at the item with the highest value.
  3. Each team member thinks about how much effort the team will expend to fully complete all the work for the item. Comparing this work to the work effort for the smallest item, each team member selects a card that represents this relative effort. For example, if you think that it requires ten times the effort, you would select the “20″ card. It is not permissible to select two cards.
  4. Each team member places their selected card, face down, on the table. Once all team members have done this, turn the cards over.
  5. If all team members show the same value, then write the value on the item and go back to step three for the next item. (Or if there are no more items, then the process is complete.)
  6. The person with the highest and the lowest value cards both briefly explain why they voted the way they did. If there is a Product Owner present, this person can add any clarifications about the item.
  7. For any given item, if a person is highest or lowest more than once, then each explanation must include new information or reasoning.
  8. Once explanations are complete, the team members collect their cards and go back to step three.

Notes:
- it is extremely important that the voting for an item continues until all team members unanimously vote the same way (this way team members and outside stakeholders cannot blame any individual for “wrong” estimates)
- in Scrum, it is normal for the Product Owner to be present during this process, but not to participate in the voting
- in OpenAgile, it is acceptable for people serving as Growth Facilitators for a team to participate in the voting
- voting should not include extensive discussion
- if more than one person has the lowest or highest vote, usually just one person shares their reason in order to help the process move quickly
- the first few items will often take 10 or 15 rounds of voting before the team arrives at a unanimous vote
- later on, items may take just one or two rounds of voting to arrive at a unanimous decision
- some teams, where trust levels are high, will discard with the use of physical cards and just briefly discuss votes

The planning game is used at the start of a project with the full list of user stories. In this case, it is reasonable to expect the team to average two minutes per user story, and an appropriate amount of time needs to be set aside to accommodate going through the whole list.

The Planning Game is also used any time that there is a change in the list of user stories: re-ordering, adding or removing user stories, or changes to a single user story. When such a change happens, the team can re-estimate any user story in the whole list. When starting a Cycle or Sprint or Iteration, all the user stories in the list should have up-to-date estimates so that estimation work is avoided in the Cycle planning meeting.

Finally, the team can decide to re-estimate any user stories at any time for any reason. However, it is important for team members to remember that estimation is non-value-added work and the time spent on it should be minimized.

NOTE: The Planning Game is described as Planning Poker on wikipedia.  The version described there has some minor variations from this version.

A closely related method of Agile Estimation is the Bucket System.

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