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.

Acceptance Testing | Glossary

Definition:

This is a testing technique performed to determine whether the software system has met the required specifications. The main purpose of this test, is to evaluate the system’s compliance with the business requirements, and verify if it is has met the required criteria for delivery to end users.

Further Reading:

  • “User Acceptance Testing: A Step-by-step Guide” , by Brian Hambling and Pauline van Goethem.