Within the large organization, I can appreciate the desire. Indeed, there certainly are some benefits around transparency, consistency and institutional knowledge to be had when we get everyone to agree to a standard. This is a careful balancing act, as the benefits may prove elusive and the risk is very real. First with transparency, while working code is the best indicator of progress, as teams grow into the hundreds, that can become too much “product” for an executive to effectively review and understand. This closely dovetails with consistency, where teams need to have common understandings of how to exchange stories, what “done” really means, and even what technical standards they will follow.

Technical standards can be quite pernicious, as enterprise licensing agreements, technology stacks and other architectural decisions can place very real requirements on how teams operate. We do like to think of each team as a trailblazer, but at some point, if you have three web development teams, one chooses ASP.NET, one chooses Java and the third chooses PHP, it doesn’t take an expert to see there is wasted energy. Lastly we come to the idea of institutional knowledge. As a consultant I can certainly appreciate that companies have a desire to “do it on their own” and apply hard earned lessons in one project to future ones.

It is not that these are invalid desires or that some benefit can’t be reached from standardizing, or as I’ve been calling it “institutionalizing” a Scrum implementation. Rather, it’sthat we need to understand the cost of each decision we make and weight it against the benefit. I think back to one of my earliest experiences in project management. An aspiring PMP, I was kicking off a project and I took out my PMBOK to find out what tools I could use to charter and initiate a project. From analyzing stakeholders to managing risk, I’m pretty sure if there was a checklist or template, I used it. At the time I didn’t understand exactly how each one applied, so I compensated by using every single one. Surely, this is not Agile, nor how one would advocate something like the PMBOK be used. I took a list of possible tools and considered them a mandatory set of things to do. Just like that, a supporting resource became a requirement and my project was about following lists rather than delivering value.

I see a similar challenge if an organization begins to offer too many guidelines. So what is the right limit for acceptance criteria in a story? Well, in my case, I took a 3×5 note card and figured out how many sentences I could fit on one side. This brought me to the recommendation of 7, but does it mean if I only have 2 that my story is wrong? Of course not. A better measure would if it clearly articulates what the story needs to do, is agreed upon by the team and they can commit to do it in a sprint. Then again, even user stories are not explicitly part of Scrum, so are we now mandating that all project requirements be formatted in this construct? Just because something makes sense in one domain, doesn’t mean it should be applied elsewhere.

Indeed, using a framework for empirical feedback like Scrum provides one with infinite ability to inspect & adapt. Of course, a common challenge with standardization is that, we have two groups of people: one group who is defining the standard and a second group who is trying to use it. Thus we have one group using the process and getting feedback, but a different team is supposed to make adaptations to the process, but is not experiencing that feedback directly. This is the paradox I alluded to before. In order to get a large organization to use a highly flexible & adaptive process, we must take away some of that flexibility by taking decisions out of the hands of individual teams and delegating them to centralized committees. When this is done, does the value proposition remain intact? How do we go about confronting making consistent & transparent Scrum throughout a very large organization without fundamentally undermining the nature of this framework?

I know many people have talked about this topic and I will certainly have more to say about it, but for now I think the key is to figure out how to standardize on the principles and keep maximum flexibility, but I can see this blog post is already too long so let me leave it with that until I continue this thought later. I’d love to hear your thoughts in the meantime.

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.

When you live where we do, working with huge organizations spending enormous sums of money so that hundreds and even thousands of people can build, support, train, maintain, and even (gasp) plan how to handle the information needs of millions of people as they; trade at a local, regional, national, and international level concurrently; seek, provide, research, pay for healthcare;  protect/defend their person, family, home, community, nation, world from threats of others or their own environmental actions; and even download upload whatever they find entertaining in this world; when you live on this side of hill, architecture is at the core of being Agile.  And for the most part, we suck at making it great.  Why is that?

Perhaps it has something to do with what architects hear us say and what they take away with them.  I recently read a great blog Lean & Agile: Are they worth the effort? and made these comments.

