Tag Archives: coach

Movie Retrospective

When I'm teaching about retrospectives, there has always been a challenge: a simulated retrospective wants a shared experience. But what shared experience to use?

  • The one experience I know we share is the session we're in, but using a retrospective on the class sets up an awkward "meta" and recursive dynamic, as we try to do something and think about doing it at the same time.
  • A class often shares another experience (or set of experiences): the projects they're working on. Everybody may not be on the same project, but even if they are, real projects have real issues, and using real issues for an example almost instantly violates safety and takes away the magic circle aspect where it's safe to try new behaviors.

So:

1. Identify a movie as the shared experience. I've been using Star Wars, Episode IV, with the part of the movie from the rescue of Leia until Obi-Wan dies and the protagonists escape. (Sorry if that's a spoiler:)

(I'm sure other well-known movies would work as well but I haven't tried any; perhaps The Wizard of Oz or The Godfather or something more modern?)

It's possible a person or two hasn't seen the movie; I'm willing to take that chance. If I thought the background of the group was so diverse that a substantial part of the group would not have a shared movie, I'd try a different approach.

2. Ask people to imagine they were the protagonists, to recollect for a moment what happened in the relevant part of the movie.
[A couple times I tried to show the movie clip in fast-forward. From a technology standpoint, it was painful. But from the perspective of the simulation, it's a better simulation NOT to show anything. As in real life, people will have different memories of what happened and different perceptions of what's important.]

3. Use the recalled scenes as the basis for a retrospective.
I like Esther Derby and Diana Larsen's approach in Agile Retrospectives, and I use an abbreviated sample exercise addressing each of their sections. For example:

A. Set the stage: Check-In – "In a word or two, what's on your mind?"

B. Gather data: Timeline – "Recall the memorable, meaningful, and/or significant events; write one per sticky note, then put it on the timeline."

C. Generate Insights – Patterns and Shifts – "Look for patterns. What links? What shifts? Which are most important?". Or perhaps do a "Worked Well / Do Differently" analysis.

D. Decide What to Do – Dot Voting – Give everybody 3 dots to vote for what to focus on as a group over the near term. (They can put their dots on 3 different things, or all on the same one if they feel strongly.) Agree on the immediate (concrete) next steps, who will lead them, and how and when progress will be reported.

E. Close the Retrospective – Appreciations – Identify how others have contributed. "Bob, I appreciate you for ___." ("Thank you.")

Even doing this in an abbreviated manner (a few minutes for each) lets you run through a complete retrospective in miniature.

You can then follow it up with some debriefing to bring out any points you need to make.

Source:
Bill Wake, 2010. [8/15/10 – Thanks to Diana Larsen for helping me ensure "Decide What to Do" results in action.]

Coach Interview: Declan Whelan

Interview with coach Declan Whelan. Our discussion, held June 1, 2008 at the Agile Coach Camp. 

WW – Take a minute and tell me about yourself and your background, and how you became a coach and what you're up to.

DW – I've been in software for… I realized it's over 20 years and I think, "Oh my gosh, but I have the gray hair to prove it." About four years ago I was doing some consulting work with a company in Toronto. They had decided to go agile across the board and they brought in some excellent coaches such as Jim Shore, Jim Highsmith, Joshua Kerievsky, and Gunjan Doshi. I had heard about XP before that but I hadn't really taken that much interest in it. But then I saw what was going on. It was phenomenal watching the energy level and feeling that there was a deep and radical transformation happening. I got bit by the agile bug from that experience.

I then had an opportunity to work with a company that was really struggling with their software development group. They had been habitually late, habitually buggy. They would plan two or three point releases right after every major release because they knew they'd be patching it up. They were really at a point of failure. Someone said they were looking at firing the whole software team. I was a last resort. Now, the problems were really much wider than the software team but that was the flash point. This was a good opportunity to bring agile in because they had nothing to lose. So we did, somewhat incrementally because the team couldn't turn on a dime. We just did some simple agile things then slowly evolved it so that after 18 months they were ready to launch a full-blown XP project which was quite successful. After that, the team transitioned to use a combination of Scrum and XP.

I continue to consult with this company and have expanded my agile repertoire. I now provide agile coaching, training, and development on a wider scale.

WW – What practices did you start with on the incremental path you had them on?

DW – It was simple PM stuff. I had the business unit work with me and the lead developer to estimate all the open issues and classify them as:

"A": Must have
"B": Should have
"C":  Nice to have

I then talked to the development team and got their buy-in that they would commit to and support a date if I guaranteed that they would have twice as long to do the work as they themselves estimated. They supported that.

Then we gave the business unit a development budget for the "A" issues:

"A" Budget = # of developers * working days / 2

