“Being agile is about business sustainability. It’s an approach to work that lets an organization respond to changes in its environment – customer needs, market fluctuations, new technology, competitor moves, resource constraints, whatever.”
Communicators get that. We pay attention to the business environment. We’re also familiar with change, since most of what we advise on or write about has something to do with something new.
It’s about change
“Since every part of the business uses computers, change can’t happen without systems changes. Even great communication can’t compensate for crappy tools. But developing systems can be slow and expensive and, sometimes, by the time you’re done, the target has moved and more changes are needed.”
Heads nod. Everyone’s witnessed this.
“So, some people figured there had to be a better way to build software and make change easier – and “Agile” was born.”
Then I tell them about the Agile Manifesto and its values. Most of them love, “Individuals and interactions over processes and tools,” since putting people first and actually talking with them is high on a communication value list, too.
At this point, I’m itching to explain scrum and kanban and standup meetings and iterations and . . . but I know eyes will glaze over if I push too hard on the “New Ideas” button. So I pull out some stickies, introduce them to Lean Coffee and they try not to interrupt each other.
It’s about the team
I was looking for a good metaphor to explain how an agile team works when, in a recent learning session* I played the role of the newbie Product Owner and was reminded of life in a TV newsroom.
No reporter creates a story alone. An assignment editor generally suggests a story to cover. Reporters collaborate with a camera person and, often, a video editor. Together, they decide what will go into their item, what’s important and how it will fit together.
On an agile team, the product owner is like the assignment editor. He or she represents the business and decides what needs to be built. Developers, testers, analysts and others work together to make it happen.
In daily news, deadlines are short, a few hours between assignment and airtime. Stories are short, too. A reporter might handle two or three stories in a day. Similarly, in agile development, bundles of function are small (they even call them “stories”) and deliveries are frequent. The difference is in the definition of “done.” A TV item is done when it hits the air. Software actually has to work. Still, just as news stories can change, over time, as new information is learned, software is refined as new needs emerge or new features are added.
It’s about the customer
In a news show, the topics are varied, drawn from the events of the day and the news team’s view of what the audience (customer) wants to know. (Trust me, viewers are not shy about calling in and telling them how to run the show.) In agile software development, someone from the business side (customer) is right there on the team, determining what gets covered.
Whether we’re building software or building a news show, the key to success is a team that shares a common space, shares a goal, shares ideas, shares information and shares the workload. Communication – especially interpersonal communication – is an essential ingredient to make that happen.
*The session was at Communitech’s Agile/Lean Peer2Peer group. Chris Chapman, of Derailleur Consulting, had us play with the idea of “no estimates.” But that’s another story, one that Chris tells better than I ever could.