It is startling to read such a well read and concise synopsis of what many of my colleagues in the Agile community get wrong in communicating what Agile is.
First Agile is more than just delivering the most valuable parts of what the customer wants.  The bit missing is the important one. – it works as near to perfectly as the team can make it.  Why do I harp (some say nag) on this.  Well, if the most valuable item the product owner has cannot be delivered, say for example a startrek replicator machine capable of making $1,000.00 bills in endless supply.  Then we cannot deliver it.  Sorry, not going to happen.  What else do you want?
So what is Agile, it is a way to deliver the most viable value at any given time and in saying this we begin talking about iterative development where we allow for the rapid delivery of emerging solutions.  You know the ones that are not quite right each time the product people look at them – the ones needing ‘one more thing’.  Agile is great because it delivers what was wanted in a short period of time and then ‘adapts and inspects’ to create the next version of “AH HA’s” the product people come up with.  Great stuff.
Agile also does incremental well.  That is the one that you do when the product is nailed down and you know what the end looks like for the most part.  now we can deeply dive in to what and how we repeatedly create the same product or process.

This does sound like lean but as you so quickly caught on, lean as in manfacturing is not what we do in software.  We do not build the same exact source code and ship it over and over again.  We have that bit down in release.  What the Leanies are talking about is ‘lean principles’ which IMO are basic good engineering practices that aided the allies in winning world war II.  Check out TWI and see what I am talking about.  TWI or Job Instruction Trainng is how to teach unskilled people processes that will permit them to produce highly technical product in a very short time.  If more of the Leanies had time in manufacturing line management they would know this. but that trade and proffession, like phrenology, is a thing of the past.

So what does Agile need to adapt and inspect on?

First and foremost we have not allowed architecture to emerge as a valued member of the Agile team.  There are probably a host of really good rationales for this and I am pretty certain that a therapist would have a field day with all the angst, anger, and other inhibiting behaviors that fostered this feeling and continue to fuel the issues.  Folks it is time to get pragmatic and move on.

There is one reason that I have found that makes this impossible and that is the how today’s Agile Architect defines themselves through their work patterns with each other and with Agile teams.

Agile is a team sport and we treat architects in general and Agile Architects in particular as individual contributors that sit on the periphery of the Agile Team.  Shame on us for being that conventional in our thinking.  Shame on Agile architects for not moving hard enough to show the lack of relevance that attitude has when integrating Agile into large projects and programs.  that word is something we need to use around architecture for a couple of good reasons.  The most important is that it really works well when it is done and it also really changes Agile biases because it rocks the boat into hyper gear.

In fact, this is probably the insidious challenge with things like RUP or PMBOK, which advocate selectively choosing the tools and artifacts you need for a specific project. While people are free to opt to exclude certain deliverables, in an unhealthy organization, one does so at their own peril. Any gap or inconsistency is likely to be pointed out in a postmortem as the ultimate mistake that doomed a project. Scope had to change? Clearly you should have done both a business requirements and then a system requirements document. Project schedule slipped because too many bugs were found late in the game? Looks like you really should have made a formal QA strategy document and a full traceability matrix mapping your requirements to test cases.

Ironically, this very dynamic can play against Agile. I was facilitating a discussion about Agile and one of the participants earnestly explained to me that they needed to write detailed technical specifications because so much of their work was sent offshore to the lowest bidder, where turnover was so rampant they were working with different people every 3 months. The idea that they should improve their off shoring strategy did not seem to be worth considering. I wish the team luck, but I wouldn’t be surprised if several months from now, they found themselves looking over a steaming pile of project wreckage and saying, “well, that’s why we shouldn’t use Agile and need to put together detailed specifications before we ever start coding!”

