Goldratt describes these things (not directly), and similar phenomenon (like failure of companies to get the real benefits from ERP, SAP, 6Sig, Lean, etc.) nicely:

Organizations make rules to deal with/operate in the presence of limitations.  By rules, I mean rules, processes, structures, and other arrangements and things (see the dictionary definition).

Technology (see the dictionary definition) improvements remove limitations.

For a change to truly take hold and succeed, 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

The concepts above (ERP, SAP, 6Sigma, Lean, and Agile) are technology improvements.

Specifically, Agile, as a technology improvement, removes limitations such as:

• the inability to deal with change
• the inability to deal with uncertainty

Make the Change Stick
For an Agile transition to be truly successful, all the rules that were created when the old limitations existed should be revisited.

1. Remove rules that are no longer useful – these tend to be the ones that were made specifically to address those old limitations
2. Identify the new limitations we have now (they’re out there…a separate article coming soon)
3. Create new rules to deal with these new limitations
4. Rinse and repeat when you find the next improvement

Examples of Rules that May Need Changing and/or Scrapping in Agile Transitions

• Functional Org Structures and Groups
• Documentation-focused processes and steps (this is a huge one…changing how we validate things to how we request things)
• Heavyweight software release processes
• Compliance processes
• HR-related rules – from career paths, to evaluation and compensation, and more

All of these rules that were made when older limitations existed, if they continue to be modus operandi, will sap away the ability to continuously improve and embody the change you are trying to make, leech away energy from your change agents, and eventually result in a transition that has been mediocre at best.  It is exactly this situation that makes it appealing to create a hybrid method – such as combining the UP with Agile.

Changing the rules – A transformation enabler

I do believe that there are other aspects of Agile transitions that are important to consider.  Changing the rules is a major one that is often neglected due to how difficult it is.  Any time you feel like customizing your agile process with something from your former processes, ask yourself if it is because you have found a rule that needs changing!

My opinion may be a bit controversial.

I believe that a coach is whatever she/he needs to be to help their teams get to the next level.  I believe that great coaches are also great leaders, though they are not formally in leadership roles with those they are coaching.

Some organizations are in such a state that they need someone to demonstrate leadership in order to even begin to understand what a leader does in their context, and in such a state that no one available is ready to step up.  In such places, no amount of Socratic questioning, facilitating, dialog, or other hands-off techniques will help them in a reasonable time.  In such places, I imagine those with more strict coach role definitions would declare “they are not ready for <improvement x>”.  I would take a different approach – I might temporarily take on a leadership role to demonstrate, and then hand off the role to a team member.

Important considerations when taking on a leadership role as a coach

When you do this, you are removing your coach hat, and putting on a borrowed leadership hat.  Set expectations clearly:

• this is a temporary, brief, time-boxed situation with specific goals including demonstration and mentoring
• a primary goal of this endeavor is to hand over the leadership role as quickly as possible to a team member
• a primary goal is to put the coach hat back on as soon as possible and to break dependencies on the coach as leader

If you are a coach, you may already be taking on leadership roles

Do you facilitate meetings early in an engagement, such as discovery workshops or other things?  You are acting in a leadership role already.  As I describe above, it is a time-boxed endeavor with pretty clear expectations.  But it is leadership.  The more explicit and accountable the leadership role you take on, the more slippery the slope becomes, but with careful expectations management and a clear plan for transitioning the role to a team member, teams can benefit from your experience and leadership.

Turn them away?

Some believe that the role of the coach is very explicit and that there are clear boundaries, and that some people just aren’t “ready to be helped”.  I don’t.  I believe that I “work on/with the person in front of me,”  in the middle of the problems they have, and that rules sometimes need to be bent to help them in the best way.  If they want to change, and improve, I will do whatever I need to help them.

An example

A team is the first in its organization (a very large organization) to try scrum.  The team is 1 of four working on a large project.  No one on any of the four teams has any experience with scrum, and the culture until now was one of multi-tasking, multiple bosses (“I have five bosses, Bob, five”), and fear of rocking boats/exposing information.  There is little clear leadership.

