Project Retrospective - SOCCER format

Recently I conducted a project retrospective with a set of focus areas, which I abbreviated as SOCCER:

  • Storytime
  • Opportunities
  • Culture
  • Confusion
  • Emergency (ER)

The idea was to allow the team to focus on its strengths, gradually move to stuff that needed improvement, and close with identifying items that should be fixed right away.


After spending about an hour with the team building the project timeline, we summarized the project in about 10 mins. The team then dealt with each of the SOCCER categories one at a time for about a half hour each. To help generate ideas and conversation, I created a few sample statements/questions for each of the SOCCER items as under. Then the SOCCER categories were dealt in the following order.


"When I tell a story about this project, I'll always remember …."


"I was productive and in flow when …"
"I would like to be included in …. "
"I think we should …."
"Why don't we …"


"This confused me …."
"I am still confused about …."
"Why did I/we do that …."


"I was disappointed by …."
"We cheated when/because …."
"I lied or misinformed because …."
"I should have, but I didn't …."


"I found this meeting wasteful …."
"In my role I struggled because …."
"Nobody seems to care about fixing …."
"I doubt that the leadership knows about …."
"I wish my leadership supported me in …."

As feedback the team suggested that I can improve the quality of questions. E.g. In the Culture my questions seem to seek only things that should be improved and not the things that are brilliant.

Verb to Noun

I mostly visualize concepts in pictures. Just as the lens in human eye inverts an image upside down, quite often this is also a reality in organizational change management. Agile adoption is a case in example. Executives want the organization to be agile (verb). Between several layers of hierarchy the vision is inverted to Agile (noun). Instead of being nimble, middle management incorporates bloat (heavy processes, templates, audits, and assessments). It is not a surprise then how many such initiatives fail to demonstrate any significant improvements. Even more painful is to see teams getting robbed of a chance to understand and experience what it really means to be agile (verb) and nimble. Rather, edicts that create more problems than it solves are abundant. Take for example the notion of less documentation. On several occasions I encounter teams that don't get what it means. Either someone is getting by without putting pen to paper (no user stories, on the fly analysis), or somebody is having to document eternal change (software design documents). I have found only one way to solve this problem. Abandon the noun approach, and adopt the verb approach. Understand the purpose of documentation and then follow some simple rules such as:
  • Document only when you can identify a consumer for the information and (s)he indicates that (s)he needs it.
  • Attempt to offload documentation to its consumer. Usually, it minimizes the need for it.
  • Maintain one and only one source for each kind of information. 
  • Make the source of information more accessible rather than create yet another incarnation.
  • In future try to do better, unless the situations warrants otherwise.
This is what being agile (verb) means. On the contrary, doing Agile (noun), would create a suboptimal ecosystem where somebody is working more than (s)he should, while the other person is not still getting what (s)he needs. And, a litmus test is when you get asked, "What is Agile's take on documentation?"

[Image taken from:]

Entrapments of Idealism

Have you heard of things such as "zero defect policy" and "100% unit test coverage"? Or things such as codification of every step of the process; I'm sure you have been presented copious flow charts and documents that state the obvious. Take for example a group that I was engaged with. In their Definition of Done for a user story, which was about ten bullet list long, one item is 'Code Complete and Compiling'. I call this situation the entrapment of the ideals. These idealisms are taking joy out of work. Not that they are incorrect. It is that they generate emotions, which sooner or later breed cynicism, kill improvisation, and create bogus work that is sometimes euphemistically knows as diminishing return. Environments that don't take corrective action to curb such tendencies create a culture of pluralistic ignorance. Individuals are aware of these absurdities but stay silent to avoid being tattooed as bigots. The operating delusion is that this idealism is helpful in strengthening the capabilities of an organization. 

In the bunch of things I'd like to mix in a workplace stew, pragmatism would be my number one choice.

[Image taken from:]

My Interpretation of Agile Practices and Artefacts

Some of you who have heard my opinions on Agile practices, artefacts, and mindset have asked for the slides. As much as I hesitate to share without being able to tell the story, I understand that you probably remember some of my views. With that caveat, here are the slides:

   Hello Agile    User Stories    Agile Estimation
   Release Planning

