Interview with Johanna Rothman

It was a pleasure having a conversation with Johanna Rothman, President of Rothman Consulting Group Inc. She is among those few people who has witnessed how Agile methodology has emerged over the period of time.

In our conversation Johanna discussed the difference between Coaching and Consulting, if Agile team hiring is different from regular hiring process and certain aspects of leadership.

Q1. I was going through your website and the first questions came to my mind was what is the difference between coaching and consulting. Please let us understand five major differences.

Johanna: When I coach people, I can do a deep dive into their concerns, challenges, actions, and reactions. We discuss the why’s, how’s and what’s for that individual person–both in their sphere of influence and outside that sphere. We take a system view to determine how the person can be effective.

When I consult, I take a system view for a team and an organization, not just the person. I work with more than one person, and often, more than one team.

Here are some differences:

Coaching

Consulting

One-on-one work. We work together. One-to-many work. I work with teams and managers across the organization.
We know our intended backlog, so we know what we will discuss. We don’t know the deliverables or the result. We know the client will try small experiments and report back. I structure consulting so we have defined results when we start working together. I know my deliverables.

I suggest experiments the client can do after this visit or in the future.

We discuss personal interactions in depth. Through the interpersonal, we discover the reinforcing loops and discuss them.

I often ask questions about the system(s) in the projects, but that’s not my focus.

Via the consulting (straight consulting or an assessment or a workshop), we discover reinforcing loops and discuss them in depth.

We might address specific interpersonal interactions if I notice them.

We design simulations or experiments together. I might have the client try a simulation I already designed.

 

There are some similarities, too:

  1. I often recommend people read and consider some specific writing to help them understand ideas we will or do discuss.
  2. We often draw pictures to see the situation(s).
  3. Sometimes, I create a simulation for the client to perform and report back.

Q2. What is the key to make geographically distributed agile project work?

Johanna: If I have to choose one thing, it’s respect. The team members need to learn to respect each other. The managers have to respect the team as a whole–no moving people in and out of the team.

The team decides how it will work–no one can mandate how the team will work. Yes, the team has a project to work on, but no one can tell a given team or team members how to work. The team decides all of that.

I am writing a book with Mark Kilby about geographically distributed agile teams now!

Q3. Is hiring an agile team any different from regular/general hiring?

Johanna: The short answer is No. 🙂 The longer answer is that the interpersonal skills are different for agile teams. We look for more collaboration, more willingness to experiment, more adaptability for agile team members.

In addition, an agile team must hire together. That doesn’t mean panel interviews–which are horrible–but developing and agreeing on the job analysis, understanding how to interview together, and how to agree on a candidate. The manager has to be involved, but agile hiring–at minimum–involves the team from interview to decision to hire.

Q4. In today’s world, how important is it to learn saying ‘No’ and end multitasking?

Johanna: The more work you have to do, the more you need to stop multitasking.

We have so many devices that can interrupt us, it’s even more critical than ever to stop multitasking on different work or different projects. I might be the only person in the world to turn off notifications when I’m focused on a project. I can’t stay in single-focus all day, but for an hour or two? I must. Or, I won’t finish anything.

I make my deliverables small, I focus on them until I finish, and then I pop back up.

It’s the same thing with everyone else. If you give yourself a chance to focus, finish something and then look around, you would find your throughput becomes more even and, at least for me,  higher.

For managers, this is even more important and more difficult. Managers make decisions that affect many more people than a team member does. Managers need to focus and finish something, and then do it again and again and again.

Q5. Give us insights on two scenarios when agile can go wrong.

Johanna: If a team isn’t interested in using agile approaches, agile is wrong for that team. If a manager wants a team to use agile approaches, first, invite the team to explain their position. I like to do this with open space.

Managers can try to mandate an agile approach. Even worse is when a well-meaning manager mandates a specific approach or a specific board.

However, agile approaches are a cultural change. People can’t successfully change their culture–especially to a collaborative approach–if they are told what to do and how to do it!

The second wrong is using an agile approach that doesn’t fit the team’s context. I see this when teams adopt a framework without looking at their context and team. (I wrote a whole book about this: Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver.)

Q6. How important is storytelling when undergoing an agile transformation? Is it meant just for  leaders or managers or team or for all?

Johanna: People learn through stories. A story sets a context and explains the difficulties she encountered, what she tried, what worked and what didn’t, and where the situation is now. I love learning through stories and I love reading stories about what worked and didn’t work.

Everyone needs stories at various levels. If I’m a tester, I want to know how the testing worked. If I’m a manager, I want to know about all those projects and how the team collaborated with the customer. If I’m a requirements person, I want to know how the product owner worked and what happened.

Stories help us see the whys, hows, and whats to see if that situation fits our context.

Q7. Can situations make a person leader? When do you realize that a person has leadership skills/traits?

Johanna: Everyone has the possibility of being a leader. I have a different question: Does the culture of the organization encourage or discourage leadership? Here’s what I mean by leadership:

  • A person who realizes the current situation is not working or helpful for the person and/or the team.
  • A person who is ready to help the situation change.
  • A person who invites various approaches to change so the changes fit the situation.

