‘Tis the season for ghosts, goblins, and cute children dressed up as princesses and vampires seeking treats. Halloween is the time to delight in all things creepy and crawly! An Agile coach, however, sees scary things year-round. Eeek!
Here are a few of the scariest things I’ve encountered and what can be done about them.
Phantom Product Owners
The Product Owner is a key role, especially when it comes to getting great value from the team’s work. “Phantom” Product Owners are either so far removed from the team as not to exist or sometimes hinder rather than help team productivity. They may have some or all the following tell-tale signs:
- They are so busy – haunting halls unknown – that they are often or always absent from team meetings and daily work.
- They don’t work well with the team due to being absent from meetings, where decisions need to be made.
- The team or organization has diverged from good Agile practices and has policies or rules that exclude full participation by the Product Owner. This further encourages absenteeism, strengthening the Phantom PO’s powers of invisibility.
- The PO, despite being an active member of the team, does not actually have decision-making power. As a result, it takes much longer to get answers to key questions or remove obstacles obstructing progress. Like a phantom, such a PO is powerless to make an actual difference in team productivity and output.
Luckily the antidote capable of reverting a Phantom Product Owner to a human one is written directly into the Agile Manifesto, which states that the business and the Product Owner, as the Voice of the customer, must work together with the delivery team daily. In order for delivery teams to deliver actual, customer-visible value Sprint after Sprint, the Product Owner must have full decision-making powers. If your organization is guilty of empowering such PO behavior, seek ways to cut off such Phantom limbs.
Franken-Agile
Dr. Frankenstein didn’t mean to create a monster; he just thought he could do what nature does. The monster didn’t mean to be evil, it just ended up that way.
Sometimes our clients and indeed our own Agilist selves think we know better than the creators of Scrum or other Agile frameworks. That somehow our situation is so unique that the “generic” frameworks won’t work for us. Little do we know that these frameworks were created out of many years of experience, trying things this way and that way. When we pick and choose parts and pieces without the commensurate experience, we may be, unbeknownst to even ourselves, creating a monster. Franken-Agile is the too-often result: a patchwork Agile shell held together by Scrum tape and Lean glue that, under close scrutiny, wouldn’t pass the sniff test.
Every client situation is unique. However, knowledge and experience are required to understand how to alter and remix Agile frameworks to match your needs. Start with the known instructions first. Over time, after you understand enough about the basic principles, the changes they imply, and their effects, you may decide to change a little here and a little there, guided by much hard-won experience. In the end, you’ll end up with something that serves you well and that you won’t have to put down for fear it’ll destroy everything you’ve tried so hard to create.
Imaginary Agile Standard Monster
Sometimes a company has decided to “go Agile” to make the leap to “faster” productivity. Naturally, they start this change effort the way things always start: with a complete plan and fully documented Agile SDLC. This new Agile standard is created from the imagination of well-intended people without the experience of using Agile in the company. Once published, it becomes the Agile Standard that everyone must follow. Born out of good intentions (and we all know what road that’s used to pave), a monster document is created, one that blocks and consumes ideas and innovation before the organization has even learned what they really need.
Having an Agile SDLC is not a bad thing. Having one that cannot or is not easily changed is a monster. Your standards document should be a plant, not a monster: start from the seed of your initial understanding and build upon that. Start with just enough to get started. Grow your Agile Standard as you would use Agile to develop software, incrementally and iteratively, informed by learning and regular reviews. That way you’ll create something that supports you instead of something that blocks what you really need.
Treats, Not Tricks
Scary things at this time of year are meant to be fun. Scary things in your company culture and processes are not fun any time of year. Seek to understand the problem you are solving and the tools available to you. And seek a guide, a “vampire hunter” to keep you safe from the monsters we encounter and sometimes accidentally create on our Agile journeys.
