Johanna is known as the “Pragmatic Manager.” Known for her frank advice and humor, Johanna is the author of the Pragmatic Manager newsletter as well as numerous books on agile, estimation, and effective management. Johanna helps leaders and managers do reasonable things that work.
This interview touches on agile development, retrospectives, and distributed teams.
YOUR STORY
David Horowitz (CEO, Retrium): Tell me about your story. How did you get started as a management consultant?
Johanna: I had been a director in several organizations. I realized I wanted to move faster than my employers. That’s not always a feature in a manager. It is a feature in a consultant.
David: You call yourself a "Pragmatic Manager". What does that mean to you?
Johanna: I help people start from where they are, to achieve what they need to achieve. I don't care what practices they use. I care about the principles. Here's an example: When I teach my agile and lean workshop, I show people a Scrum board and a kanban board. I explain about the pros and cons of each. The client then decides what will work for them, in their context. The principle is make the work transparent. The practice is that they select the board that works for them.
David: How did you get started in the agile world?
I am an old programmer. Back when I was coding, we had to work feature-by-feature, because we had to write small, short pieces of code so we could use a linking loader. (Yes, I am that old!)
I used continuous integration because I didn't want to lose what I worked on. I would write some code, save it, integrate it and see if it worked multiple times every day.
When I became a project and program manager, I realized how much risk my projects and programs had. How do you manage risk? By seeing progress. Back in the '80s, I worked in one company where I asked everyone on the program (12-15 teams, and it included hardware) to show their progress with a working deliverable every month. That meant they had to keep the code clean or they would not be able to integrate. In that organization, the culture was to integrate and build everything every day.
When I left that company and went to another company, they did not have that culture. I managed a program of just seven feature teams. I asked them for monthly deliverables and a demo every month. 5 of the teams said yes, and they were able to demo each month. Two teams wanted to write all their code first and then test. They were unable to demo anything at the end of the first month.
I asked them to change how they worked. They were not happy (!), and they were able to demo the next month. That changed their perspective.
I used a non-agile life cycle called Staged Delivery for years. It doesn't have the transparency of agile, but you do work in shorter timeframes, producing complete features. I have used timeboxes forever. I wrote about the concept of inch-pebbles which you might recognize as small stories back in 1999.
I was as agile as we knew how to be before the Manifesto :-)
DIstributed teams
David: What's the biggest benefit to teams working remotely?
Johanna: You can hire anyone anywhere. If you want people to work with your customers, you can, because they are there.
David: What's the biggest challenge?
Johanna: How to build and maintain the trust in the team. If you don't have trust, it's really difficult to collaborate and produce together.
David: What can distributed teams do to ensure successful collaboration?
Johanna: Use face-to-face collaboration. I know, that sounds funny. But if you only chat or email with people, you don't see their faces. it's too easy to assume the worst of people instead of the best. How can you know if I'm being sarcastic or rolling my eyes if you can't see me??
David: Are tools important? If so, which ones? If not, why?
Johanna: Sure, tools are important. The ones that ease communication and collaboration are the most important. I use a variety of IMs, so I have a chat window open at all time. I like communication tools that have the ability to turn on video. I like the ability to share documents as we write them.
RETROSPECTIVES
David: Do most teams you coach run retrospectives? How critical are they?
Johanna: Retrospectives are critical for a team to know what and then how to improve. I wish I could say all my coachees run retros, but they don't. It's often the first thing I recommend to improve what the team delivers and how they work.
I have found that if a team doesn't run retros regularly, that is often a sign of a systemic impediment.
David: What's your #1 piece of advice to agile teams who are wondering how they can run more effective retrospectives?
Johanna: Make time for the retrospective. A 20-minute retro after two weeks of work is insufficient. If you make time—at least an hour, preferably closer to two hours, you will discover that running the retrospective will surface more impediments. If you surface them, you can address them.
David: Are there extra challenges in running distributed retrospectives?
Johanna: Oh yes! Finding a way to collaborate is difficult when you try to run distributed retros. How do you write on stickies? Where do you put them? I like an emotional timeline as part of many retros, and that's quite difficult to do with a distributed team.
I look forward to your tool because I suspect it will help people see what they are doing and what they could decide to change.
David: What's the best way for our readers to get in touch with you?
Johanna: Through my site, www.jrothman.com. Take a look around and read something. Drop me an email, maybe sign up for the Pragmatic Manager.
David: Thanks so much for your time!
Distributed team? Want to run effective retrospectives?