If you are unable to access these, please don't hesitate to drop me a comment. 

In the Crucible of Learning

In an Agile adoption program, who do you think is socially affected the most? I would say it is the Scrum Master. This role is exposed to the most variety of topics; areas as diverse as social, political, technical, product, tooling, and administrative. Using crucible as a metaphor, it is usually the Scrum Master who is to be found in it.

A well-executed adoption, usually, leads to a transformation. At least it becomes a poster child for the transformation that may follow. In rare cases where transformation has happened, there has been one more group in the crucible. It is the middle management. In one of my previous posts I mentioned how management tries to avoid pain of change programs like Agile adoption. 

The reason Scrum Masters and middle management gets dragged into the crucible is straightforward. For the Scrum Master it is the focus and scrutiny of the team(s). It requires an elevated level of maturity, self-awareness, self-confidence, and sense of security to be able to withstand constant scrutiny and absorb rapid feedback. In case of management, it is the pressure to placate and insulate the drivers of change (team) from the believers in status quo (upper management). Perhaps it is the pressure to deliver instantly on the investments in Agile. The notion that teams will pay an initial toll in velocity/throughput as they learn, implement, practice and relearn new concept is unacceptable to the senior management.

It is valuable to be aware of this dynamic. It helps you plan the learning cycles. But more interestingly it provides some litmus tests to see you if you have the right people as Scrum Masters and sponsors. If Scrum Masters can't adapt fast enough and managers avoid coaching, then the writing is on the wall.

Image taken from:

Got Strategy? Sense the Shift?

What services, products, and innovation do we need to sustain a business in the future? Usually, these kind questions are a bailiwick of Strategy within a corporate. What organization skills do we need to make Strategy relevant and effective in an organization? Ahem! Is the CSO around?

Avoid a Strategy of Imitation

Many organizations are knee-jerk reactionary. They sweep into action because a competitive situation has gained significant momentum. A good example would be the movement to have 'Social' presence. How you will monetize it, you don't know that yet. 'Big Data' is treading the same path. Beware!

Strategy is Social

Most workplaces have low tolerance for seemingly irrational thoughts. The reality of markets that these organizations play in, however, are indeterminate, delimited, and sometimes arbitrary. This juxtaposition is frightening. Those who are aware of it design organizations that are unconventional and innovative. A significant difference I have noticed in such organizations is that strategy is not confined to a department. That doesn't mean somebody doesn't have a title with "Strategy" in it. The point is that the energy, awareness, responsiveness, and the entrepreneurial spirit are at a much elevated level compared to the rest of the industry. Some refer to such organizations having a different DNA.

Choose the Contradictions

How is the blueprint of these organizations different?
  • Employees understand how the reality of the future will mutate much faster than today, and embrace it.
  • These folks think in terms of "what if" and "why not'.
  • The organization has built a tolerance for spending time in seemingly "wasteful" activities such as some-work-some-play, sustainable pace, innovation games inspired meetings, etc. 
It is surprising to me how many leaders are unable to take the very first steps to experiment with these contradictions. Of many a things hard to comprehend from the books, this one would make it to the top of my list, a sea change in thinking.

The more time I spend in consulting, the more I realize that Technology won't be a differentiator for the organizations in this decade, especially for large companies. The onus for success has rapidly shifted to Business and management style. In the complex relationship between the two, the ball is in Business' court.

[Image taken from:]

A Gift of Obamacare Rollout

Like many technologists, I too delivered my share of smirks and sarcasms at the failure of the website. As somebody who has experienced such service roll-outs first hand, it is unimaginable that a vendor would be so careless/reckless with an initiative as significant. How could that have happened? In this day and age when software can land a rover on Mars, a website buckling under its design load should outcast every technology "expert" involved. This poor design should have been disclosed earlier in the website's existence. As comical and theatrical as the senate hearings on the subject were, there's an element of sincerity in them. I wouldn't have reacted too different from how the lawmakers did.

In all of this mess, there is a silver lining. In the last two or maybe even three decades this has probably been the only time when Capitol Hill has summoned, on it's floor, a hi-tech company and reprimanded it. This was a much needed course correction. I think, it will improve the quality of solutions built for the government of United States, albeit at the cost of cost. History will remember this fiasco as the turning point for quality of government IT services. Not a bad bargain for $400 million, if you ask me.