We guaranteed to the business unit that we would deliver all the A issues. We would try to get some of the B's and C's — "If they happen to fall in the same area of the code, you might get some of those." They key was that we committed to a date and that gave the business unit some degree of certainty that  they could plan around. We then met with the business unit on a regular basis to track progress and to reprioritize as any new issues arose — but we held them to their A budget.

And it worked. The team was able to get all the A's and they got a few B's done and they met their commitment. The business unit were impressed: "Oh my gosh, that's the first time we ever had a release delivered on budget and on time." We were actually one week late but that wasn't bad compared to their traditional three months late. After that, the team planned and executed the next four releases like clockwork. So it was really just team building, setting reasonable expectations, and building trust and confidence.  Once the team and I had credibility, we were able to take the next step. "If you like what this is doing for you, we can be an even more effective team if we take the next step."

WW – What do you find the challenging areas for the coaching you do, either personally or from the angle of the hardest group or person to work with?

DW – I find for me, the hardest part on a one-on-one basis is the really skilled software developer. I find it really difficult to go in and be in the position of saying, "We're all in here to learn. Life is a continuing learning experience and perhaps I can bring you something that maybe you haven't seen before." But if they've been doing it for as long as I've been doing it, and especially if it's in their domain and they've been working on this team for ten years, they don't think there's anything they could possibly learn. I find it difficult to get them to switch that bit in their mind, to open up to the possibility that they could learn something new. For me that's been the biggest personal one-on-one challenge.

WW – Do you have any techniques or tricks you try with that?

DW – I've tried to be technically really good. I try to write code frequently, if possible every day. Try to stay current so I can gain some trust that I know what I'm talking about. Pair with them. I still find it a challenge. The really good people will always claim, "Yeah, that worked well in this case, but in the 95% of the cases I deal with…" It seems to be this credibility thing, that I have a hard time bringing people to the stage where they can see for themselves. Do you have any?

WW – I do the same – I think pairing with them and being able to demonstrate that I can do solid things helps me too.

WW – What do you to do keep up with your own learning that you need to do?

DW – Read. I read a lot. I tend to read seven books at once. I don't know if it's a common pattern, it's probably not a good pattern. I also buy a lot of books that I have on the shelf. So if I have a question on planning, I'll go get Cohn's book on planning. I tend to have a large number of books.

There haven't traditionally been a lot of practitioners in my geographical area. I've been trying to build an agile community in the Waterloo area, which is where I work. That's looking good. I'm hoping that next year we'll have a local agile group.

I've had fairly challenging positions. I've been heads-down in the trenches for three of the last four years. It's only been in the last year that I've made an effort to get a website blog, go to conferences. I'm working on that part of it now.

WW – Is there a book you're reading now you particularly recommend?

DW – The one I'm reading now is Agile Software Development, second edition, by Cockburn. I started the appendices first like Alistair recommended. I find it fascinating he draws on relatively old stuff, stuff that was written in the '70s, and it resonates today. I'm an abstract thinker; I like to go from the abstract to the concrete, not the other way around. I think that's the way he writes. He derives concrete from the abstract content, and I like the mental model he likes to write from. I really like the jargon/analogy of a game. I'm a coach of kids in sports, and the strongest metaphor I've seen for agile coaching is coaching children's sport teams.

WW – Thank you.

 DW – You're welcome.
 

Resources

Review – The Principles of Product Development Flow (Reinertsen)

The Principles of Product Development Flow: Second Generation Lean Product Development, by Donald Reinertsen. Celeritas Publishing, 2009.

Lean product development can be looked at as flow-based product development. Reinertsen draws on a variety of areas (economics, queue theory, control theory, the military) to explore the consequences for product development. The book is organized as 175 principles, organized into chapters by area. Here are a couple examples: “B2: The Batch Size Queueing Principle: Reducing batch size reduces cycle time”; “F8: The Cadence Batch Size Enabling Principle: Use a regular cadence to enable small batch sizes”. Each principle gets a page or two of explanations; the diagrams are plentiful and helpful. (For an introduction to the topic, I still recommend Reinertsen’s book Managing the Design Factory.)

Embracing Commitment

Commitment is a powerful tool. [Originally published at InformIT.]


We often hear and speak of commitment. It's a term many people use, but it's a word with several different meanings. When you're clear about which kind of commitment you're asking for or using, you can connect to emotions, you can look for win-win benefits, and you can create reliable promises that others can build on.

In this article, I'll look at several meanings of the word “commitment,” at different commitment relationships, and at ways people assess or create commitment. I'll start with these aspects of commitment: attitude, motivation, hustle, and promise.

Commitment as Attitude

Commitment can be an attitude: an emotional state of attachment that puts the committed thing above other things; this commitment brings a sense of dedication. If you're committed, you're not working as a mercenary, committed only to the paycheck and not the cause. When you're committed, you care.