This draw is particularly relevant to me, as I would identify myself as a reformed process-aholic. When I was a newly minted PMP in my first project management role, there wasn’t an optional template, process or document that I avoided. Project charters, team orientation manuals, risk spreadsheets, progress dashboards, business requirements, testing strategy documents, data dictionaries, you name it my project had it. Nobody would say that I wasn’t managing my project well or that I was neglecting something. Of course it means that I authored a lot of documentation nobody read, and it wasn’t clear what the team had truly agreed on – were testing guidelines in the unit test strategy, the project plan, or the system test strategy – and incidentally I was so busy filling out documents that I wasn’t really around to help the project team. I do seem to recall complaining that nobody followed the beautiful plans I had put together. What I didn’t appreciate is the idea that everything you do in a project has a cost. Now many things don’t cost much, and are well worth the investment, but process isn’t free. Every minute we spend documenting something is a minute not spent collaborating. While documents are useful for historical context, they can also become inaccurate over time, or continue to cost more if they must perpetually be maintained. What is the cost of the fact that now, when people have a question, they go to the document instead of asking the subject matter expert, who would be able to explain much faster and effectively?

Interestingly enough, it seems many people, especially in large bureaucratic organizations realize that is these unwieldy processes that can ultimately consume so much time and energy they are effectively undermining the project. Perhaps its human nature that those of us closest to managing a process are at risk of becoming consumed by it and perceiving all problems as challenges to be solved with more process.

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.

The authors first introduced the topic with a simple economic study, the impact the changing price of eggs had on sales. The researchers found that consumers were more sensitive to prices increasing than decreasing. The impact of a loss – in this case due to price increases – was 2.5 times more profound than the impact of a gain (Putler, 1992) . Quite simply, people do not rationally weight losses properly and as such this leads to irrational behavior.

This concept was then applied to numerous examples such as one of KLM’s premier captains flying his 747 down a foggy runway into another plane because he was facing a flight delay and didn’t yet have tower clearance or a financial adviser explaining how many of his clients are unwilling to sell a poor performing stocks once it is below the price they bought it at, even if the most likely outcome is that the given stock will continue to drop (Brafman, 2008). Individuals fear of REALIZING a loss that has already occurred causes them to take on additional risks that are not rational. Perhaps the best, example offered was the $20 bill auction conducted by professor Bazerman at Harvard. At the beginning of each semester he offers an auction for a $20 bill starting at $1. There is a twist; the 2nd highest bidder must honor their bid, but gets nothing. As the price moves closer to $20, two bidders will become locked into a bidding war as each person hopes to outbid the other, thereby avoiding the $20 loss. Professor Bazerman has indicated that the bidding has gone as high as $204. This idea of risking more to make up a loss is not uncommon. In your own life, think of the last time you were driving somewhere and were running late. Did you drive faster or more aggressively than you would normally?

While the authors did not explicitly apply this dynamic to large projects, I can certainly see how this dysfunction has played out in projects I’ve been on. In fact, it seems the nature of a traditional waterfall project would be quite prone to this irrational loss aversion. Imagine for a moment a project broken evenly into three major toll gates for requirements/design, construction and testing. Now imagine for a moment that the first face is coming to a conclusion, but the design is not quite nailed down, or an extra week is required. Traditional project management would say that one would communicate the schedule slippage and move the date out. My own real-life experience has been that people will say, “we’ll just make up the time!”

One of my friends in QA has frequently pointed out that the nature of his job as a QA professional means that he’s “the last one to go and the first one to be cut” implying that that traditional projects generally run longer through their earlier phases, in turn placing extreme pressure on QA to make an original date. I would like to say that when I used to work on waterfall projects I was strong enough to resist this dynamic, but sadly I was not. On several occasions, the siren call of “making the date” lured me too close to the treacherous rocks that have shipwrecked many vessels.

Somewhere deep in our psyche is a fear of loss, and with the modern large-scale waterfall development projects we have put together a system for delivering projects that basically plays to this fear. Is it any wonder we see massive projects go way over budget and yet continue to go forward? Like the ambitious MBA student looking to avoid the $20 loss, there are too many examples of companies throwing good money after bad to avoid ending what has already become a disastrous project. One client I recently worked with had just concluded a massive, two and a half year project only to realize that the cost to maintain this newly developed product was so high it could never be sold at a profitable margin.