Image taken from:

Drill Sergeant in Corporate America

If we had drill sergeants in some of large corporations, here's what, I believe, their admonition will be:

You're doomed and here's why.
  1. You are aware of the People, Process, Technology trifecta. Why don't you have a people development backlog?
  2. You're thinking of scaling Agile when you should be focused on scaling creativity. 
  3. You seem clueless when I tell you that your business is about to go bust in the next decade.
  4. Your customer is looking for a product and you can't seem to get out of your collegiate departmentalized organization model; quality assurance, development, and business analysis. Your mobile organization still thinks in terms of devices - Android, iPhone, etc.
  5. You don't consider your IT to be a partner in managing the P&L. But you expect the 'ITcians' to be a better custodians of your dollars and understand value.
  6. You seem to believe that you have learned all you could. Your daily schedule has put you in a place where you have ceased to learn. No wonder you choose command over conversation.
  7. You're biased for conventional success. So are your managers. 
  8. Speaking of managers, that individual is exploiting your being. (S)he is not interested in what you want to become.
  9. Your boss got you an Agile trainer. But you didn't suggest that your boss get an executive coach. You didn't, right? So you don't even provide feedback. Guess what you aren't getting from your team. 

One more thing - pull down those credentials from your office walls. That's a good School of Business but you didn't register for the right classes. So, next time you see your friends and family, tell them you're doomed. And now you can get back to placating your nemesis and pleasing your bosses.

Is your Mechanic ASE or I-CAR?

You don't know, do you? It, probably, doesn't determine your choice of a mechanic.

That's an important commonality between you and the Ozone (CxO) at corporate, when it comes to decision making. They don't care if you use Agile or Waterfall in your shop, just as you don't about your mechanic's choice of methodology. It is important to be at peace with this reality. I recently participated in a LinkedIn discussion, where quite a lot of folks clearly didn't understand this mindset of executive management.

Ozone is primarily occupied trying to figure out how their organizations can:
  • Deliver more,
  • React and respond to markets better, and
  • Build a competitive advantage.
Quit selling Agile and start solving their problems.

[Image taken from: ]

Political Infrastructure of Change

Leaders and managers involved in change programs cherish the notion that merits of their new vision will speak for itself. More often than not, change requires more than just its merits. Neither the effectiveness of technology nor the promise of its empowerment guarantees success. Matter of fact is that cognition of merit, like experiences and learning, is subjective. ( Rob Legato discusses how he experienced it while recreating the Saturn V launch sequence for 'Apollo-13'. ) No wonder sometimes others don't agree with our insights. We expect truth and facts to prevail, but the triumph of insanity and imprudence is a story repeatedly told. Moments like these are frustrating. An eerily familiar comment sighed, "It's politics." I believe that political infrastructure should get as much of a leader's attention as technical. Given the lack of exposure to it, I'd even go as far as to say that development of the following capabilities should take precedence for a leader:

  • Politicking. Political and organizational talent is a must to successfully implement change. We, usually, learn skills and trades like software technology and operations management. Seldom do we learn about politicking. Concepts such as trust, hope, suspicion, and despair aren't in any high school curriculum, as far as I know. Let alone illusion, delusion, disillusion, and wisdom. Interpretation of optimism, content, and pessimism is another area of deficit commonly observed in executives. In my experience of working with some effective leaders, I have clearly noticed the link between their sharp politicking abilities and an awareness of the concepts mentioned above.
  • Story Telling. The art of story telling is widely admired in leaders. A lack of it is often the first thing people point out when they talk about lack of leadership. Steven Denning has written extensively about it in his book The Art of Radical Management. Stories that promote optimism, a desire for drive, add context and perspective to situations, define reality, tell the truth and, paint a future are the grease of a  good enterprise. Story telling is key to building the flexibility for change in an organization.
  • Reasoning. This one is the most surprising of the three. Not because of the lack of it, but because of lack of time for it. Reasoning to build right mental models is an imperative. These mental models serve as memes, which fuel the engine of change. An example of lack of a weak mental model would be confusing unity with uniformity. It is a common trap most change managers fall into. Subconscious expectations include, amongst many, a desire for uniform application of vision across the board. That often rubs the 'subjects' of the change the wrong way. It appears to insult the intelligence and curtail freedom at work. There's not much freedom left in a modern large organization. It seems to me that most change agents end up fighting over uniformity when they should be focused on building a unity for their vision. This is an example of a poor mental model that leads to a wasted opportunity. So, take time to think yourself and promote reasoning in your staff. Mental Models are the equivalent of genes in an organization. Spread good ones around.