An approach that worked really well in this situation in multiple organizations for me was to take on a leadership role for a time-boxed period, with the explicit goals of transferring the role to a team member as quickly as possible.  Taking on a scrum master role for a few sprints allowed me – someone with little need to fear breaking with tradition – to facilitate decisions, challenge rules, expose elephants, and more.  Team members saw that all of these things resulted in more success, and a natural scrum master emerged and took on the role, allowing me to focus on pure coaching.

As more teams started trying scrum, there was a new leadership gap – at the program level.  I took on the uber scrum master role – again for a brief time with explicit goals to transfer the role to someone on the team as soon as possible.  The results were repeated – this time at the program level – and the results were teams that functioned effectively as an agile program.

Taking on these roles was a risk…it is a slippery slope to start upon to take on accountable leadership roles.  However, in some places, drastic learning must take place, and in such places, arriving at some answers via questioning and facilitation would take unreasonable amounts of time.  In such places, demonstration and mentoring can be combined with coaching to turn lights on.  More on this topic in my coaching courage post.

What do you think?  I’d love to continue this discussion

I wasn’t taught it…but I did learn it.

One day long ago my professional career seemed torn asunder by an organizational change.  At that time, I believed that all I had worked for was no longer firm ground on which to base my next successes (that is the way it seemed, anyway).

“It is only after we’ve lost everything that we’re free to do anything” – Tyler Durden

I use that quote way too often.  My perception at the time was that I had lost everything.  There was a new regime moving in.  My colleagues resigned themselves to stagnation while the new leaders arrived and established their top-down plans.  This seemed really familiar to me…

“Meet the new boss…same as the old boss…” – The Who

Not wanting to have to repeat the last 2+ years, I chose a different approach.  I started just doing.  Taking on stuff that needed doing, defining my role myself (I helped my managers find the titles that fit later).  Questioning things and providing good alternatives.  Turns out everyone else was questioning the same things, but no one was doing anything about them…one reason is because they perceived that they had a lot to lose.

I’ve learned many things about courage over the years…here are two:

1) Everyone has some amount of courage bottled inside them.  It just doesn’t come out, for many seemingly-good reasons – the obstacles to learning courage.

Why does having nothing make it easy to find courage?  Perceiving that we may lose something or be punished if we act courageously and make a mistake is an obstacle in the way of courageous behavior.  The “easy,” less risky path is almost always the one that everyone takes – not bucking the trend, ignoring the elephant, not calling out an improvement opportunity, not making waves or rocking boats.  “My boss got promoted by not doing these things, should I not behave the same?”  Groupthink and peer pressure make being courageous difficult too.

2) Once someone realizes that good things happen from courageous acts, it becomes far easier for others to be more courageous.

Eli Goldratt, in “Beyond the Goal,” describes a psychological experiment done on Harvard MBA students – strong personalities who would likely be future business leaders (my apologies in case I am getting the details slightly wrong).  A group of these students are shown three very different lines on a card – a short line, a medium length line, and a long line.  They are then showed a second card, on which a line is drawn that is very clearly the same length as one of the three lines (let’s say it is as long as line #2 for clarity).  They are all asked “which line on card 1 is this line most like?”  Though the answer is clearly #2, all of the participants except one have been prepped to answer “line #1″ – the wrong answer.  The final participant, who has not been prepped, chooses “line #1″ – the obviously wrong answer – 90% of the time the test is conducted!

The experiment continues…this time, one of the prepped participants answers correctly – “line #2!”  When one participant bucks the trend (described as “one ray of light”,) 75% of the test subjects also stick to what they believe the correct answer is rather than conforming.

(Note: I can not find the original source for this experiment- please contact me if you can!)

What can we do to help us choose the harder path/path less traveled?

I believe that the things that prevent people from being courageous are obstacles to success.  We – as leaders, coaches, scrum masters – are here to remove obstacles from our teams’ way.  Assuming courage is a success factor for projects (which I do, especially on Agile projects), how can we encourage it?

We can’t teach courage, but we can certainly remove the obstacles that prevent people from acting with courage

1) Create the “one ray of light” that will break the conformity trend.  Demonstrate courage the first time.  Leading by example as a coach or scrum master, you can show a team that courage is desirable.    Some very simple examples that have worked for me include:

