Tag Archives: BA

Are commitments the only way?

Have I told you folks lately how much I appreciate the answers I get here? I mean I’m grateful, and feel all warm inside, but also, I just really love reading them and learning what agile looks like in different places, for different people. I learn so much from you! So, if I haven’t said so lately (or even if I have), thanks.

So, last night, Justin @searls lit up twitter with this:

Agile friends: anyone out there still believe the “agile commitment” is worthwhile? My writing wants your (starkly opposing) viewpoint.

Later, once the conversation had taken off, he added this:

an agile team guesses what they can accomplish in an iteration, commits to it, and submits to ritualistic beating upon failure.

On the subject of commitments helping with trust, Zach @zspencer said:

Promises that are kept help. Promises that aren’t don’t.

To which Justin replied:

success is never certain, or commitment would be unnecessary. You’d recommend a team risk promising an uncertain outcome?

Wow. Big conversation. And there’s a question coming. First, the part where I ramble. :)

Are promises part of life?

…I don’t typically make promises. I have intentions, and I share values with people. I care about them having what they need to be happy, and I care about me having what I need, too. I love collaboration and I love getting things done. That’s something I want. But it seems to me a promise would mean I’ll do something even if I don’t want to, even if something changes so the original plan won’t work. Or even if I was wrong about what would, in the future, be possible (or a good idea).

If I “promise” to finish something by Friday, and I don’t, it may well be because I choose to do something else rather than finish. For example, maybe it took longer than I thought, and I valued getting some sleep and taking breaks more than finishing, for example.

Maybe I chose to organize my collection of e-books instead of working on the project.

Would a promise help with that?

If I did choose to organize files instead, we’d have a problem that’s not about promises, and not about Friday. It’s a problem the moment I lose interest in the thing we both want to create. Maybe it’s too hard (I feel stuck). Maybe I’m not engaged. Maybe I don’t have the tools I need. Maybe the environment at work is so pressured that I can’t think. A good retrospective might help us figure out what’s really going on.

But if we’re on the same side, you know that we both value what we’re working on together. Maybe in a particular case, “you” means a manager or business owner, and “me” means a developer. We share an agenda, a devotion to something of value, and we work toward that at a pace we find, not just sustainable, but exciting, interesting, productive. We work out a shared intention, and then watch what happens.

People often tell me I don’t really mean that I don’t make promises, so let me be really clear. My spouse and I don’t make promises to each other, either. If one of us were unhappy, neither of us would want that person to stay. No promise is required when we’re both doing what we value.

So that’s me. I would really like to know how promises and commitments look in your work. (I don’t mean to bombard you; there are a lot of questions here, but I’d welcome an appreciate an answer to one or two that jump out at you.)

Here’s what I’m wondering…

Do you use commitment on your agile projects? What do you mean by commitment? What happens if you “break” that commitment? What causes the commitment to be broken? What are the consequences?

How do you build trust on your teams? Or between your team and the business?

Have you found a way to work — successfully, in the world — without commitment? What does that look like? What changes when you work that way?

What’s the BA role on an Agile team?

I went to a talk last night about the role of the BA, by Mark Price of Pillar. Here’s the impression of BA that I came away with.

First, Mark highlighted four of the 12 Agile Principles as being people-focused, and the area of influence of the Agile BA. They are the ones around:

  • Collaboration
  • Inspired People (Motivation & Trust)
  • Face to Face Conversation
  • Self-Organizing Teams

Specifically, what I heard him say was that the BA coaches people toward collaboration, including helping the customer be a real part of the team. The BA also understands intrinsic motivation, factors that influence communication, and how to shepherd small groups through Tuckman’s stages of group development, and toward real flow.

Let me be really clear here. To me, that describes the perfect job. But I have this nagging question that comes up. And maybe it’s the Fundamental Agile Question for me at this time: People pay for this? Really?

What’s the most important thing the BA does? Have you worked on projects where the role wasn’t filled? Is it considered dispensable, fluff, unnecessary expense? Or is it important for an Agile project’s flow?

GeePaw sez…

Short answer: yes, Angela, they pay for it. :)

Long answer: I’m not sure I would call that description a BA. It sounds more like just a coach. Certainly, my practice is focused around these actions at least 75% of the time. The rest of the work, usually a handful of technical problems, is, for me, the easy part.

The software industry is almost entirely captive to fear and failure. This produces a remarkable range of social pathologies.

Jerome Bruner once remarked that the role of the psychoanalyst is to help the patient find a story that allows her to become who she wants to be. That’s what a coach does, too. My most important activity, over and over again, is in bringing the group mind and the group heart to bear on the daily work life.

(Are these answers too weird or disjoint from their questions? Just re-ask me, and we can try again.)

Well, ok, but then what’s a BA, Mike? Just a domain/tech translator?

Well, no one on an agile team is “just” anything. Agile roles are very loose and floppy, like bunny ears.

BA’s can start as domain-tech translators. But the good ones quickly realize that the answer isn’t to spend your time writing down business procedures as if they were flowcharts, it’s bringing people together to solve problems.

I’m an external consultant, so I always start looking for a coach-after-me as soon as I arrive. The candidates — I’m saying 90% here — fill one of two “informal” roles on the team. One is the domain experts, be they called BA’s or SME’s or whatever. The other usual suspect is the #2 geek. (Not sure why.)

Hope that helps. But if not, I’m going to give it a rest, and let our so-far *awesome* comment-squad help us out.