I have a tendency to see a new possibility and say, “Let’s go there!” That is a form of leadership. It is not the only form. Sometimes, leaders are great facilitators. Sometimes, leaders help others understand why we should go there. Sometimes, leaders who have more empathy than ideas are even more successful.

There is no one right way to be a leader. What does the situation need? Can you help the situation? That’s leadership.

Q8. Final words for our audience.

Johanna: Thanks for asking me these questions. I invite anyone who wants to continue the conversation to start at www.jrothman.com. Thanks!

 

 

Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development.

She is an author of over two hundred articles and several books: -Manage Your Job Search -Hiring Geeks That Fit -Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects -The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management -Behind Closed Doors: Secrets of Great Management etc.

Interview with Patrick Steyaert

Today’s conversation is with Patrick Steyaert. He is an international speaker and winner of the Lean Kanban North America 2015 Brickell-Key award for his contribution in the development of Discovery Kanban, a method to manage knowledge work in the context of innovation and change.

Patrick is a wonderful person to work with and here is our discussion on how change can challenge thinking.

Q1. What is the key hurdle in implementing agile?

Patrick: The key hurdle is that Agility requires a whole new way of thinking. Rather than the “either-or” (reductionist) thinking that underlies traditional management (and much of our education) it requires “and” thinking (integrative thinking). Any successful (agile) change must start and end with challenging the traditional “either-or” thinking. If it does not do so, agile will be a revolution that is not a revolution. In other words, if the thinking is not fundamentally challenged then agile just becomes a recipe just like all other recipes before. This is the case for many of the current agile change initiatives where agile is treated as a recipe: first, an agile method is chosen; second the benefits of implementing the particular agile method are unquestioned, so the biggest obstacle becomes actually just implementing the method; and finally success is declared when (parts of) the agile method have finally been implemented. It does not bring the organization closer to business agility, the thing they actually need.

Q2. Please explain Discovery Kanban.

Patrick: Agile development is not sufficient anymore. Rather than just agile development, organizations are looking for business agility where the whole organization is engaged in creating value through meaningful work. Discovery Kanban, together with Upstream and Customer Kanban, form a family of Kanban systems that create flow and pull not just in the development or service delivery team(s) but end-to-end from suspected to satisfied need.

Q3. How a change can challenge the thinking?

Patrick: Today’s agile training and coaching is too much focussed on practices and too little on teaching and coaching a new way of thinking. It seems that there is an assumption that the thinking will change when practices have been implemented. I see little evidence of this. Our experience with Okaloa Flowlab has been that we can actually start with teaching a new way of thinking before methods and practices and that this has many advantages. We immerse people in a simulation where people experience the limitations of the conventional way of thinking (division of labour, capacity utilisation, predictive control) and the advantages of the agile way of thinking (flow, self-organization, active learning).

Q4. No idea should turn into a dogma. What do you mean when saying so?

Patrick: In a revolution that is not a revolution, one dogma is replaced by another dogma. We see a lot of this in the agile space. People that strongly advocate for one particular strand of agile at the exclusion of other strands of agile. They are replacing the dogma of traditional management with the dogma of their particular strand of agile. On the other hand we see people that strongly advocate for a “pragmatic” approach. What they actually mean is an approach where you look at agile as a toolbox of practices. I call this opportunistic pragmatism. The truly pragmatic approach is one in which you have strong beliefs that are loosely held. It starts with recognizing that all good ideas have a boundary to their applicability and therefore there should be no dogma’s. The only dogma is that their should be no dogma.

Q5. Throw some light on ‘Uneven flow leads to organized chaos with waste and overburdening’.

Patrick: Many organizations suffer from an uneven and unpredictable demand. This inflicts a lot of pain in the delivery organization as it tries to match the demand. Often times the delivery organization alternates between periods of overburdening (more demand than capacity) and starvation (more capacity than demand). Delivery teams can develop a certain level of flexibility to cope with changing demand but this only goes so far. The solution lies in leveling the demand.

Q6. What is Triage?

Patrick: Triage is a technique that comes from medicine where it is used to decide the order of treatment based on an assessment of the seriousness and risk of escalation of illness or injuries of a patient. It is an effective technique to level or shape the demand in order to make most effective use of the critical resource. Since a couple of years now I have been using triage in upstream kanban where it plays a central role in leveling demand – avoiding alternation between starvation and overburdening.

Q7. How was your experience at Lean Kanban India 2017 Conference and how was it working with INNOVATION ROOTS?

Patrick: I really enjoyed Lean Kanban India. From the many interactions I had, the one thing that struck me the most is that participants were really open to discuss and explore new ideas. It really gave me the impression of a very vibrant community. I enjoyed working with Innovation Roots before, during, and after the conference. There is a real commitment for doing a good job of developing the conference and the community. A real joy to work with.

 

 

Patrick Steyaert is a founder and principal coach and trainer at Okaloa. He helps organisations to innovate and change. He works with customers ranging from high-tech SME’s to large incumbent companies. He is an expert in Lean and Agile with practical experience in both software, IT, and technology businesses as well as non-IT (logistics management, HR…)

Patrick holds a PhD in computer science and was involved as director in several start-ups. He has more than 15 years of experience of leading change and innovation in organisations. He is an LKU accredited Kanban trainer and Kanban Coaching Professional.