• Admit to a mistake very publicly and proudly.  I’ve found making very public a mistake of mine and its impacts results in others sharing their own more, and taking more accountability – it breaks the ice for others to realize that mistakes are part of learning.  This is the easiest way to start changing a team culture from one of introversion to one of collaboration and teamwork
• Escalate a particularly uncomfortable team obstacle to leadership and facilitate its resolution.  This can be really effective if the obstacle is one that team members believe is not going to be resolved.  That overwhelming release/migration process that no one wants to call out, for example, or some other set of rules that the teams just feel are just “the way it is” and that they have no hope of improving

2) Encourage courageous acts.  When you see them, point them out.   Discuss as a team how courage resulted in good things (for example, talking about an “elephant in the room” helped us have a great group discussion that resulted in starting to consider addressing the big issue that was previously being ignored).  Make courageous acts infectious.  Use informal awards (I’ve seen “Zena” and similar awards used informally for such things).  Help a team member champion an idea that may not be popular or an easy sell.

As a coach, scrum master, or other leader, do whatever you can to create an environment that rewards courage.  Sometimes this means leading by example to be the “one ray of light” illuminating an elephant.  Sometimes this means admitting to an embarrassing mistake and helping the teams realize the benefit of sharing mistakes/learning.  And sometimes this is simply helping a team member be courageous themselves.  Whichever, I see coaching courage – removing the obstacles to learning courage – as a constant role of servant leaders.

Are you considering a coach?

If you aren’t, are your organization and projects at risk?

Fire! Ready, Aim…
Many organizations, thinking that they can’t afford or don’t want to invest in coaching or training, read a book and some articles, and tell their teams that they are now doing Agile.

I have never seen a team get great benefits from Agile in this way.  When I am coaching, and I hear other teams that aren’t being coached say “we’re doing Agile,” I raise an eyebrow (in my mind anyway), and find out if I can spend some time with them to see what they are doing.  Without fail, these teams are doing “Scrum but,” “CrAgile,” “Scrummerfall,” or some other thing that only resembles an Agile method minimal ways.   There are many articles on these topics.

How might coaches be engaged?
I’ve heard that some people use the analogy of a Soccer Team to make the point about what a coach is and how coaches might be engaged:

Wing It
Consider a soccer team.  You could read about soccer in various books and other references, and then attempt to play.  Chances are, though you may learn some of the basic rules, your team will not perform that well without great luck.

The Clinic
You could have this team go through a 1-week soccer clinic to improve their abilities.  They will probably learn some new tricks, maybe a bit of strategy if you’re lucky.  But rarely will such a brief improvement effort result in drastic, long-term improvement as a team.

The Ramp-Up and Check-In
Now consider the same team if they had involvement from the expert who held the clinic for 3-4 months.  The coach could provide the same techniques and training, and apply them to real situations as the teams go through them.  This is FAR more powerful learning – it is contextual, it is about the team and its real challenges.  They can follow guidance as they are working and incorporate it into the way they do things.  The coach can also keep an eye on things that are nearly impossible to observe in the clinic- team dynamics, organizational obstacles, and more – and help any time they find a need.  The team’s game can really improve.  If you have a good coach, the team actually may even get to the point where it is able to improve on its own- perhaps the team members have watched the coach and adopted his/her techniques to observe and question and find improvements.  After a few months of working together, the coach can scale down her/his involvement, perhaps to the point where she/he is called in as needed and to perform periodic check-ins and assessments.

Though this is a far more powerful model, it may not sufficient – for all large/complex/business-critical projects that cost lots of money.  These projects and programs are the “pro” league of the project portfolio, and any opportunity to mitigate risk should be considered.  There may be argument that it is not even sufficient for smaller projects and programs, because much of the value a coach could add happens real-time, as the project is going through its iterations, as challenges arise (unexpectedly).  Depending on how infrequently your teams have help available, they may not be getting the help when they need it most.

The Embedded (the “pro” league of product development?)
Sports teams expected to perform at any professional level follow a different model of coaching – they have coaches and experts that stay around all the time.  The level at which they are expected to perform  makes the cost of great coaches and trainers a good investment.  The risk of not having a coach far outweighs the cost.  How does this compare to your projects?