The iterative nature and value of frequently delivering production ready code certainly help to mitigate this dynamic in an Agile environment, but I would not pretend that the same pressures don’t exist. I know I have seen business executives simply assert, “we must get everything done by this date”, expecting the team to find a way. Just because one works in an iterative way, doesn’t mean we are really open to evaluating our progress and make adjustments. From a project management point of view, we can refer to the triple constraint and inquire what is the lowest priority: cost, schedule or scope? In the unfortunate case where project sponsors are not willing to entertain such a trade off, then one must move to a discussion about risk – or reduced quality – and how much the program is willing to take. The best course of action is to surface these subconcious tensions that may be playing out. While we may not want to be the bearers of bad news, it is far better to escalate an issue when people still have options than when it is too late to do anything. Also, if we accept people are inherintly adverse to realizing a loss, the team may be much more willing to walk away from a small train wreck of a project, rather than a larger one they would be even more invested in. Unfortunately my experience has shown that the most likely, and worst, possible option is to shoulder the risk oneself and subscribe to the fallacy that it is our job as project managers to manage risks like this. Of course, now the stakes become higher as we continue to bid more and more for that $20 bill.

(How many times have we all seen this or experienced this situation?)

Agile allows everyone to win.

John the CIO thought everything was running smoothly, not perfectly but customers had stopped complaining and products were shipping on time for once. Re-org after re-org had finally brought some results. The developers/testers/project managers and business analysts were happy, or so he was told by the V.P. of Development to whom all departments reported. Everyone was solving problems and working together in the open and bright space. Disciplined process and structure were in place and demonstrated during executive and shareholder meetings using sharp power point presentations. Documentation, process and procedures were stored in shared repositories for all to see. More eloquent documentation you could not find.

Everyone agreed improvements needed to continue but the executive management team was elated.

While it was true, products were shipping, what he didn’t know is that people were working in excess of 50 hours per week and more. They were now working nights, weekends and sometimes over night. He heard about the video games, pizza and food being brought in so he assumed, everyone was being taken care of. What he didn’t know…Changes were made hours sometimes minutes before going to production completely bypassing the QA team and being looked over by the B/A’s or sometimes just the developer. Negotiations with clients were made on features so what he thought was being delivered months earlier according to a ppt presentation really wasn’t but the VP had already smoothed that out with the client. To those above, it “appeared” that the team shipped all features, defect free, on time but what the teams knew, particularly those closest to the code and deployments, is that they shipped some of the features, not well tested, and held their breath followed by other negotiated smaller production deployments all without the CIO’s knowledge! Everyone knew what was going except for management that was carefully “managed” out of the information loop.

While people on the teams knew what was happening, bringing it up to the PM’s or VP singled them out as non-team players and before they even knew what had happened, they were removed from the teams. Eventually, everyone stopped talking and trying to make things better. It was easier and less risky to simply comply and stop pointing out the obvious flaws and potential serious harm this vicious circle was causing. The risks the company was taking without knowing it as well as the clients. Employees observing this were losing respect for management and the prospect that things would get better. There was a growing concern that it was important to keep up the illusion of success. Technical debt was building and building to an untenable point until products completely failed to be deployable without multiple code patches and increased  manual testing cycles. Eventually it was not possible to hide the crumbling product infrastructure.  Regardless of how hard people worked, how fast the coding went or how much the testers tested, the product could not be  stabilized and it was not scalable . Nobody wanted to hear, we told you this would happen a year ago or even last month. The CIO stood up and took notice but wanted action, not excuses. Again people rushed to FIX IT instead of stopping to figure out, what caused this problem and again, went into the immediate hectic circle of HURRY, WE HAVE A PROBLEM, FIX IT, TEST IT, SHIP IT, HURRY, FASTER, FASTER, And FASTER.

Oh problems were identified; you know the story, the usual ones.

· The project managers, were not quite right for the team but instead of removing them, we’ll just add more

· Testing is too slow and it’s all manual

· We need to split development into maintenance and new development

· We need more people in general, that’s it, we’ll put a few senior people on the project and several really expensive consultants, they’ll fix it right up and kick everyone back into shape.

