Bottles of bacon and chicken wing soda

Bacon and Buffalo Chicken Wing Soda – things have to change!

Culture is a reflection of how the people within an organization act. The culture is protected by peer pressure and the processes, procedures and policies teams and organizations enact and enshrine. Overall organizational culture is difficult to change. Chip and Dan Heath, authors of Made to Stick, would call culture “sticky.” One major reason culture is sticky and generates defense mechanisms is that once a culture is entrenched those people that are inside the culture become comfortable. They understand how to make the culture work.  Organizations also find how to make culture work. Alignment to culture fosters higher worker satisfaction, more employee engagement, higher productivity and employee retention. Cultural fit matters to organizations and to individuals.  The dark side of cultural alignment (all forces need to have balance) is that cultural alignment can lead to stagnation and low levels of innovation. As we have noted in the past, “culture eats change for breakfast.”  New organizations establishing a culture and organizations and cultures that have generated hardened boundaries will have several levels of defense beginning with hiring for culture. Culture guides information sharing, how work is done and how individuals and groups interact therefore directly impact value delivery at a team and organization level. Cultures that generate prescriptive processes, procedures, and policies and then make adaptation difficult make change and innovation hard. (more…)

A significant amount of transformation and leadership literature centers on establishing or changing the culture centered on values. Instant problem.  According to the Harvard Business Review online article on organizational culture (May 2013)  “there is little consensus on what organizational culture actually is.” There are two common threads in the definition of organizational culture; definitions that center on value, and definitions that center on behaviors. Many change leaders espouse value-centric definitions.  This decision causes them to focus their efforts on changing values in order to change the culture. These change programs are immediately starting in a difficult position. Values are amorphous.  Every individual interprets specific values differently.  For example, I asked several friends to define creativity.  Each person had a different definition.  Some of the differences were more than mere nuances.  Our individual interpretations would make the outcome of embracing the value of creativity unpredictable.  The variability of how we interpret values make it difficult create a common vision and then elicit a common outcome. Diversity makes this issue even more problematic.   As someone schooled in the need for measurement and feedback, the lack of a clear definition makes monitoring and measuring a change in the values at best difficult and often outside of the expertise of most internal measurement groups.  Without a clear definition and without a mechanism for monitoring change, talking about values is merely window dressing. (more…)

 

XP Explained

This week we continue with the building blocks of Extreme Programming by tackling chapters four and five in Kent Beck’s Extreme Programing Explained, Second Edition (2005). Chapters four and five provide a deep dive into values and principles.  Why, when we talk about frameworks or methodologies, do we spend so much time on values and principles?  Simply put, values and principles provide a rationale for the practices that are the nuts and bolts of a methodology. Without an understanding of why we do something, it will be difficult to hold on to a practice or to understand when and why to tweak a practice when things get tough. (more…)

XP Explained

This week we begin Section 1of Kent Beck’s Extreme Programing Explained, Second Edition (2005), titled Exploring XP, by tackling Chapters two and three.  The first two chapters in section One provide us with an overview of the conceptual framework that underpins XP. 

Chapter 2: Learning to Drive.  In this chapter, Beck challenges us to consider that developing a product or writing code is like driving.  The metaphor of driving is used because driving is not a one-time event where you start the car and point it in the right direction then take a nap.  Rather, driving is a process of constantly paying attention, gathering feedback and making a series of small changes so that you arrive at your goal healthy and whole.  As noted in the preface, the core XP paradigm is “stay aware, adapt, change.” Tying the driving metaphor and XP together is the common problem of mushy requirements. In XP customers drive the content of the system and steer by getting feedback and adapting based on short iterations.  (more…)

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:

  1. Organization
  2. Processes
  3. Contracts

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.

Organization Problems

There are three major organizational problem sub-categories that impact Agile implementations:

  • Value / Cultures
  • Process
  • Contracts

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:

Fixed Mindset

Agile Mindset

  • Ability – static
  • Goal – look good
  • Challenge – avoid
  • Failure – defines your identity
  • Effort – for those with no talent
  • Reaction to challenge –
    helplessness

 

  • 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.

Solution:

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

  1. Alignment of goals:  Supports transparency and motivation
  2. People:  A diverse skilled workforce
  3. Involvement:  Build true teams, not just collections of individuals
  4. Change:  Listen to feedback and dynamically adjust tactics and strategy
  5. 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.

Pseudo Experts

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).

Solution

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.

Solution

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!