Do you have a project on which you are spending  millions each year?   That sounds like a risky endeavor, considering project success rates over time (See any popular project success rates research etc).  Having a coach on board or accessible at all times can help your team deal with the infinite number of challenges that it may run in to.   Are you an executive that has “shelved” a multi-year, multi-million dollar project?  This is about you.

The bulk of the coaching value-add is probably not in specific things like Agile practices and techniques, but in other, less concrete things – like dealing with situations that aren’t covered in the books, maintaining focus despite difficult situations, mentoring leaders in the team, facilitating brainstorming, guiding team members in problem analysis, and helping to identify goals for continuous improvement.  If your coach is effective, teams will make measurable improvements every iteration- much more consistently than without one.

Effective coaches are rare, and they don’t come cheap (if you find one that does, start asking around for references ).  But they are a force multiplier, and a massive risk mitigation technique.  The cost of this level of risk mitigation pales in comparison to the benefits  – in continuous team improvement, in mentoring of future leaders, and in the pursuit of organizational agility.

An example…(We have many…)
You may be doing a great job of allowing your teams to follow the guidance they’ve been given and execute Agile very well.  Great job!   Product owner (PO) of project X, one of the highest-budgeted projects in your organization, realizes that a feature set that was originally deemed extremely important has been exposed as a nice-to-have,  or maybe not really necessary at all (a very common situation on well-executed Agile projects).  What should the PO do?

Clearly, the PO should talk to the stakeholders and let them know that we could save $400k on the development of this feature set that we would have otherwise spent.  Is it that clear?  Is YOUR organization ready to handle this situation?  Would the project be deemed a success and the fact that it was ended early be treated as a win, or would the message be that it was ‘canceled’?  What would happen to the project team if they were done early?   Would your organization be able to get this high-performing team a new project that actually has critical importance, or would they be disbanded?  Would your organization be able to re-allocate those funds to the next most critical endeavor?  In many organizations I know of, there are many reasons why a PO in such a position might not choose to terminate the project early (would it be uncertain to the PO what they would move on to?).  These are organizations that have not taken Agile and Lean to the enterprise level.

A coach provides an objective, guiding voice.  Any coach worth his or her salt would help the PO and stakeholders realize the opportunity and the reasons why the opportunity might be tough to take advantage of.  They could then help the right decision to be made, and help the organization improve so that it will be better able to handle this situation in the future – by exposing this “organizational obstacle” to agility and helping the organization resolve it.  If there were a coach in the aforementioned situation, would that have saved the organization $400k in poorly-spent development costs and earned them $___ in benefits from the more important efforts that those funds could be devoted to (which otherwise would be opportunity costs)?

There are many things to consider when you are deciding about hiring a coach.  It’s not all about Agile, training, and practices.  It is about success and risk management, and about prevention of the common phenomenon of less-than-sucessful Agile implementations.

Are you considering a coach?

If you aren’t, are you putting your organization and projects at risk?

Play a game of pick-up
Many organizations, thinking that they can’t afford or don’t want to invest in coaching or training, read a book and some articles, and tell their teams that they are now doing Agile.  A few daily meetings later, an Agile project is born (well…something is born…).

I have rarely seen a team get great benefits from Agile in this way (except for when these teams already had heavy experience with XP and Scrum on successful projects).  When I am coaching and hear other teams that aren’t being coached say “we’re doing Agile,” I raise an eyebrow (in my mind at least), and try to spend some time with them to see what they are doing.  Without fail, these teams are doing “Scrum but,” “CrAgile,” or some other thing that only resembles an Agile method in minimal ways.  You might find that teams that do this actually are hiding information more than they did in the past (though the opposite should be true), by simply telling stakeholders and outside parties “leave us alone – we are doing Agile.”

See articles about these topics as well as “Scrum Tests” for a quick sniff-test that can be done in minutes (though not a substitute for more in-depth assessment, it can point out a CrAgile implementation quickly).

How might coaches be engaged?
I’ve heard that some experts (including Ken Schwaber, co-creator of Scrum), uses the analogy of a Soccer Team to make the point about what a coach is and how coaches might be engaged (my take on this analogy):

The Clinic
Consider a soccer team.  You could have this team go through a 1-week soccer clinic to improve their abilities.  Chances are, they will learn some new tricks, maybe a bit of strategy if you’re lucky.  But rarely will such a brief improvement effort result in drastic, long-term improvement as a team.

