Oh the joys of not being in the grind. From this position I get to see all sorts of stuff about doing â€œAgileâ€ right. Primarily from a Project Management perspective. But, Iâ€™ve got a secret. Itâ€™s one of them there plain-sight secrets that turns out to be how successful teams get things done. To us plain language folk, we call it â€œTalking to each otherâ€. But, since that will never work in consultant speak, weâ€™ve got one of them there fancyish names for it. Wanna hear it?
Wooo Doggie! Doesnâ€™t it sound grand?! But those two words, thatâ€™s the secret to making your team agile! How do I know? Itâ€™s right in front of our noses.
Letâ€™s look at Scrum. What is Scrum? Well, we stick all our work in a Product Backlog. The Product Owner manages it. The team meets every sprint (usually 2 weeks) to take the next highest items off the backlog. We meet every day to answer three questions. We track our work in a burndown chart. We demo what weâ€™ve completed at the end of the sprint. We reflect on what weâ€™ve learned before our next planning meeting.
Do you do those? This isnâ€™t one of those trick questions. What I mean is that, if your team adopted Scrum, itâ€™s because you all looked at a book â€“ or online â€“ saw that as a blueprint, talked to each other and agreed to do that stuff. In other words, your team has an explicit policy to do those things. What things?
- We agree work is managed by a role called a Product Owner
- We agree to meet every two weeks to determine what the next highest priority items to be worked on are
- We agree to demo every thing weâ€™ve completed every two weeks to the customer
- We agree to meet every day to get a sense of where we are and where we are going
- We agree to use a burndown chart to estimate out if weâ€™ll be done by the end of the sprint
Those, folks, are explicit policies. Youâ€™ve agreed to them as a team. Turns out, explicit policies are a key part of Kanban as well:
- We agree that we will measure the cycle time of work through the system
- We agree to limit the work-in-progress at any one time
- We agree to meet every week to let the business reprioritize and replenish the backlog queue
- We agree to demo as much work as weâ€™ve completed every two weeks
- We agree to meet every day as a team
And then some team-specific ones:
- We agree that when an item is blocked we can go one over our WIP limit for that queue
- We agree to swarm on test items when the WIP limit has been reached
- We agree to write acceptance tests before writing code to increase flow
- We agree that bugs can be fasttracked through the system, and can violate existing WIP limits by 2
Explicit Policies â€“ the agreements of the team are actually what makes any agile method successful. Yes, Lean thinking helps. Yes, XP practices are vital. But the team owns the process. And if you arenâ€™t talking as a team â€“ and yes, as an organization â€“ it ainâ€™t gonna work. Like the one time by cousin Billy and my other cousin Billy were wiring up a moonshine still and Billy said he was gonna pour the grain alcohol and the other Billy lit a match so they could see in the woods. It was fun for a brief second, but then you end up without any eyebrows and people just know.
So there, now you know. You want to know if your manager can add stuff mid-sprint? Talk about it. Want to know what happens if you test-last? Talk about it. Try it out. Run experiments, and know what results you are looking for. It is the heart of Individuals and Interactions over Processes and Tools.
And if you see your Aunt â€“ I was never here.