Suppose, for example, you reach a point in your agile implementation where teams are delivering and executing in a much more productive and efficient way. That begs the question, are they delivering the right things? Now that teams can deliver faster with better quality, how does an organization leverage these newly acquired super-skills? 

The answer is clear: the business and product strategies have to change, too. If teams can deliver faster and more iteratively then we need a product or business strategy that can take advantage of these capabilities. It’s not enough to continuously improve how we deliver. It’s not enough to just keep scaling agile to encompass more and more teams. What we must do is improve our ability to figure out what to deliver next. We need to incorporate feedback, learning, experimentation, and rapid delivery into our business and product strategies—without these all we’ve figured out is a faster, better way to deliver the same old results.

What many organizations have discovered in their adoption of agile is that their organizations are rich in policies and controls that were installed to support a process they no longer use. In order to achieve their organizational agility goals, these organizational policies and processes need to be adapted to match the new agile execution, delivery, and strategy models. For example: If existing release management policies require a 3-month conveyor belt to deploy a completed product but the team can deliver completed product monthly (or even weekly), those release management processes and policies must change in order to take advantage of team’s abilities.

To truly pursue organizational agility, we must tackle and transform emerging constraints— things like signoffs, stage gates, metrics, performance plans, risk management, etc. This goes far beyond team-level problems (or even enterprise agile) to the systemic constraints that stand in the way of true agility.

In his 2009 Blog Post (http://bigv.is/xBNZEe) George Schlitz talks about the need to change these rules.  He states:

“Organizations make rules to operate in the presence of limitations…the rules that were made to operate in the presence of the old limitations must be eliminated or changed, and new rules created to deal with new limitations.”

As organizations improve how they operate they must change their organizational policies to deal with new constraints – not treat the existing policies as constraints themselves.

2012 will be the year that organizations start to turn the corner in their agile adoptions. They will recognize that team- or project-level adoption of Scrum, XP, Kanban, Lean (or some combination of agile processes) is only the first step towards achieving organizational goals. They will realize that organizational policies, process, and often, structures, need to change as well. Some will find the challenge too daunting—But those who figure out how to evolve their organizations; those that make it a priority to effect organizational change in order to meet ever-changing markets; and those that realize a sense of urgency and respond to it will find themselves on the path to true organizational agility.

Works Cited:

1. Schlitz, George. “Agile Removes Limitations…You Must Now Change The Rules.” Web log post. BigVisible Blog. BigVisible Solutions Inc., 10 Nov. 2009. Web. <http://www.bigvisible.com/2009/11/change-the-rules>.

Imagine a sherpa helping mountain climbers reach the summit.  He cannot stay in the rear, waiting for a climber to take the wrong steps and only then correct them.  Not only would this be incredibly demoralizing, but would make the ascent unbearably slow and hazardous.  A sherpa – not unlike a coach – uses his experience to show the best path to reach the peak.  He points out the seemingly harmless ice-patch that hides a dangerous crevasse; he selects the best shelter to protect climbers from an impending storm; and he makes sure nobody in the group falls behind.  The effective Agile coach does the same.
 
But what if a team chooses not to take the coach’s advice?
 
Agile teams are typically self-organizing and often self-managing.   A team can choose to walk a different path than the one suggested by the coach – just as the mountain climbers can choose not to follow the sherpa’s advice.  If the team fails, the coach is there to help pick them up, facilitate the retrospective and the ensuing learning.  No “I told you so” required.
 
But why would a team consciously reject a coach’s advice?
 
The coach is the Agile expert.  Why would a team opt not to follow his or her advice?  This can only due to lack of trust.  If a mountain sherpa takes climbers in the wrong direction, gets them lost, or puts them in peril, it is natural to doubt their expertise.  If an Agile coach provides bad advice, places the team in harm’s way, or in any way jeopardizes the team goal then it would be natural for the team to second-guess her advice.  This represents a breakdown of trust and faith in the coach.  If it persists it is a signal that the coach can no longer be effective and should likely be replaced.
 
Effective Agile coaching is not passive.  It is not simply about making background observations, assessments and comments.  Coaching should be about leadership; it should be about achieving goals; it needs to be about success.  Success does not mean simply learning Agile, but rather using Agile to successfully achieve the business or product goals – successfully reaching the mountain summit.
 

The pdf of the presentation can be found here:

Here are copies of the slides: QA The Agile Way

Agile 2009: Mapping the Change Battlefied

BigVisible Theme Prioritization Scoring Workshop – CSPO Class

Feel free to download and use.  It currently does not weight the relative benefit of implementing a feature (epic, theme or user story) nor the penalty of not implementing though adding the weighting capability is simple enough.

If you are interested in taking an public scrum class with me, check out training.bigvisible.com

Regards,
Giora Morein

I haven’t had time to create any user guides but here are a couple of things that I think would be helpful to know:

1. You will need to enable Macro’s for the sheet to work correctly
2. If you haven’t already done so, you will need to install the Analysis Toolpak Excel Add-In that comes with Excel.  From the Excel Menu, select Tools, AddIns.  Select the Analysis Toolpak and click OK.
3. After entering your Iteration Start and End Dates, click the “AutoShow Columns” button to automatically hide and show the relevant date columns
4. In the Status field, avoid using the “Fill-Down” capability to set the status of multiple fields.  Instead use copy-and-paste for the same result.  You can copy from a single status field and paste to a range of fields.
5. To have the burndown data for a specific day show up in the charts, you will need to enter an “x” in the field directly beneath the date
6. You can modify the categories by changing the list of categories in the table of “Category Burn-Down Data”
7. You can hide specific categories by removing the “x” next to the category name.
8. Send me a note for any additional help – I’ll do my best to get back to you quickly.

I’ve included two sheets: a blank tracker as well as one containing sample data.

Bigvisible Standalone Iteration Tracker v0.9.2

Bigvisible Standalone Iteration Tracker v0.9.2 – Sample Data

Enjoy
Giora Morein
gmorein@bigvisible.com

This is the Scrum Introduction presentation I presented at the first Scrum Israel User Group.

Download the Introduction to Scrum

Download the Presentation