[Image taken from:]

Psychology of Pseudo-Agile

At every encounter with a struggling and sullied Agile stroll, I have seen a group of managers trying to look good. Their troubles began with the rising social pressure of adopting Agile. Or, an edict from top management. Around them Agile exists in name only. The obvious dis-ingenuity raises a question, "What drives the improvident behavior?" In the composite of emotions, the following stand out:
  • Fear and stigma. Accepting and tolerating failures is not everybody's disposition. With failure comes stigma. Agile doesn't bear fruits day one or even in the first attempt. Combine the two, and avoiding (a change to) Agile makes sense. Rest is self-explanatory.
  • Pain avoidance. Middle management is often the point of friction within an enterprise. It's the layer that tries to insulate the drivers of change from the believers in status quo. It is emotionally painful. Remember, change provokes sensations of physiological discomfort?
  • Strong Beliefs. Humans have strong beliefs. We also have information. However, we an uncanny ability to pick beliefs over information.
These emotions lead to an environment of:
  • Defensiveness. A reluctant and half-hearted pursuit of Agility usually draws a ton of criticism. It's just how humans behave, specially as a change seeking mob (software development teams). This puts the managers on the defensive. Ironically, defensiveness is recursive. 
  • Distortion - Often the tactics managers employ to keep the opposing interests of their teams and their bosses under control.
  • Cognitive Dissonance and Bigotry - Distortion slowly widens the gap between the beliefs, messaging, and actions within the management circles.
  • Herding - Negative outcomes of cognitive dissonance eventually lead to embarrassing state of affairs. Denial prevails and the brave choose to coverup. Risks are hedged and the "like-minded" coalesce. Panic breeds packs.
  • Political Jostling - Groups start to joust, which then inflicts its punitive tax on Agile adoption. 

Final Thought

Any large group of people (organization) is fraught with political challenges. A lot of us disapprove of the politics; some shy away, others dismiss it. Meanwhile politics doesn't stop its play. It frustrates even the best of us. What if we dealt with politics like any other problem? Could it be that politics is a veneer of some underlying and innate fears? That would change your perspective, wouldn't it?

Image taken from:

Agile and Beyond 2012

Agile and Beyond 2012 was a sold out event with about 650 attendees. Great Keynote by Steve Denning.My session on 'Agile Pathologies: Backyards of Agile Shops' was well received. The slides are available on Slideshare here or you can see it embedded below.

I was surprised to see the vibrant Agile community in Detroit. Had no idea, it is so big. Thanks to the organizers for a fabulous event. Well done!

Practices or Mindset: An Observation for Agile Adopters

"These practices are not suitable for our environment". "Let's shoot for as well formed backlog as we can". The difference between the two individuals is that the former is thinking of practices and the latter has the mindset.

What's the big deal, you ask? The subtle difference results in an order of magnitude difference in morale during execution. Your metrics, very likely, are a reflection of this nuance. And, in case you have ever wondered, these metrics then become the perfect medium of spreading the culture around; both good and bad. The "practices" crowd also worries about if they are executing as per the "textbook" or not. The differences are analogous to 'one size fits all' versus 'one size fits none'. Dogma and pragmatism are the other polar pair that come to my mind.

I intend to keep a log of how the practice-mindset subtlety manifests. Expect an update coming. Please don't confuse this topic with my earlier blog on Lean and Agile.

[Image taken from:]

Signatures of Distrust in Agile Teams

Trust is one of the key attributes of any successful agile team. Its lack hurts the velocity and increases the stress level in members. This, in most cases, is unsustainable. I would recommend a thesis titled, 'The role of trust in strategic alliances' (Michaela Weinhofer, June 2007. Baltic Business School, University of Kalmar, Sweden). Two simple definitions of trust from the references in the thesis are:
  • Combination of credibility, predictability, and straightforwardness, and
  • Decision to rely on another party under the condition of risk.
The cooperative relationship required to achieve a common goal can hardly ever be built with distrust. The reason I say "hardly" is because experts (referenced in the above thesis) think cooperation and trust are independent entities. The relationship may be cooperative but not productive. I would also highly recommend The SPEED of Trust: The one Thing That Changes Everything by Stephen M. R. Covey.

For an agile team, how will you know that you are in a distrustful relationship? Here are some symptoms:
  • Perpetually prioritizing new functionality over defect fixes.
  • Continuous scrutiny of velocity, deep interest in individual developer velocity, pressure to sign-up more points than velocity.
  • Questioning story estimates beyond a reasonable limit.
  • Avoiding story splits fearing 2 plus 2 won't add up to 4.
  • Comparing actual effort to estimated effort.
  • Key leadership (technical and non-technical) entrusted to non-team members
  • Attempt to pile-on stories mid iteration in the interest of getting more done.
There are many reasons contributing to above situations. It could be lack of awareness or lack of experience with Agile. But don't discount the possibility of distrust as a driver.

[ Image taken from: ]

Guilty of a Process Diagram - Don't be, just be Smart

"Let's not get this process too heavy", "We'd prefer lightweight over the traditional heavy". Everybody has got process diagrams, even in the Agile sphere. You don't believe me? Ask any Agile manager and you'll get at least two; a defect triage process diagram and an iteration lifecycle diagram.

Replacement for Common Sense
You probably have a process diagram that you loathe and scoff at. Usually processes are proposed and adopted to replace common sense and then, even worse, compliance is monitored. If you have to have them, processes should be guidelines to remind folks of the steps and sequences in case there are doubts. The idea should be to provide support to those who need guidance; beginners or occasional troubleshooters.