The Ramp-Up and Check-In
Now consider the same team if they had involvement from the expert who held the clinic for 3-4 months.  The coach could provide the same techniques and training, and apply them to real situations as the teams go through them.  This is FAR more powerful learning – it is contextual, it is about the team and its real challenges.  They can follow guidance as they are working and incorporate it into the way they do things.  The coach can also keep an eye on things that are nearly impossible to observe in the clinic- team dynamics, organizational obstacles, and more – and help any time they find a need.  The team’s game can really improve.

If you have a good coach, the team actually may even get to the point where it is able to improve on its own- perhaps the team members have watched the coach and adopted his/her techniques to observe and question and find improvements.  After a few months of working together, the coach can scale down her/his involvement, perhaps to the point where she/he is called in as needed and to perform periodic check-ins and assessments.  The duration

Though this is a far more powerful model, it may not be the ideal for all large, complex, business-critical projects that cost lots of money.  These projects and programs are the “pro” league of the project portfolio, and any opportunity to mitigate risk should be considered.

The Embedded (the “pro” league of product development?)
Sports teams expected to perform at any professional level follow a different model of coaching – they have coaches and experts that stay around all the time.  The level at which they are expected to perform  makes the cost of great coaches and trainers a good investment.  The risk mitigated and value generated by a coach far outweighs the cost.  How does this compare to your projects?

Do you have a project on which you are spending  millions each year?   That sounds like a risky endeavor, considering project success rates over time (See Chaos report, or ask around at most large companies).  Having a coach on board or accessible at all times can help your team deal with the infinite number of challenges that it may run in to.   Are you an executive that has “shelved” a multi-year, multi-million dollar project?  This is about you.

The bulk of the coaching value-add is probably not in specific things like Agile practices and techniques, but in other, less concrete things – like:

• dealing with situations that aren’t covered in the books
• maintaining focus despite difficult situations
• mentoring leaders in the team
• facilitating brainstorming
• guiding team members in problem analysis
• championing and effecting continuous improvement despite any challenge
• identifying organizational obstacles and helping the organization overcome them

If your coach is effective, teams will make measurable improvements every iteration- much more consistently than without one, and the coach will be less necessary every day (at least in the ways they were needed originally).

Effective coaches are rare, and they don’t come cheap (if you find one that does, start asking around for references ).  But they are a force multiplier, and a massive risk mitigation technique.  The cost of this level of risk mitigation pales in comparison to the benefits  – in continuous team improvement, in mentoring of future leaders, and in the pursuit of organizational agility.

An example…(We have many…)
You may be doing a great job of allowing your teams to follow the guidance they’ve been given and execute Agile very well.  Great job!   Product owner (PO) of project X, one of the highest-budgeted projects in your organization, realizes that a feature set that was originally deemed extremely important has been exposed as a nice-to-have,  or maybe not really necessary at all (a very common situation on well-executed Agile projects).  What should the PO do?

The PO probably should talk to the stakeholders and let them know that we could save $400k on the development of this feature set that we would have otherwise spent.  Is it that clear?  Is YOUR organization ready to handle this situation?  Would the project be deemed a success and the fact that it was ended early be treated as a win, or would the message be that it was ‘canceled’?  What would happen to the project team if they were done early?   Would your organization be able to get this high-performing team a new project that actually has critical importance, or would they be disbanded?  Would your organization be able to re-allocate those funds to the next most critical endeavor?  In many organizations I know of, there are many reasons why a PO in such a position might not choose to terminate the project early (would it be uncertain to the PO what they would move on to?).  These are organizations that have not taken Agile and Lean to the enterprise level.

A coach provides an objective, guiding voice.  Any coach worth his or her salt would help the PO and stakeholders realize the opportunity and the reasons why the opportunity might be tough to take advantage of.  They could then help the right decision to be made, and help the organization improve so that it will be better able to handle this situation in the future – by exposing this “organizational obstacle” to agility and helping the organization resolve it.  If there were a coach in the aforementioned situation, would that have saved the organization $400k in poorly-spent development costs and earned them $___ in benefits from the more important efforts that those funds could be devoted to (which otherwise would be opportunity costs)?