· Oh it’s just the testing teams fault anyway, lets fix the testing process by designing process flow diagrams and making lots of templates. They are supposed to assure quality right?

Needless to say, nothing changed. But the CIO thought it was all fixed up because the product started shipping again. Hmmm.

The team became fragmented and completely demoralized having been told everything was better. Nothing changed. The patterns of behavior that caused the problems simply repeated but the appearance was that the product was “stable”.

To the teams, nothing changed except they now had to report status to more people and defend their efforts instead of improving the process. Because the teams were split into maintenance and new features, they now had less people doing more work and the code defects increased thus increasing testing time.

People started to leave. Those who stayed dragged themselves in. The team had no spark and no reason to go above and beyond.

What agile could have done for this team?

Rule 1. Agile really does require top down support. Whether it’s the CIO or the SVP, it requires the most senior sponsor to support it completely.

Rule 2. Agile is transparent and as we all know, you have to face the ugly and deal with it, as Brian wrote, Step 1, Accept that you have a problem and be ready to deal with it, not cover it up or call it something else or “redefine success”.

Rule 3. Do not lie to upper management. You are not helping your CIO you are hurting your CIO and everyone else around you as well as destroying your credibility. Once people lose respect for you, it’s unlikely you’ll ever win it back.

Rule 4. People write software, test software, and organize plans. People are not resources, fte’s and contractors. Treat them like the people you thought you hired. They have brains, let them use them. Expect them to be brilliant and let them surprise you.

Rule 5. Stand up and say no. Not now, next iteration. Or, choose this OR that.

And many other basic concepts that Agile principals bring to the table.

People say Agile isn’t for everyone. But I wonder about that. Agile principal concepts are common sense principals that benefit everyone and every organization at every level. The fundamental guidelines bring out the very best and yes, not so great but gives everyone a chance to adjust. You find out quickly if you are doing the job you love or not. You’ll probably find that you’ll love your job more. Imagine bouncing into work pretty much every day so happy just to be there, with people you really like working with. Every day, just imagine…

And how much happier your clients would be and how much more productive the department would be.

And for executive management – imagine if you would, increasing your profits while driving down expense instead of spending more money to make money. Or instead of laying off people during a down economy keeping them.

Today, those few nuggets of value have been tweaked, twittered, extrapolated and inflated to the point that almost any tool, software add on, metric that can be conjured is associated to all of the following slides.

• Agile Priniciples
• Agile Manifesto
• Jim Johnson’s 2002 xp presentation
• Anyone of a number of Scrum graphics
• Scott Amblers data

And presto we have a new something or other.

I go back to Jim Highsmith’s comment regarding that there is more written about Agile than is known.

Right On Dude!

I guess that makes the people I work with on the outside, Everything we talk about is based on what we have experienced leading, coaching, and training. We know it works and we know how many errors we made finding this out.

AH, INSIGHT!

Perhaps there is a way to find out how much of the PowerPoint has Power by asking the presenter, how many mistakes it took to stumble across the gem they are offering. Hmm let’s see,  I can read about Mike Cohn’s stumbling into planning poker and points, just like I can listen to Ken Schwaber tell me about all the things he has done that did not work. If you want a good laugh, ask Jeff Sutherland or Ron Jeffries what surprises they have had. Dave Anderson still moans about all the things he would change in his book that he knows are wrong. Sanjiv Augustine too. I could go on and on with the people I know who have told me, written about it, but then I know I would forget someone like Jean Tabaka or Hubert Smits and I wouldn’t want to do that. SO all I can do is tell you what I remember.  Now wouldn’t it be nice if we had some record of all of our screw-ups?

Me? Hey…My most recent learnings are about how QA and Architecture teams impact large projects.  Most important finding is understanding how to get them acting like teams and not support staff.  Second most important finding is getting the rest of the teams to see their value early.  The mistake that led me to these learnings was assuming that Architects, QA and their management wanted them to act like teams after they said they did.  Key lesson learned.  Count the number of steps taken, not the words spoken.  Then again this may be why the straw really broke.

So where is the beef in all these presentations? Maybe we ought start asking.

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.