The software team was measured on the success of the project, but the project managers were assessed on the quality of their reporting. For the project managers, it was OK if the ship sank, as long as the sinking was properly predicted and the ship's log was up to date when it went down. People talked about teams being dedicated and committed to results, but nobody worried about the commitment of the project managers (to process).

Attitude talks about the emotional aspect, and that's notoriously hard to assess. However, if people don't care, the project has no chance.

Commitment as Motivation

Why do you come to work? What keeps you going on your project? What's your real goal?

Everybody has a different combination of motivations. For example:

  • Produce something someone values
  • Build something beautiful
  • Work with others we like
  • Work in a process we like
  • Look good to the boss
  • Program in Java
  • Build our resumes

As the last few items suggest, our motivation need not align with the best interests of the project or the company.

The team was based in two locations. One sub-team had developed a goal of eating at a different restaurant for lunch every day. They had spiraled out past 45 minutes each way. This was good for the sub-team's morale, but 2.5 hours or more lost out of the middle of the day was interfering with their productivity and their ability to work with the other sub-team.

Individual motivations may differ, but that's fine if they all point to the success of the project. If your motivation doesn't ultimately support the project's goals, you will weaken the project.

Motivation (especially shared motivation or mission) can serve to re-center you to True North, the direction your team is really trying to go.

Commitment as Hustle

What is the behavior of commitment? A sports coach may tell you that some teams have hustle—that extra bit of energy a team or individual puts in. A hustling team takes the extra couple of minutes to get things working and checked in before lunch. If something's due tomorrow, they'll try to get it done today just to be sure.

A team that's hustling may work overtime (a little, occasionally). Some managers treat overtime as the true sign of commitment. Bob Martin talks about a different sense of urgency: the 8-hour burn. This comes when you're working at such an intensity that there's no point in overtime; you're so “fried” you're likely to be more dangerous or useless than helpful.

It's easy to prefer the dramatic whether or not the drama is more effective.

On an early web project, the team had done much work to get ready, but had underestimated how hard the actual deployment would be. The team's manager later admitted that he loved the adrenaline rush of the two final all-nighters. He felt the team showed hustle, and he felt part of the team more than ever. (The team could have spent those hours over the previous months and skipped the drama, but perhaps the drama helped jell the team.)

Commitment as Promise

What is a promise? It's not a simple true-or-false proposition like “My car is yellow.” Is “I promise to give you a nickel” true or false? It depends on what I think, say, and do.

Speech act theory [Searle] [Winograd] is a linguistic tool that can help explain promises. The theory's key insight is that some statements create their own meaning: “I now pronounce you husband and wife” becomes true in the saying, if certain conditions are met.

What does it mean for a speaker to make a promise to a hearer? Here are some key conditions:

  • Both the speaker and the hearer agree on what is being promised.
  • Both sides believe the speaker has the time and resources to meet the agreement (even if not everything goes perfectly); neither is having private doubts.
  • Should problems arise, the speaker will put the commitment above other things, working beyond what had been expected to what is now needed.
  • If the speaker comes to believe the promise can't be kept, the speaker must notify the hearer as soon as possible, re-negotiate, and accept the consequences of failing to deliver.

A web of promise can form, helping a team work together. A series of kept promises builds trust [Solomon], and lets people worry less about whether others' jobs are being done.

Scrum has the notion of a Sprint Goal (though many teams don't use it). The team commits—promises—to meet the goal, rather than promising to complete a particular set of stories. This can open the door to creative solutions that meet the spirit of the sprint even if the exact plan isn't met. (Some teams frame the Sprint Goal as sets of stories: these are the things we promise to get done, these others are the ones we estimate will be done beyond that.)

If the Sprint Goal is in danger, Scrum defines Sprint Cancellation as a safety valve. It's ironic that Sprint Goals and Sprint Cancellation are often not used; the first is seen as too boring (“do the planned stories”) and the second as too dramatic (“launch a witch-hunt”).

Some teams make promises about what they'll deliver. Others make promises about their process (“A full day's work for a full day's pay” or “We'll use Scrum.”) Other teams make estimates, not promises.

Many teams have confusion about what they're doing; are they making an estimate (which can be wrong) or a promise (which needs a buffer)? Clarifying such ambiguities can go a long way to setting proper expectations.

Promises and Relationships

A plain promise is the simplest relationship: a speaker makes a promise. The structure is still simple even if the speaker and hearer participate in a web of promises, as long as there are no loops.

Mutual commitments create loops; most promises have a price. (“You give me $10 and I'll give you lunch.”) Mutual promises put leverage in the relationship. (“I'm not paying until you make me a proper sandwich.”) While explicit promises can be performed better or worse, there are sometimes tacit assumptions that cause problems if they're violated.

