Category Archives: Change

Leading Tech Teams

Leading Tech Teams

Slides from my workshop at I T.A.K.E. Unconference 2014


Behavior follows system follows mindset


How can you get different results? Should you change people’s behavior? Should you create different working systems? Or should you address their mindset? I think it’s the latter.

Jurgen Appelo spawned an interesting thread on Facebook by saying:

You cannot change an organization’s culture. What you can change is your behavior and your influence.

Several people joined in and voiced their opinion. I both agree and disagree with Jurgen. The following lines will try to describe how.

I believe behavior is a result of the social system people are working in. So, if you’re a tester and you’re being measured on the amount of bugs you report (a systemic feature), you will tend to open more bug reports to meet your targets. And you’ll do that even if the agile coach or the management writer advises against it. Or if you’re a project manager who is handed down a fixed price, fixed scope contract, all the arguments of the #NoEstimates crowd will likely fall on deaf ears.

I believe the system is a result of your mindset. What do you believe about people? Are they lazy and always trying to cheat? What do you believe about social systems? Should we focus on efficiency, utilization and optimize for each function (development, marketing, product management etc.). Then you will design hierarchical, silo-ed organizations, controlled via budgets and projects.

Based on the two assertions above, I don’t think it’s enough to change your own behavior to achieve meaningful results in the organization. Changing your behavior does not affect the collective mindset. What you can do however — on this I agree with Jurgen — is influence other people, try to get them to change their mindset. In other words, effectively engage in double loop learning.

As a coach, I must spend at least a third of my time trying to change mindsets. “Why should there be a development and a QA team?” “Can performance be managed via yearly performance reviews?” “How is the team leader role helping us achieve our goals?” “Should we have one developer per module?”

I find that I can’t start influencing people’s behavior until we start debating questions like the ones above. Only when we agree to learn more about each other’s deeply rooted beliefs can we start designing new systems. And these new systems, in turn, usually generate different behavior.

Behavior follows system follows mindset.

Is your mindset blocking your agile transformation?


In the last few years I’ve been involved in several agile or lean transitions. Some of them went smoothly and for others we had various challenges.

Upon reflecting on the main causes that slow down or even kill transitions, I became convinced that the prevailing mindset of the organization is one of the key blockers. To fully detail my view, I’ve written a paper called Mindset as barrier (PDF, 9 pages).

Give it a read and tell me what you think.

(Image from:

2013: the state of agile


If you’re considering adopting agile, or have already done so but wonder how your adoption is going relative to other companies, you’re in luck. VersionOne has recently released the results of their yearly survey titled “The State of Agile“. For companies transitioning to agile or considering it, the report provides valuable clues on how to maximize the results of their change initiative. 3501 responses were collected for this survey.

Going over its contents, some things stand out:

  • Scrum is still the market leader and seemingly the only choice at the moment. Teams that have adopted vanilla Scrum, Scrum + Extreme Programming or Scrum + Kanban account for 73% of the total. Kanban-only implementations are at a low 5%. [1]
  • Agile passed the early adopter phase. 19% of all companies have been doing it for more than 5 years, and 53% for 2-5 years.
  • Agility is scaling past the individual team level. 57% of the respondents said they have at least 5 teams doing it and 38% have more than 10 teams.
  • Not all agile practices are equally popular. Some numbers I hope to see increasing in the future: 50% of respondents integrate development and testing, 47% do refactoring, 30% pair program and only 15 % measure cycle time. On the flip side, there’s a 10% increase in the usage of retrospectives in the last 2 years. This is good.
  • It seems we’ve found a scenario where agile seems to be difficult to implement: outsourced projects. Plans to run that type of project using an agile approach dropped from 77% to 39%.
  • There are still many misunderstanding regarding agile. The biggest concerns people report are related to a lack of up-front planning, loss of management control and lack of predictability. In my experience however, it’s often the opposite: teams and managers report they feel they have more control and optimized predictability after adopting agile. Expect a blog post on this soon.
  • I imagined everybody would report a faster time-to-market as a result of going agile. After all, that was the whole point of agility, wasn’t it? The percentage, 83%, while still good, indicates that more change is needed across the organization to reap full benefits. If I had to guess, I’d say it is at the portfolio and program management level or in the marketing or sales departments.
  • If you want to succeed, the most important recommendations are to involve senior management and to properly train everyone. At the same time, you must be ready to face the biggest barriers to change: company culture and reluctance to change.

In closing, I want to thank VersionOne for making the effort each year to make this happen. I’m sure it does wonders to their sales, but it’s also a very valuable resource for us agile coaches.

[1] It’s likely that the results of this survey are biased — after all, the majority of the replies comes from VersionOne customers. The report even indicates that 2/3 of the respondents are from the US and 3/4 are from companies with 100-1000 employees. As such, you might want to take the results with a grain of salt. I especially suspect that smaller companies and startups aren’t accounted for all that well. However, the general findings match my experience with companies adopting Agile.

Re-blog: How to be a change catalyst

Over at the Mozaic Works blog I’ve published a new post describing my view on change and some of the techniques I’m using when I try to initiate and catalyze it.

Slides from ‘Catalyzing Change’

A month ago, I was asked by one of the members of the local agile meetup to share my thoughts on how one might drive a TDD adoption. Tonight, I held that presentation. But I slightly “extracted an interface” and gave a generic preso about catalyzing change.

By the way, I don’t think you can actually “drive” a change. You can however ignite a fire and catalyze the reactions.

Kotter’s model for change

“If we don’t change, we don’t grow. If we don’t grow, we aren’t really living.”
Gail Sheehy

The one constant in both our professional and personal lives is change. As a coach, I am often called to help people instigate or deal with change. One of the frameworks I use in these situations is the model for change popularized by John Kotter.

Kotter defines change as an 8-step process, as follows:

  1. Instill a sense of urgency
    Communicate as clearly and as broadly as possible that a change is needed.
  2. Assemble a change leadership team
    Bring together a cross-functional team that would lead the change.
  3. Figure out the vision and strategy for the change
    The leadership team should come up with a high level direction for the change.
  4. Communicate the vision
    Everyone affected by the change should understand what is coming.
  5. Empower everyone for action
    Make sure that everybody can contribute and influence the change, not just the leaders.
  6. Create a few short-term wins
    Make the first few steps with clear outcomes. Communicate the outcomes.
  7. Build on top of the gains and produce more change
    Be relentless after the first wins and produce more.
  8. Integrate the new approach in the culture
    Hold on to the new behavior until it’s deemed “normal”.

I have a few beefs with the model, namely that it’s been devised as a way for “managers” to change “employees”, but if you take care to be as inclusive as possible at each step of the way, I imagine it being useful regardless of the empowerment level in an organization.

You also need to sense how the system is responding to the change and adapt as needed. That means being as holistic as possible in your assessment of the change impact (what might have happened elsewhere as a result of the pending transformation?).

If you want to read more, here are some of Kotter’s books on the topic: