Category Archives: Agile & Lean

KrisMap: An Organisation’s Persona

(Joint post with Michael Sahota)

Essence of Kris

Imagine your ideal organization.
We may think of the organizational culture as the “personality” of the company.
What is the personality of an Agile organization?
Gather Identity Attributes

Culture is Aggregate Identity

Organizational Culture is the emergent aggregate identity of all her people.

Aggregate Identity

Aggregate Identity

Some questions to help you think about Her Persona:

  • What is the organization like?
  • What does she like?
  • What does she want?
  • What does she feel?
  • What does she look like?
  • How does she behave?

Continue reading

See the Whole

Noticing Improvement

There’s a lot written about how Kanban is less disruptive and demanding than Scrum in most contexts, and I think some of that might be true. There’s probably as much being written about how Scrum may be more merciless at uncovering dysfunctions in a system, throwing all of the bad stuff in your face every two weeks.

Flipping the Coin

Listening and observing to some interesting conversations today at a client, I came to realise a more crucial difference between Kanban and Scrum, that I haven’t read anything about so far:

Kanban makes it much harder to notice improvement.

See the Whole

See the Whole

Observations

This morning, when I approached the client’s office, I met one of the organisation’s Kanban and Agile early adopters, who recently had not been very happy as his team lost interest and motivation in Kanban, or any improvement. The common frustration of the organisation had basically killed their enthusiasm (which for some team members hadn’t been too great to begin with). Now he approached me with a broad smile, and as I asked him, “How’s your team doing?” he laughed and said, “Great!”, and generally emanated happiness.

I hadn’t seen him doing that in months, so I asked, “Wow! What did happen that improved your mood so much?” Thinking, his face fell, and he said, “Nothing. They still hate Kanban.” Puzzled, I went on, “So, what made you so happy?” and he said, “Well, our customer recently had another important project going on, so they didn’t really have time to give us many requirements, and we had time to clean up some stuff. Generally, we didn’t have much stress any more.” Wow. Didn’t notice the improvement although they were happy.

Later today, another team, retrospective. “I don’t have anything. We can’t change anything anyway.” Nodding all around the table. This was the most frustrated of all our teams. We talked through possible improvements, we asked how we could be of help, which wishes we might take to management… In vain. They didn’t want a standup anymore (no opportunities to collaborate, all specialists, no slack to learn), they seemed to think their board was useless and just additional effort to update… Then I asked if they wanted to stop using the board. Silence.

They started looking afraid, not frustrated and complaining anymore. They looked at each other and one (who had been relentlessly complaining the whole Kanban idea was useless from the start) said, “There’s something in the back of my head, I don’t really know what it is… And I think I want to keep it.” Relief all around. Action item: keep the board, keep updating it, standup once per week (had been two before). Wow.

What unobserved improvements have your teams or organisations surprised you with?

Discernment

What happened? These teams work in a rigid, frustrated organisation—it’s persona would be clinically depressed. Both teams have not yet managed to cut their work into pieces of a size where it would be reasonable to measure the lead time. They have no way to see their improvements, and for an outside influencer it’s still hard. Scrum would “force” them to cut their work into measurable pieces. Is that really a bad thing?

Containers add visibility. Not only to challenges, also to improvements.

How do you mitigate that in your influencer’s work, using Kanban?

AgileCoachCamp Norway

What is Agile Coaching?


AgileCoachCamp Norway
AgileCoachCamp Norway

Professional Coaching

The AgileCoachCamp Norway 2012, which I’m currently attending, was opened by an inspiring session with an ICF coaching trainer, Jan Georg Kristiansen from Erickson Coaching Nordic AS in Norway.

He gave us a definition of ICF coaching as a 100% client-focused conversation, and we decided to have an Open Space session to take his definition as a starting point to define our shared understanding of Agile Coaching.

Engagement

Agile coaching is a 100% client-focused engagement which enables continuous improvement, because the client owns aligned goals and purpose across organisational levels and the people doing the work define the steps towards those.

Minimum Required Skills

An Agile Coach needs to have

  • a deep understanding of Agile & Lean, which includes Systems Thinking,
  • coaching skills, the awareness to know when to coach, mentor, and teach and how to switch hats,
  • servant leadership,
  • good facilitation skills.

Optional, but not mandatory skills include coding, training, management experience, … We collected this list in a session hosted by Rachel Davies:

Agile Coaching Skills 1/2
Agile Coaching Skills 1/2
Agile Coaching Skills 2/2
Agile Coaching Skills 2/2

Guiding Principles

An Agile Coach focuses on improving the client’s business, avoiding local suboptimisations and challenging assumptions on all levels.

An Agile Coach ensures congruence between Agile and Lean values and principles, the goals of the people she works with and the people who pay her.

An Agile Coach makes herself dispensable as quickly as possible.

An Agile Coach is committed to her own personal growth and continuous improvement of her skills. To guide her on that path, she should have a personal coach.

Thank you, Michael Leber and Andrea Chiou, for suggesting the second principle!

Please add more comments!

Good or Bad? Like this image by thegoldguys!

Thoughts on Words: Project

Thinking is shaped by the words we use. Management thinking is shaped by the words managers use and are used to. If we want people to change their mindset, we must stop to use words that carry a history of bad meaning with them. Let’s start to create a new language to talk about development that explicitly avoids mistakes made in the past.

Project

Project as a concept was devised in a time when management still thought they could execute an endeavor according to a detailed plan. This worked in the times of Henry Ford, when employees were glad to be paid, and customers accepted that their cars were black. Both is not true anymore. Employees seek mastery and purpose, and request autonomy instead of detailed plans. Customer value today is rather discovered than simply produced. Uncertainty is the only thing you can be certain of.

A project is a temporary organisation formed by people working on a sufficiently identified goal. As long as projects were few, changes infrequent, this paradigm had its use. Now, changes are the norm, and every enterprise runs multiple projects. These don’t function as temporary organisations anymore when each member is belonging to multiple organisations at once. I don’t see the concept adding any value anymore, yet it brings this whole history of misconceptions to the table… Continue reading