Analogous to an Elevator Pitch 
Based on observation (haven't come across a research on it), I have concluded that most people prefer simple processes but fall in the trap of creating complicated ones. That calls for a couple of rules of thumb:
  • Start so simple that you void the decision box. If you are using decision boxes, chances are you are in the realm of questioning people's common sense. 
  • Expand a process area only when team members are missing the boat. If team members repeatedly fail to execute a certain step, question its need first. 
In gist, a process diagram should be a very high level happy day path free of clutter designed to handle unhappy day scenarios. An analogy for a good process diagram is to an effective elevator pitch; crisp, clear, and simple.

It is important to understand the 'why', specially if you have to innovate. And if the 'why' is clear, there's no reason you'd ever stand complicated process diagrams.

[ Image taken from: ]

A Case for Enhancing the Agile Triangle

The Iron Triangle (Project Management Triangle) is an antithesis of Agile mindset. Jim Highsmith recognized it and proposed the Agile Triangle. It seems that the value vertex, releasable product, is still narrow in its focus. It is talking just about product/service value. It is restrictive to only customers and shareholders. How about Employee/Team Value? Or, even intermediary value focused on enhancing the core environment and sharpening the saws. For better software, we ought to think of empowerment, leadership and mentorship.

I want to make a slight modification to Jim’s triangle and add Intermediary/Internal value to the Value vertex. We just can’t ignore that anymore. That’s how continuous improvement happens. That’s when you take time out and act on retrospective tasks. That’s when functional product ownership balances itself out with technical product ownership.

An Agile approach to product delivery encompasses enabling the people and infrastructure. We just can't think at the project level anymore. We ought to start focusing on the whole organization. It is untenable to continue delivering external value without investing in internal value. The risk of not doing so is to put continuous improvement on the back burner.

A new normal, but a bad normal

In the last few years, I have been focusing on Agile Pathologies. My thesis is that as individuals we exhibit certain patterns of thinking, reacting, and politicking that usually impede Agile adoption. At times it is outright contrary to what Agility is all about. We can blame the tools, spaghetti code base, team distribution or whatever else you have, but Agile adoption is a people challenge.

A few in the industry discounted my views. Some examples:
  • "People behave in fairly predictable ways."
  • "That's within the realm of normal human response."
  • "80% of projects fail because of lack of attention upfront."
We are considered knowledge workers and supposedly can intelligently deep-dive to fix our problems. Under this misconception, we have built a culture of band-aiding the broken bones when it comes to people issues. This is the new normal, but it's a bad normal. 

With Agile manifesto, the software development community for the first time officially declared people to be more valuable. If we really believe that, we have to try hard to identify a pattern in people problems, and address their root causes. Or else the debate will not cease, “Is Agile the best way to write software, or is it the way best people choose to write software?”

Just as any good constitution or a body of law isn't of much consequence without understanding the basic principles and right execution, so is Agile. By execution, here, I mean responses to emerging problems and situations. Good Agile environments need relentless focus on improving people issues. More importantly, they require that we are hawk-eyed in spotting pathologies.

[Image taken from: ]

Speaking at Agile Development Practices East

On Thu, Nov 10, I will be in Orlando to share my views on some recurring anti-patterns I have encountered during Agile adoptions. If you are an Agile manager or sponsor, or want to be one, and have ever wondered if Agile is a fit for you or your organization, this session is meant for you. I will share some war stories and my secret sauce of success on ThoughtWorks' engagements.

I will delve into these pathologies at four levels; individual, team, management, and organization. We'll have a look at the 'Agile Iceberg' and try to define what an Agile Transformation means after evaluating notions such as 'Preconventional' and 'Postconventional' agility. 

As a speaker I get to share with you $200 discount. Just use the discount code, SPAS, to register. With an additional early bird discount of $200, this should save you $400 for conference registration.

Here are some links to the program: 

Agile Frontier: Where's Agile not Working Yet

"What kind of projects are suitable for Agile?"
"We've got to be careful in choosing projects that we want to be Agile."

At the onset I must make it clear that a big component of Agile is continuous improvement. That said, generally speaking improvement can usually be made most of the times; especially if Agile is not yet an established approach within an organization. The reason is simple, while most people focus on the structure of Agile and appreciate its aesthetics and lightweight nature, good Agilists focus more on its soffits; rigor, discipline, Socratic approach to problem solving, etc.

Relatively small and/or web-based projects have been experimenting with Agile for quite a while. The knowledge base in the Agile community on what works and what doesn't with such projects is rich. The landscape turns dismal on some other fronts, primarily due to lack of experimentation. In some instances a whole section of software community has been insulated from Agile. A prominent case study is Siebel (more on that in a later post). The idea in this post is to discuss some of the environments that are still a frontier for Agile. Without further adieu here's where Agile is struggling:

Big Opaque Software Frameworks:
Ownership, access, and control over the code being written is vital for software teams. If developers can't modify a code base to suit their needs and hook other 3rd party tools into it, they can't really derive a fundamentally sound and quality product out of it. Basic practices that contribute to stability and quality of software like Unit Testing are hampered due to inability to touch this code base and, again, lead to a poor quality product. Lack of unit testing in turn, usually, lowers the confidence level of developers who want to refactor the code. Thus they avoid it , which leads to inefficient designs.

Shared and Aggregated Environments:
Rolling software changes into environments and databases that affect organization wide operations are not too well suited for Agile development on their guts. Some changes are impossible to make and other very expensive. An example would be a common environment shared between inventory management, inventory ordering, and inventory finance and accounting systems. A spaghetti like this with myriad of inbuilt interdependencies usually warrants heavy frontloaded analysis. Regulatory oversight only makes the matter worse. e.g. a change made to an Oracle module once made might be difficult to roll back due to financial and regulatory restrictions. Often the Big Opaque Software Frameworks (above) almost mandate a heavy analysis and design phase. Big ERP and CRM applications fall into this category.

Software Hardware Boundary: This is the most exciting and promising challenge that Agile will have for a few years to come. Traditional heavy equipment and machinery manufacturers that utilize large scale control systems are getting comfortable with Agile in their software shops. Some of them are trying to take Agile out to their manufacturing plants and experimenting with how to make the mechanical design teams work with software design teams. Agile has not yet addressed the complementarity in software and hardware design. How can hardware design keep up with the software as it is evolving and vice versa? They inherently seem to have not just different characteristics of work cycles but also skill sets and personality traits in their ranks. Agile approach to software is largely unknown in the manufacturing world. It's a challenge of lag, lack of experience; hence the frontier.

Untamed Team Distribution:
Lack of interaction between software development teams and business stakeholders adversely impacts the feedback cycle and affects quality of the product. Development velocity takes a hit and ultimately feedback cycles lengthen to a point where rework increases and impacts velocity. Agile leaders in the industry have figured out approaches to make Agile work in distributed environments but only when the teams distributions are purposefully designed, i.e. they have the luxury to choose the people on the teams and their physical location or have a say on the rotation schedule of people between locations and teams. The persuasion to form teams with individuals that are dispersed between multiple locations across different timezones and are "staffed" on projects because they happen to be available might backfire and lead to woefully suboptimal value. Designing for Agility is a resource management challenge, and therefore a frontier.

Systematizing Agile: A natural propensity once Agile has delivered a few success stories is to systematize it in an organization. This urge for "systematization" is detrimental to Agile's success. Agile is not Coca Cola; each implementation is different and should be different to suite the needs of an individual project's needs. Systematization and templatization curbs the "inspect and adapt" nature of Agile. A challenge, therefore, emerges. How can Agile be institutionalized such that the necessary functions within corporate like budgeting and accounting can still run efficiently, smoothly, and cost effectively? How can financial planners ensure optimal use of available resources and timing of investments? This is not to say that in the traditional world financial planners are blessed to have projects executed as they had planned. Projects are extended, teams underdeliver, and expenses are all over the place. Not to mention that the OpEx CapEx ratios are much different than initially planned. The challenge therefore is to build accounting communication and data-churning tools that can react to the realities of projects on the ground. Agile, I think, catapults this necessity to forefront. However, Agilists haven't yet built the tools or reporting mechanism, to the best of my knowledge, that addresses these specific needs of financial planners.

Agile Scalability: 60-70% capitalization rates in software development industry are not unheard of. They are rare, though. On an average this rate is around 20%. Since software capitalization rate is far less (or even none due to short spans between technical feasibility and actual development) in Agile it essentially becomes unattractive for corporation to even think of agile transformation across the portfolio without getting creative and aggressive about it. That's a risk, I don't think anybody is willing to take. The outdated (in context of Agile software development) FASB edicts pose a huge barrier to scaling Agility in large software development environments.

Talent: With the growing adoption of Agile comes a sad realization. It's still the people that make the difference, as they always have. A common misunderstanding in the community is that it's the lightweight process and use of innovative tools and techniques (e.g. TDD) that make Agile successful. If Agile is as much about the people as it is about tools, then we have a significant problem at hand. Scaling Agile within an organization suddenly seems to be a herculean task. Who are these people that "get" Agile and where can we find them?

Now some would argue that regulation intensive environments are not conducive for Agile. True. But that's all there is to it, it's not conducive but Agile is works in many such cases.

This list is a work in progress. As I encounter other challenges you'll definitely see them reflected here. Change is an eternal process and I hope that the next time someone is thinking of making a change in any of these frontier environments (s)he considers Agile as a creative process that teaches us to confront novelty and improvise as opposed to a new "process" or a "methodology" that comes with its own peculiarities of Do's and Don'ts.

Image take from:

Agile Release Planning

"Almost every project has it; there's nothing new about Agile Release Planning." Not quite! What's different about Agile Release Planning, like many other good Agile practice is that it is lightweight, inclusive, and a living plan that is well socialized. Every release plan is different. The anathema of the traditional release plans, though, are their elitist origins, seclusionary existence, and staleness. The realities of project kick in and then an eerily familiar yet enigmatic (to me) behavioral (anti)patterns start to fortify; the unrealistic to begin with plans morph into contracts between IT and Business and nothing ever changes - budget is set, schedule does not move, and scope of course only increases.

Someone once said to me, "You Agilists are lucky". I think, he meant to say that Agilists are pragmatic and call out the fashionable insanity of planning. The notion that neither scope nor schedule and budget move is untenable. Release Plans are and should be evolutionary by nature. This evolution stems from other Agile practices like prioritization and iterative design practices.

The slide deck below is an aide I use to convey the above message.