There are many things to consider when you are deciding about hiring a coach.  It’s not all about Agile, training, and practices.  It is about success, risk management, and organizational agility – and it may be worth considering as a critical success factor on important projects.

Nearly every large organization does it.  Just when we think we’ve learned…made an impact…demonstrated that success is possible on large projects in massive organizations riddled with problems…the need to control takes over, and lessons are lost.  Outdated management theory that has stifled innovation in our businesses for decades is reapplied.

Enter the Methodologists
Heretofore sitting quietly on the sidelines, safely watching without involvement as the new methods resulted in true change, the methodologist and other pointy-haired bosses emerge.   Surely success can’t be the result of a framework which allows teams to decide the best course of action in pursuit of shared vision and goals.  Now that they’ve succeeded, we must formalize and document exactly what they did, create a new set of steps, phases, templates, and more – so that we can roll out our “Enterprise Agile Framework” cookie-cutter style to the rest of the organization.  Because the team that succeeded was an anomaly- normal teams can’t succeed that way.

Usually what follows is the change effort that has started to grow on its own is halted as these “experts” attempt to break down the success, Newton-style, into all of its identifiable parts.  They convince leadership to not start other Agile projects until they have defined the framework…the model.

A “hybrid” methodology is born…the change effort dies…and with it, so dies improvement…because:
•    Projects following the new formalized method aren’t as successful and suffer from the same challenges as those before Agile was introduced
•    By defining the process we are breaking most of the Agile manifesto principles (especially #1 “[we value] Individuals and Interactions over Processes and Tools”)
•    As Laura Ingalls Wilder describes above, peoples’ roles are relegated to filling out templates and following steps, not developing successful product
•    Agile is a holistic, principles-based concept that is not just another set of steps, documents, roles, and phases

If this sounds like your situation, your Agile adoption may already be over.  If you are a leader in such an organization, do what you can to stop this search for the Holy Grail– you won’t find it – what you find won’t be magical at all.  Refocus those proposing this re-application of old mental models before you are sentenced to eternal mediocrity.

Hybrid Methods – The Beginning of the End of your Improvement Efforts
Saying we are going to use a “hybrid” method is a polite way to describe the desire to not solve organizational dysfunction of some kind.    Your improvement effort has uncovered some nasty reality of the way you do business that is so frightening that you’d rather hide it than correct it.  (“It would shake too much up!”  “Too many people have built decades of their growth on these old problems- what a political nightmare it would be to change them!” “What would all those managers do with their time when it seems we don’t have roles for them?”)  Instead, re-introduce some of the old ways we used to sweep the problems under the *cough* –  deal with the problems – create some formal steps and documents to fill out that ensure that no one is accountable (“It’s not my fault- I did my job – I filled out my templates…”), and nothing need change.

Packaged Process Solutions – Miracle Cure in a Bottle (or, Hair of the Dog)
I am hereby calling out all of the consultancies that offer packaged process solutions as salesmen of miracle cures.  Shame on you for taking advantage of the suffering.
Organizations in the normal, healthy part of a successful change effort (wherein huge amounts of pain are experienced as their organizational antibodies attempt to reject the foreign bodies that have been introduced) are weak.  They are in pain.  The reality upon which they’ve based countless decisions (and many, many millions of dollars) has been torn apart by small teams determining for themselves how to develop product without the massive frameworks defined by brilliant methodologists – and it is a big pill to swallow that the real solution is far simpler.  These organizations are going through withdrawal, and the bottled miracle cure offered by the consultancy is oh so tempting…like a drink during a hangover, the one puff two weeks into quitting cigarettes, or a fix when going cold turkey.  It would be so easy to just buy my way out of this…make all the problems and pain go away…not have to change anything.  And if the packaged process doesn’t work, it won’t be my fault (not anyone who is left to implement it in the organization, anyway).

The realities of packaged process solutions
•    The consultancies that come up with them rarely use them…and those few that do have much more highly controlled environments in which to execute than you do
•    The more you “balance agility with [ceremony]” the farther you get from the real factors that influence project success (there is “Too Much Stuff“)
•    They are an easy way out of having to overcome your dysfunctions
•    You will likely not be very agile, and will likely suffer from the same problems you always have

If you are in the middle of an Agile adoption, and you have a moment to reflect, and hear the proposal of a packaged agile process solution, raise the red flag.  Agile is not just another set of steps, documents, phases, and roles – it is a fundamental change in the mindset and culture of everyone involved in product development.

If you go with the Enterprise Agile Framework – either in the form of the home-grown “hybrid” method or the packaged process solution
Change is really hard – sometimes too hard to handle.  There is no shame in not being able to make it all the way.  The bigger the organization, the more difficult it is to change.  Call us when it has not resulted in massive improvement.   Agile is a 12-step program to get over traditional method addiction, and good coaches will never turn away someone who admits they have a problem.

I am not a methodologist, though I love to learn about all kinds of software development methods. They seem to cover all bases. It all makes sense – no more mysteries. Surely when following these steps, I won’t miss a thing! Seeing a detailed method laid out in a process flow diagram gives me comfort. Every artifact I can imagine is documented and approved somewhere. I can see where everything goes from idea to code to product. I will know where we are going wrong every time…The promise of complete knowledge!

So why don’t these methods result in more success?
I have become convinced that 2 major reasons (in addition to the commonly-discussed problems) they don’t result in more success are

1. there is just too much ‘method’ in SD methodology. There is too much ’stuff’ to do, and
2. by virtue of having steps and artifacts assigned to roles, people are no longer responsible for the product, they are responsible for ’stuff’ – artifacts and steps

Too much ’stuff’

All these steps, all these artifacts – all this stuff. Add all these things to the chaos of every day – last-minute issues, being split across multiple tasks and projects, multiple bosses. Who has time to understand the ‘Spirit’ of the methodology – that which actually is needed to make it work?

Methodologists can look at the RUP, at anything Summit-D based, at PMBoK, at any other heavyweight methodology, and see how many of these methods may actually be customizable…How with some thought you actually might be able to run an Agile project using them! How they may in fact be iterative, despite the linear appearance of the diagrams…

Most people (myself included) are not methodologists. They are people trying to get projects done amidst a host of challenges and distractions. There is little time to invest in understanding how a holistic SD method works, how to customize it, how to somehow iterate on one dimension while performing linear phases on another! Though these things seems simple to methodologists…they are a layer of complexity that most of us on the ground can’t even begin to devote the mental cycles to.

Accountability for Product is Lost

On a project, I am no longer responsible for the finished product. I am responsible for an artifact, during a phase. When the phase is over, and my artifact is ‘done,’ my job is done, and the next step (and eventually, the product itself) becomes someone else’s problem. Successful product development now relies on assumptions like these:

• That my artifacts got the true user requirements right
• That I consumed the last artifacts and interpreted them correctly when creating my artifacts
• That everyone consuming my artifacts interprets properly when they create their artifacts
• That the final product, the result of all of these handoffs and interpretations and translations, is what the user truly requires
• That nothing changes

There are many challenges with these assumptions. If people are not responsible for the finished product, but rather for interim artifacts, is there something lost? Is their expertise available once they hand off their artifacts to others? I believe that something is inherently lost just by virtue of changing any person’s goal from the finished product to any interim artifact.

Agile

I believe that one of the most important unwritten benefits of Agile is that everyone on the team, as a team, is focused on the goal of the end product. Artifacts can be used as tools or as consumables in the achievement of the product. Everyone has the same goal. No one can say ‘it’s not my problem, I completed my artifact.’

‘Hybrid’ Methods

Some very talented methodologists, as the pendulum swings from pure prescriptive methods to pure adaptive methods towards more prescriptive again, propose ‘hybrid’ methods. Get the benefits of both! We can ‘balance agility and discipline’ (inappropriateness of those specific words when comparing Agile and traditional methods is a separate topic) We can benefit from agility while gaining the comfort of our artifacts…panacea. Hybrid methods look great on paper. In practice, I’ve not seen better results – once you start introducing the artifacts as ends themselves – the focus away from the product itself begins. The benefits of the Agile principles quickly fade away.

Consumables, not Deliverables

I like to treat artifacts as consumables or as tools – things that can be used up during the process of creating the end product. The better the quality of these consumables – the more ‘pure’ they are, and the less unnecessary stuff they contain – the easier they will be to process. Artifacts can also be tools (many examples of how can be found throughout the Agile world on the internet) – used as needed when they help teams produce great product.

Some examples:

1. The team doesn’t have the infrastructure it needs to be effective (perhaps no continuous integration, or the enterprise-approved toolset will take months to get set up/be available)
   • Passive Conduit:
     • Escalate the issue to program leadership and anyone who can solve the problem
   • Active Conduit:
     • Escalate the issue to program leadership and anyone who can solve the problem
     • Investigate possible short-term alternatives and get something running for the team (get an open source/free CI server installed and running on the dev servers, get team to implement its own CI)
     • Find people in other parts of the company or in the community that have solved this problem
     • Include team members with relevant skills in identifying/implementing a solution
     • Work with program leadership and support groups to help them understand the challenges and risks the team faces, and show them the measures you have taken for the short term
2. The team has been asked to wait for some major architectural or design effort that will influence upcoming work, lest they should waste effort!
   • Passive Conduit:
     • Escalate the block to program leadership (technical, business (through Product Owner), etc.) and set expectations about the impact of doing BRUF/BDUF/B*UF efforts
   • Active Conduit:
     • Escalate the block to program leadership (technical, business (through Product Owner), etc.) and set expectations about the impact of doing BRUF/BDUF/B*UF efforts
     • Spend time with the architecture and/or design groups in question. Provide training in Agile methods, and coach them in how to evolve overall architecture and design while making actual progress. Facilitate the creation of stories that can be implemented based on what is already known in such a way that changes can be easily incorporated later. Include team members in coming up with such solutions

The Passive Conduit focuses on escalation and communication of the issue — The Active Conduit also communicates and esclatates, but goes further to focus on facilitating and driving the resolution when appropriate.

Does your team have issues? Who knows about them? What have you done to help solve them?

“It is only after we’ve lost everything that we’re free to do anything” – Tyler Durden

This statement (from a popular movie, Fight Club, of all places) has been incredibly valuable in my transition to (and growth as) an Agile project manager, scrum master, and coach over the years.

Successfully moving to Agile is very much about abandoning rules and practices that were made to deal with limitations of the past. In the past, as a project manager on traditional projects, in addition to “management” activities, I had to make decisions- sometimes about technology, or product, or schedule, or other. The burden placed on project managers in many large organizations is tremendous. Ironic that the project manager is often the person in the worst position to make these decisions – usually without reporting authority of her/his teams, without the most domain expertise (when compared to business sponsors, for example) or technical expertise, etc.

Having all this responsibility and accountability made the traditional project manager a very powerful person.

It is difficult to willingly give up power.

“One of the most common and serious mistakes that you can make as a project manager is to compensate for an inadequate sponsor role by making major project decisions such as scope, objectives, risk management, quality expectations, benefits realization plans, and so on by yourself…Simply put, you are the “passive” conduit through which the dreams of the sponsor flow.” – Rob Thomsett, Radical Project Management

Throw it all away and be free

I believe that one of the simplest and most effective things an Agile project manager can do is, ironically, nothing!

Well, not really nothing. But none of the things mentioned above. The Agile PM should be a conduit of information, a “passive conduit” as Thomsett describes nicely in his excellent book. Instead of solving problems, focus on getting problems to the right people. For every challenge, risk and issue arises, spend your time communicating to those who need to know, those who are empowered and able to solve the challenge or issue, or who are affected by the risk.

If every single challenge is moved, through you — suddenly seemingly-powerless PM — to the right people, they will all be handled most effectively, and/or decisions will be made with the best possible information. Almost magically, your project will become far more successful, without you solving a single problem, and without you making a single decision! Your decision not to decide (and to instead facilitate decisions) has resulted in project success. How do you define power? My definition has changed over time.

Handling anything – the same method

Suddenly every issue, risk challenge becomes the same. Project management, something I previously thought incredibly complex and requiring atlas-like efforts of driving people in a direction as well as scrutinizing detail, has instead become a series of appropriate reactions to any change, servitude of the team in its efforts to accomplish its objectives, and (process and other) guidance for those needing help dealing with particular situations. The effect on the organization can be profound- those truly accountable and empowered to deal with things get more experience doing so.

Mind Like Water – a nice description of a way to approach dealing with change and problems