
You might not expect to encounter the "delegation" concept in a blog post about agile software development. After all, agile is all about the "self governing team." But in the real world, if you are in a company which is transitioning to agile, and you are the project manager of a newly created agile team, you may well need to consider how to create a situation around your team that allows self-governance to emerge without making you completely crazy. In real life, your first few weeks with your agile team can seem like your worst nightmare. This is not because there is something wrong with you. This is completely predictable. Stop blaming yourself.
If your team is used to having you, as a project manager, take all the responsibility, and you suddenly stop telling people what to do, (along with not setting up their meetings, not taking their notes, and not getting them a projector every single time for every single meeting), you should not expect them to do what is needed, no matter what the Agile Founding Fathers say. Instead, your team members, being humans, will go ahead and take advantage of you and do whatever they feel like doing. And remember, they are under a bunch of stress themselves with this whole "agile transformation" thing, so you're not seeing them at their best.
<more>


In the glory days when giants still walked the earth and the Agile Founding Fathers created "the team," they decreed that there would be three "team roles:"
The product owner would be omnipresent and omni-knowledgeable, the scrum master would (somewhat mysteriously) "move boulders and carry water," and the team itself, the AFFs explained, would be "cross-functional." Without being told how, the team would just swarm around the work and get it done: analysis, design, development, testing, release, the works. Boo-yah!
<more>


As you join your teammates in your sparkling new agile team room, and you all do your best to quickly "become agile," I guarantee that despite being surrounded by brightly colored index cards and sticky notes, you may sometimes feel...angry. Here you are, supposedly liberated to be "self managing," out from under the collective thumbs of your corporate hierarchy, and you realize that you are reminded briefly of the Lord of the Flies.
<more>


Product Ownership is very difficult. Take a big step away from the Agile Manifesto and think for a moment about project stakeholders, user stories, and how they don't fit together as neatly in real life as they do in Mike Cohn's User Stories Applied, as awesome as that book is. How in the world is it possible for there to be a single person standing in for all project stakeholders in negotiating with the team?
<more>


As a trainer, I have noticed that when I start the "Roles, Personas and Goals" discussions, attendees in the room are 40% more likely to start surreptitiously checking e-mail their smartphones than they when we talk about comparatively exciting topics such as "stand up meetings," "story boards," the "burn up versus burn down chart" debate, or "evolutionary design." I had to lure you to this blog post, in fact, by riding on the coat-tails of the Breaking Dawn, Part 1, premier tonight at midnight. You aren't interested! You have heard it all before! "To write good software, you need to know who will be using it and what they want to accomplish." Blah blah blah--sounds like something your mom would say. "Give the roles names, and think of them as people. If multiple types of people play the same roles, give them different names, and call those things 'personas'" Now you sound trendy and slightly unhinged. Let's go back to the burn-ups.
<more>

Log in if you have an account.
Otherwise, register for an account.
For more details, please visit the How This Site Works page.