Manifesto Musings #4: The Communication Factor

So I was reading this post on Medium, "The Trouble with Scrum". As these things do, it started a bit of a mental chain reaction, leading to this tweet from me:

I feel like Scrum is hard because communication is hard, and most of us have been, at best, not well trained.

Just a quick look at the Manifesto (never mind the Scrum Guide for now) highlights this. Have a sloppy able because blogspot doesn't seem to have an easy way to make them:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Well, how do you know you've satisfied the customer? You have to talk to them, and get them to talk to you. Shouldn't we leave that to the experts in marketing and such?
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.That means not just communication, but constant, close communication. With CUSTOMERS. How do we even DO that?
Business people and developers must work together daily throughout the project.Whoa.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.GIVE them things? SUPPORT them? More talking!?!?
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.Right, we got that. But who gets training in how to talk to people? Not talking at them, not sending memos or emails, but actually talking to them. In person.


And then you bring the Scrum Guide into it, with its list of rituals. And really, my only beef with Scrum right now is that it is far, far too easy for people to conclude that doing the rituals means that they are "doing Scrum"." The rituals themselves -- and I do like that word -- are forms. They have only the content that the team provides. If that content is shallow, if the communication is not genuine, then the rituals are useless.

If everyone shows up to the daily scrum and answers the three questions while looking at the floor, or their phones, or they make up an answer that they think is kinda sort accurate but isn't really, then the scrum has been technically observed but hasn't accomplished anything.

What is has been, is a lot easier than fully engaging with the rest of the team. We did it and got out without wasting too much time, and now we can go back to our desks and be productive (or go to another meeting). That collaboration stuff is hard, and emotionally risky, and all kinds of other things that we are not as a rule taught to be good at in the course of our working lives. But it's all that other stuff that makes Scrum effective, when it works. A 16-page manual can't give you that.

Comments

Post a Comment

Popular posts from this blog

Handling Meetings with Remote Attendees

This is the third session in my brown bag series. It's not an "agile" topic really, but it was one of the things people requested a session on.  I hoped that people would bring their questions and be willing to discuss them. There were four topics proposed, and some conversation although it was mostly people in the room. Here is the outline:  Day before, set up a Trello board as an option for people to raise topics and added a link to the invitation. Recruited a co-pilot who would watch the WebEx chat and bring up anything that came in through that.  Five minutes before the session, dial in to WebEx, start camera, ensure that screen sharing is set up and the projector is working.  Noon - official start time. 
Read more

Agile Transitions as Self-Sustaining Reaction

Weird confession time? I used to be a little dubious about the long-term role of coaches and even of Scrum Masters or equivalent in an Agile organization. Once you’ve taught people the rules, what else is there to do? People are smart, and Agile methods as a rule aren’t complicated. I wondered—how could it possibly take more than a year or so to get this thing going? Then I spent several years observing an Agile transition from its initial push phase through to a kind of equilibrium, and I have gained a different understanding of the roles and the process in such a transition. I’m going to call these roles Primary Agile, because their work centers on fostering agility— and nothing else . Agile transitions can be thought of as something like a chemical reaction. The system starts in one state, and by adding some ingredients and – most importantly – energy, the system changes into a different state. For most organizations, that end state is going to be very different from whe
Read more

Shu Ha Ri Skeptic

Last year it seemed like I couldn't turn around without hearing someone talking about shu ha ri and its applicability to Scrum (it was usually Scrum, probably because other Agile techniques are less ceremonial). There's a good summary here . Although I don't practice martial arts, I do meditate and practice yoga, which I feel gives me a way toward understanding how the idea is supposed to work. When you first start practicing, after all, it takes all of your attention just to get into the poses or to glimpse a moment of still attentiveness. Why you're supposed to do a specific pose or follow a particular sequence won't fit in there until you've been doing it for a while, until the physical part has become automatic. That said, something about that metaphorical connection, about the idea of "just do the Scrum ceremonies as prescribed, and why will come later" didn't sit well with me. After a fair amount of rumination I've finally identified wh
Read more