The Product Owner came in with a large body of work. The team said, “That's too much, but we can commit to this part (the most important third) in the time you're willing to allow.” The Product Owner agreed to that. The team hustled, and finished not only the promised part but about 50% more. They went in saying, “You're going to love this—we got lots more done than we thought we could.” The Product Owner said, “Yeah, that's great—but you only did half of what I wanted.”

The Product Owner had violated something the team tacitly expected—they not only wanted acknowledgment of the completed part, but “strokes” for the extra bit. They had exceeded their commitment, but were assessed against a promise that they had never made. (Do you think this team will hustle as much next time?)

Power relationships make promises even trickier. Managers are often in a position of both receiving and making promises to people: they receives promises in support of organizational goals, and make (often implicitly) promises about providing a supportive context. The supporting promises (or assumptions) may be things like, “I won't ask you to work excessive hours,” “I'll provide the tools you need,” “If things change radically, I'll take that into account.”

Finally, there's a surrounding promise from a manager that is also a threat: “If I'm not happy with you, I'll punish you or fire you.” The threat may be implicit or explicit; it's part of the structure of many employee relationships. When the threat is too close to the surface, the fear it creates can cause the very problems it's trying to prevent.

Signifiers and Manipulation

How do you know people are committed? You can't see attitudes or motivation; you can only see behavior. What signifiers do you look for? (I'm going to focus on a manager's point of view, as I've seen managers more explicitly concerned about commitment than team members, but anybody can have this concern.)

A manager sometimes tries to judge emotions by how people talk or their facial expressions. These are of course prone to being faked, “talking a good game.” That leads to a quest for observable behaviors. A manager may start looking for hustle.

Hustle can take the form of voluminous output, no coffee or web breaks, overtime, or constant typing. Any of these can be signs of intense working, but they can be faked as well. There certainly are groups whose hours are “just before the boss gets in till just after they leave, with the occasional midnight email.”

Explicit promises can help, but they're subject to manipulation as well. The implementer can provide something of low quality, either full of defects, or of poor design so it will be hard to extend. They can claim to have not understood what was wanted. (“We can do that, but you'll have to split the story this way and reschedule the rest.”)

Conversely, some managers feel that teams perform up to their capacity only when they're pressured: “What else can you fit in?” “That's not enough.” “Of course this story includes that; it was understood.” “Yes, that's what you promised, but I expect more from you.” In Peopleware, DeMarco and Lister warn, “People under time pressure don't work better, they just work faster. In order to work faster, they may have to sacrifice the quality of the product and their own job satisfaction.” Some teams can be pulled (inspired) by the right motivation, but can only be pushed (pressured) to compliance.

You can't see commitment. You can sometimes see behavior that suggests it, for example, promises kept. When there's a problem such as perceived low productivity, it's better to address that directly rather than assume that commitment is the issue.

Creating Commitment

Where does commitment come from? Sometimes the motivations line up: people have their individual motivations, but those are compatible with the overall goal, so they contribute to it.

Creating commitment is tricky—what are you trying to create? An emotional connection? High productivity? A culture of promises? Are you merely after the signifiers that make you feel better watching the team: a culture of appearances over actions, of busyness over productivity, of psychological pressure over trust?

The manager set up the planning meeting as a pep rally. He used sports analogies to describe the challenge as “the big game,” and had everybody sign a big poster with the ship date on it.

It may be that everybody was caught up in the moment. Junior people seemed to accept the challenge, but several senior people walked out muttering, “He's tried to hit these buttons before” or “That's an unrealistic schedule” but they weren't willing to speak up as that would be a CLM (career-limiting move).

A very similar scenario can have a different outcome: people respond to the challenge, they build an emotional connection to the project and the team, and they walk out jazzed up and ready to go.

