Under-performing Agile? Part 1 Organizational Issues
Audio Version: SPaMCAST 225
Agile is not a panacea. Regardless of methodology, technique or framework; delivery is not assured. Realistically just about anything can happen in the world we practice our profession. Tomorrow a storm could interrupt operations; another project of greater value might catch management’s eye, changing the resources or staffing available for the project. Many of the things that happen are outside of our organization’s control or at the very least outside of our control.–However many things are within our control or at least within the broader organizations control; therefore, we do not have to be victims.
These are the issues this essay will focus on as they affect the performance of Agile. So meteors hitting the planets or super storms striking will be what they are. People, processes and behaviors are another matter entirely and are the core of why most agile implementations go off the rails.
If your implementation of Agile is underperforming, where should you start looking for the problem? I suggest that three macro areas are the typical sources of Agile performance problems:
The organization category relates to both the physical organization and the gravity well the organization exerts. The gravity well includes the other organizations or people that they influence. These can include suppliers, customers, suppliers to suppliers, restaurants, and dry cleaners; the list can go on and on. The bigger or more influential the company is, the deeper its gravity well. The process category includes the tools and techniques used to deliver functionality. The final category is titled contracts. Contracts can be used to govern how work is done or how it will be delivered. Agile projects governed under non-agile contracts will have issues of effectiveness and efficiency. In a broader sense, contracts tend to be a marker for low trust transactions. While contracts could be construed to be a process or organizational issue, I believe it tends to be a broader and more emotional issue; therefore, the solutions will differ.
There are three major organizational problem sub-categories that impact Agile implementations:
- Value / Cultures
Values / Cultures
The first of the sub-categories are value / cultural issues which are driven by differences in mindsets. Viewed as a dichotomy, classic management / fixed mindset and Agile management / Agile mindset are polar opposites which have very different views of ability and paths to success. Examples of the differences in the two are as follows:
- Ability – static
- Goal – look good
- Challenge – avoid
- Failure – defines your identity
- Effort – for those with no talent
- Reaction to challenge -
- Ability – can grow
- Goal – to learn
- Challenge – embrace
- Failure – provides information
- Effort – path to mastery
- Reaction to challenge – resilience
Mindsets are expressed in differences in how people learn and adapt which creates differing expectations of how they want to be managed and how they will tackle problems. When the mindsets of teams differ from how they are being managed, something will have to be given up. The usual victims in this equation include efficiency, effectiveness, innovation, morale and stability. Agile teams with the wrong mindset will be less than effective. Agile teams fighting managers that are managing from a fixed mindset paradigm will have tragic results.
An example of the how the two mindsets systemically differ is as follows:
The goal of someone with a fixed mindset is to look good and to avoid failures. Failure avoidance is a key behavior pattern because failure defines who you are and what you can accomplish. It will define your promotability. This type of belief structure will define how you act and react and what you expect form others.
An Agile mindset expects people to learn and grow. Growth is generated by embracing challenges. Risk and potential failure provides the experience to grow. Growth at the individual and team level will equate to greater value to the customer and to the organization.
Agile teams or teams with an Agile mindset need to push the envelope, which means a team may fail in the short run. The word failure tends to panic people in many environments. No one wants to fail; however, the only way not to fail is to always play it safe — to never stretch the envelope — to never explore new ways to address problems.
Clashes of the two very different mindsets cause conflicts. Resolution of conflict requires time, effort and mostly attention to resolve. All three of these items –time, effort and attention, are precious resources that would be better spent delivering customer value.
For further reading on how our mindset can affect our success, I recommend Carol Dweck’s Mindset: The New Psychology of Success.
The solution to the problem of a mindset mismatch is for the organization to embrace an Agile business philosophy throughout its structure or to forget being Agile all together. The change in business philosophy will help mold the organization’s culture so that an Agile mindset can flourish. The five basic tenants of an Agile business philosophy are
- Alignment of goals: Supports transparency and motivation
- People: A diverse skilled workforce
- Involvement: Build true teams, not just collections of individuals
- Change: Listen to feedback and dynamically adjust tactics and strategy
- Value Focus: A single-minded focus on delivering business value that is continually reprioritized
None of these tenants will be easy to enact. I was recently told that if there wasn’t pain in the transition, you wouldn’t be doing it right.
Everyone has an opinion about what is Agile and how to “do“ Agile. Opinions are often formed by grazing through books, articles, conferences or websites. To paraphrase a popular State Farm Insurance television commercial, “Everything you hear on web is true, right?” Unfortunately, many of the opinions, when they are put into practice, can do more harm than good.
I would like to suggest that expertise is built not only on academic knowledge but also upon experience that has generated both good and bad outcomes. Real experts are built on good doses of theory, reflection, experience, mentoring (from those who are smarter) and then experimentation (do this last).
Every Agile organization should have at least one coach. A coach helps the organization and teams by make sure they are aligned and have the tools so that learning happens. As a learning organization begins to crystalize, less coaching is needed. Coaching will always be required however over time as learning becomes the norm we will begin to need less outside help, because everyone will be a player / coach.
Lack of Measurement
When the word performance gets used I tend to get antsy unless dealing with evidence, rather than supposition or individual anecdotes. Many immature Agile organizations think that measurement is “old” school. Without measurement, how can you build a release plan and more importantly how can you know and prove that you are delivering business value? Just saying “trust me” or “it feels better now” is not a long-term solution.
Measurement is important but there isn’t one answer. Each team may have a different set of needs; as does every organization. What I suggest is that what can be a one size fits all solution is a framework.
First every team needs to focus on what they need to know in order to plan, monitor the work it is delivering and then to know how to improve. Leveraging a framework like GQM (Goal, Question, Metric) provides teams or groups with a means of thinking through what is really important (not just what the PMO tells them is important) and what they can do to improve. The goal of measurement is to provide information so that a team, a product or an organization can know if and how they are contribute to the results of the overall system.
Part 2 in Two Weeks. We will pick up with the process category!