What distinguishes the cases? There's no magic formula but these things affect it:

  • Does the goal fit higher aspirations? People want to change the world in some way, not just make shareholders richer. (They don't mind something that does both.)
  • Do people see where they can contribute? It's hard to be engaged if your contribution isn't important.
  • Is it the right level of challenge, not too easy and not too hard? If it's too easy, it's not worth the emotional investment. If it's too hard, people don't want to engage as they know they'll fail. (This is like the idea of “flow,” when challenges and skills align. [Csikszentmihalyi]) People often don't mind a little stretch.
  • Is it a free choice (free from undue pressure)? People want to be invited in, not ordered in.

What are the motivations you're encouraging? Extrinsic rewards (whether tangible, people-oriented, or special activities), or intrinsic motivation? The latter is more sustainable and self-reinforcing. [Martens]

Conclusion

Have you been caught in the trap of looking for appearances over results? Are you favoring drama and the appearance of busyness over actual productivity?

What sense of commitment are you after? If one party is providing estimates and the other side is interpreting it as promises, you'll have conflict.

Understand what you're looking for. Each type of commitment has its place. The right kind of commitment at the right time is extraordinarily powerful.

References

[Csikszentmihalyi] Mihaly Csikszentmihalyi.  Flow: The Psychology of Optimal Experience. Harper Perennial, 1990.

[DeMarco] Tom DeMarco and Timothy Lister. Peopleware: Productive Projects and Teams. Dorset House, 1987.

[Martens] Rainer Martens. Successful Coaching (3/e). Human Kinetics, 1997.

[Searle] John R. Searle. Speech Acts: An Essay in the Philosophy of Language. Cambridge University Press, 1969.

[Solomon] Robert Solomon and Fernando Flores. Building Trust: In Business, Politics, Relationships, and Life. Oxford University Press, 1993.

[Winograd] Terry Winograd and Fernando Flores. Understanding Computers and Cognition: A New Foundation for Design. Addison-Wesley, 1987.

Acknowledgments

Kevin Bradtke, Tom Kubit, Michele Matthews, and Doug Wake gave me valuable feedback and advice.

[Originally published Aug., 2009 at InformIT; republished here with their permission.]

Coach Interview: Alexey Krivitsky

Interview with Alexey Krivitsky; our discussion held June 1, 2008 at Agile Coach Camp in Ann Arbor, MI

WW (William Wake)- Alexey – To start, just take a minute or so and tell me about your background, how you came to be where you are today?
AK (Alexey Krivitsky) – I started as a developer about 8 years ago in Ukraine. I did some Java, .Net, Visual Basic. I quit that job; I had about half year to reflect on the years of my career. There were some books on agile on my shelf. One of them was Agile Software Development, first edition, by Alistair Cockburn, and some stuff about Scrum and XP. All these famous books… After finishing reading what I had, I thought it should work for me.

I found a job in a small offshoring company. The guys are from Denmark so they decided to set up a small team in Ukraine to maintain their software. They were quite flexible to change their process. By their nature they were a family business so they were willing to change anything and there was a guy who believed that agile can add value there. It was my real first experience with agile.

After that job I went working in Switzerland for a year.

What I'm doing now… I came back to Ukraine from Switzerland to set up an agile coaching business. Before that I had set up an agile community in Ukraine with about 200 people on the list, which is quite a lot, I think. I realized, "Here's an opportunity for me to develop myself in Ukraine," so I came back.

After about half a year, I realized that I was missing the real work. So I came back to my old team as a part-time Java developer. Now  I'm trying to combine being a coach and being a developer, which gives me quite the experience. I have a chance to see the problems from different angles.

It's quite interesting how many things you can change being a developer in a team, not a coach, not a guru, just from the inside of the team. You can affect a lot.

WW – Can you tell about one of the agile projects, either how they became agile or something that happened with them?
AK – When I was hired by these guys in Switzerland they had been running the project for more than half a year. They had people in Ukraine doing development. It was a chaotic project without planning. We just had to deliver something by a given day. I already had some Scrum experience, and I set myself a task to convert development to Scrum

Now I'd do it differently, but you learn from your mistakes.

I was at the client side. So I coached the Product team to define requirements in a more agile way, how to estimate, and all that kind of stuff.

WW – Did they work with monthly iterations, or what?
AK – They worked with 2-week iterations. We tried different durations and we ended up with 2-week iterations.

We didn't have a fully deployable version after each iteration. What we had is a demonstration server as it was quite difficult to do live production. At any time, the stakeholders could just log in and try it. We also had weekly demonstrations in which we presented what we had done so far to different stakeholders. It was our approach to agile which was based on Scrum.

WW – Are there any techniques, tools, or tips you have when you're coaching people?
AK – I would say I was a coach but it is impossible to coach people remotely. If you have somebody off site and you have to email or call, it's impossible to coach those guys. If you want to coach, you've got to stay with them and be involved with them.

WW – I'm interested in things you do, behaviors you have, whether you think of them as coaching or programming.
AK – I was at a position in my life where I stopped being a traditional team lead and turned myself into a ScrumMaster. It's hard to do, because you get used to proposing your ideas and believing that you're smarter than other people. Instead you have to start believing that the team can make up better ideas themselves. You make yourself stop talking and just ask questions. This is a hard thing to achieve.

When I coach teams now, I always ask questions rather than make statements. We also had a session today about skills, techniques, and questions – how to ask questions without any resistance.

So what I'm doing now is trying to help people go the way I think they should be going. It can be achieved by asking the right questions. Each time I have an idea which I believe the team should take, I just turn it into transforming discussion where I also have the chance to give my ideas. After that we just decide which way to go. They may have taken my idea or not, but we found something that should be working for them.

Another thing which I am practicing  is each time you are going to make a statement convert it to "What if you do it this way?" question.

Each time you're about to make a statement that can be taken with resistance, ask a question instead; it might help.

WW – What do you do to learn new things?
AK – We have an agile community – we organize conferences. It's a way for me to meet local experts and talk to them. I used to read blogs but I don't have that much time now. The conferences are the best investment of your time and money to learn something new. I will try to make the events in countries nearby. We'll see how it goes.

WW – Anything else you'd like to tell me about?
AK – I can tell you about the challenges of a coach in offshoring markets.

Developers in most cases are not interested in being agile; they do not see the values.

Neither is the management of the service companies – they do not care about efficiency. They care about the per hour rate.

The only right people are the product people. And they are far away

The outsourcing marketplace is quite huge, but there aren't that many agile people there.

WW – What do you find the biggest challenge when you're working with outsourced teams?
AK – The biggest challenge if you work on-site with the team is to make the client get this or get the customers to change the process. If you're a coach, you coach the team and coach the business people. It's hard to coach someone remotely. It's a challenge to coach teams to be more effective but it's only half the thing. The business people need to know how to manage requirements or releases in an agile way. There's no point in coaching just the development team.

It should be taken from two sides: somebody should be coaching the business side, somebody should be coaching the team.

I am looking for this kind of cooperation between US and European agile coaches.

WW – Thank you very much.
AK – I hope it was useful.
WW – I appreciate it.

100 Impediments

One of the most important things a ScrumMaster does is recognize and remove impediments.

This summary sheet includes 100 impediments (PDF) you may run into (though hopefully not all at once:).

I was inspired to start this list years ago from an article by Barry Boehm (which I've since lost and can't even find a reference for it).

I've found these articles that address impediments, and you may find their perspective useful as well:

[August, 2009.]
 

Coach Interview: Lisamarie Babik

Interview with coach Lisamarie Babik. Our discussion held July 29, 2008 at a cafe near Menlo Innovations.

Interview – Lisamarie Babik

WW – I’m with Lisamarie Babik from Menlo. This is July 29 [2008] after a great lunch.

WW – Give me a couple minutes about yourself and how you got to what you’re doing.

LB – My background actually is music, which is kind of funny. I’ve always found that there are an awful lot of people doing software who are music majors. I got to where I am through a long and winding course. I was a professional technical writer for a long time. I got out of that by taking the job that nobody wanted at my last company, which was being in charge of the software maintenance group. I did that so well I suddenly became the director of software development at this nice little software company in Southfield.

Then the whole dot-com thing happened and we had to start laying people off. Eventually it got to the point where I was the one being laid off. I was wandering around looking for something to do, and spent probably six months being unemployed and sending resumes everywhere. A friend got a job with Menlo, and so "Send them your resume! Send them your resume!" I sent them my resume and they invited me in for a day to go through the Agile Explained class, and frankly I just refused to leave!

I liked what I heard. It was so different and so fresh and so not-frustrating that I thought "I want to work in this place – I don’t care how long it takes. I don’t care what I have to do. Tell me to wash buckets and I’m going to wash buckets." I worked in the volunteer program a couple months before they ever gave me paying work. The first time it was as a developer and then they had me running the factory floor and doing some project management. I did that for about 3 years, and now I do mostly marketing and PR and coaching others within the factory. So I’m viewed as a resource that anybody can tap if they need advice on how to do things, or if they’re new in the factory and they’ve never done a planning game, or done estimation – they’ll come ask me and I’ll help out.

WW – Are there projects you work on as your own project?

LB – My projects I do are press releases and a lot of contest entry stuff, like we recently got a Sloan award for workplace flexibility. So I’m the one that’s responsible for doing all the writing.

I’m also working on "the book" that nobody can quite define what it is. So I do a lot of writing about what we do that doesn’t yet have a final form. That’s the majority of my projects. Then I get tapped in an extra capacity. Like this morning I was working on someone else’s project because they needed a High-Tech Anthropologist® for the day.

WW – Tell me about that job – what do you do there?

LB – High-tech anthropology®? "High-tech anthropologists® are highly compassionate, empathetic, and sympathetic people." Why I’m doing this job, I don’t know. [laughs] They’re specialized business analysts. They work with people, and make sure the software we design will meet their end needs. So it’s not defined by engineers, but by people like the people who are going to use it.

WW – Think of an instance where you worked on a team, something concrete where you helped them out with something or intervened somehow.

LB – We had a new project manager who was getting overwhelmed. We could see her boiling point rising, not that she was going to burst out in anger, but that she was going to burst into tears. That’s because she was so stressed by what was going on. So I took her aside and talked to her about the situation and what was going on, gave her some pointers about how she could handle the client that was being difficult, how she could handle the team that she didn’t know how to handle, and sent her back in. She handled things beautifully. From then on, she incorporated that, kept those lessons – she didn’t just do them once and throw them away. It was very gratifying for me to see that I had helped her grow.

I also will a lot of times play the part of the enforcer when I hear things going awry. [Someone will ask] a question like "Should we write a unit test for this?" and I yell "Yes, you should write a unit test!" from across the room. Or if a team is starting to screw around and I can see it’s affecting the dynamic of the team, I’ll sidle up to them gently and [whisper] "You’re disrupting everybody", to get them re-focused. They’ll say "We’re working – look, we’re writing code" – I’ll say "I was across the room, and you were disrupting me – I can’t imagine what it’s doing to the people next to you."

So, things like that.

WW – Think through the last 6 months – what was the best day you had?

LB – It’s hard to pick one out. Probably a really good day for me was the day I found out we made the Inc 5000 this year, because that’s a national recognition of who we are and of the hard work everybody in the factory is doing. Rich likes to spring those things on me, he kinds of keeps them to himself, till he can say "Guess what?" I got to have a big crow on the roof at all that.

Another good day was being able to come into the factory and work on my writing, and have a day when I’m really focused and have a great day of writing because of what’s going on around me. I can’t write in library quiet any more. I actually need the vibrancy of the factory going on around me to be able to write about the factory.

WW – Were there particular people who influenced you in what you do, or particular experiences that prepared you for what you do?

LB – Particular person with me – [P1], who was one of my bosses in my last job, and he’s just brilliant. When I got laid off, what I lamented was not the fact that I was leaving, I lamented that I was no longer going to have him as a mentor. Fortunately, throughout the years since I’ve left there, we’ve maintained a friendship and talk to each other through email. The funny thing to me is that though I lamented losing him, I got to know three equally brilliant people at Menlo, but brilliant in different ways.

[P2] has been a great mentor for me, in his own difficult poke-at-me-with-a-stick kind of way. It’s not a cushy, soft mentoring, but he kept me out of trouble. [P3] I look at more like a father figure that I can go to and say, "I’m having this problem and I’m not sure how to deal with it." He has a depth of business experience that despite my having been a director of development for two years, I didn’t get because he was at a much larger company than I was.

WW – Back to [P1] in particular – is there particular advice or influence where he helped you through – what made him that mentor to you?

LB – Probably the most brilliant thing he ever said to me was when I was thrashing – I couldn’t understand why the owners were making the decisions they were making, why my team was thrashing underneath me. I was having a hell of a time.

[P1] sat me down in his office, and said, "Lisamarie – the problem is you’re using logic. Sometimes when business makes decisions it’s not based on logic, it’s based on emotion." As soon as I had that I thought "Cool – OK – this isn’t something that I can necessarily fix – because when you’re thinking with logic, you’re thinking, ‘All I need to do is the right thing and this will stop’ as opposed to ‘Somebody is having a highly emotional reaction to this situation that I can’t control.’"

"All I can control is me." It was much easier to deal with that situation in the future.

I bring that up a lot with people — "The problem here is you’re using logic."

The other thing [P1] did was when I was director of development, I was responsible for the first round of layoffs. I had never been in that situation. I had a terrible time trying to figure out who of my team I was going to let go. These were guys that every day looked up to me, that were my friends. And I had to choose five of them that had to go.

Steven and I worked on that a lot and talked about one of the thing that was different from me vs. the others who were going through that process was that I actually cared about the people being let go. I refuse to use the word resource – these are people, not resources.

He kind of helped me soften [?] that experience so that I was able to learn from it and go forward, and never want to do it again, but I got to do it twice more.

When it happened the next time I was better prepared, because he had helped me become better prepared.

WW – Back to now – any techniques or things you do – "I should write a paper" or "I should do this again."

LB – I should write a paper on "story cards to run your life." I have a story board in my kitchen and it’s the only reason anything gets done at all. I got to the point where it’s what I need to order my life. I use them at work, and I always know what’s the next thing to work on. I use them at home and I always know the next thing to work on – I give them an estimate. Its great. I love it!

The other thing would be our High-tech Anthropology® practice. Just because the solutions we come to are so different and so well suited to the end user, that writing about that process as something that others could take and model is really important. We just haven’t had the time.

WW – Anything else you’d like to tell me?

LB – The only other thing I can think of off-hand is to tell you a little about my reaction the first time I was at Menlo. I had been through that class. It was not only an issue of "I’m not leaving" it was that recognition that after having thrashed at my previous job so long, it seems that there was a solution. These agile practices that Menlo was preaching at that time, and is still preaching were really it.

I’ve gone back and I’ve talked to people at my previous company – "Listen to me – there is a solution – you don’t need to be thrashing." Their response is "We don’t have time, we don’t have time."

I announced at Menlo at that first meeting that I wasn’t leaving and I was serious about it, and I’m still here 6 years later.

WW – All right – thank you very much, Lisamarie.

LB – You’re welcome.
 

Review – Teamwork is an Individual Skill

Teamwork is an Individual Skill, Chris Avery. Berrett-Koehler Publishers, 2001.
Chris spoke at the Agile a couple years ago, and I really enjoyed his talk. He explores many themes: teamwork, feedback, commitment, collaboration, trust. His perspective is that individual skills make these possible. Almost every section has personal and team challenges that give you areas to work on. Highly recommended. (Reviewed June, ’07)

ScrumGathering ’07

The last ScrumGathering was held in Portland, OR, May 7-11.

On Tuesday, Mike Cohn and I taught a course centered around a series of case studies. Wednesday and Thursday were Open Space sessions.

The overall site for the Gathering is here". This is the result of a session on Games for Scrum, along with a particular planning game, AgileTripTik.

I saw three themes:

  • How can coaches/ScrumMasters effectively intervene?
  • Leadership/vision "versus" self-organization
  • "Beyond iterations" – moves outside generic Scrum approaches

Using Actuals with Estimates

I work with a group that’s been estimating in pair hours for a while. We’ll describe a story, everybody will write their estimate on a card, somebody collects the estimates, and we make an overall estimate. (The tricky part is that an estimate needs to include the tasks that aren’t yet known but that will be discovered.)

We also track actuals. Whenever it’s convenient, but definitely at the end of each day, the pair adds its tick marks onto the board.

We’ve used a couple approaches to coming up with "the" estimate. One was to have the longest-standing team member propose a consensus number => not consistently right. Then we tried taking the maximum estimate => usually too high.

Now, we’re keeping track of who made what estimate. We compare estimates to actuals and decide who was the "winner" – the one with the most accurate estimates that week. When it’s time to do new estimates, we let that person hear all the estimates, and they make the overall estimate we record.

It’s too early to say how well this works. The same winner showed up twice in the first month, which may be an early indicator.

My estimates? I’m almost always too optimistic. So I’m going to pay more attention to how the winner thinks about our tasks.

ScrumGathering ’06, Open Space

The fall ScrumGathering is in Minneapolis, MN, this week. I’m here for the two-day open space and the trainer’s meeting. Groups are using http://scrumalliance.pbwiki.com as the conference proceedings. I’ll refer to those articles rather than repeat them here.

Product Owner – I hosted a session on challenges of being a product owner. We described various problems, and broke into subgroups to look at it from the perspectives of "patterns of product owners," "traps," and a "values/principles/practices framework."

Planning a Long Project, hosted by Kelly Weyrauch. We defined a long project as lasting more than a year, and considered a variety of issues that affect planning. Two key challenges are "dealing with changes in scope" and "being absolutely clear about how much is left to do."

Being a Manager, hosted by Jens Ostergaard. Looked at things managers do: remove impediments, set goals, coach/help with individual development, encourage innovation, provide resources/environment, block for the team. But the most important thing is to provide vision.

What is business value?. Hosted by Joe Little. Value to the customer versus benefit to the business. The Kano model – mandatory, linear, delighters. Value vs. cost.

Write a product backlog, hosted by Mike Cohn. We took a couple examples and broke them into stories. Mike talked about using the expected implementation cost as a driver for whether to make stories bigger or smaller. He also described using the back of the card to record conditions of satisfaction, high-level acceptance criteria.

Scrum for non-software applications. We identified a number of areas that use or can use Scrum. Then we explored some challenges and potential solutions for problems they might face.

In the afternoon, we did some closure exercises, to identify important areas going forward and to turn the energy into accomplishment.

I joined the Leadership group. We decided to survey scrum masters and trainers about how leadership is presented as a topic in the courses, to create a resource list of books and articles, and to gather success stories of people on Scrum teams who demonstrated leadership.

I had a fun couple of days, and took away some inspiration, some ideas to try, and some ideas for new articles. It’s always feels good to re-connect to the community.

Alistair Cockburn on Bottlenecks

"Two Case Studies Motivating Efficiency as a "Spendable" Quantity", by Alistair Cockburn.

A bottleneck limits the rate of production of a system. Clearly we want to improve its performance. But what should we do about non-bottlenecks? Alistair discusses several strategies, including the non-obvious one that the non-bottleneck may be better off deliberately spend extra time exploring alternatives before feeding into a bottleneck. He points out that there’s no single strategy that always works; it’s context-dependent.