Links
·
RSS Feed
Popular Pages
 |
 |
Jared Richardson’s talk titled “Build Teams, not Products,” in particular, was one of the best presentations I’ve ever witnessed. It was just one of those talks where all the points seem tautologic...
-Yev Bronshteyn |
 |
.. it is a really special feeling when you give someone a book and it changes the way they think and act. So I'm really pleased to have just finished reading a book that I know I'll be handing out ...
-Jeffery Fredrick |
|
With much code, all eyes are shallow
-Jared Richardson |
|
|
|
|
(Dec 4)
It's said that the road to hell is paved with good intentions... and that describes far too many "agile" adoptions. I've seen managers take money out of bonus pools for every broken build (in a continuous integration system). Another client tied raises to points and velocity. A vice president of a large organization explained to me that the teams doing agile should be faster than their counterparts, even though they had all the overhead of both agile and waterfall, with no freedom to reduce or change the work focus.
Agile practices are intended to be flexible... they should be fluid... liquid, if you will. Instead they're sometimes frozen and turned into clubs. Like any tool, they've only been as good, or bad, as the person wielding them.
More than a few developers have come to hate "Agile" because of how they've experienced it. Far too many have seen the word agile used to justify abusive practices at the hands of managers and executives who viewed agile as just another tool to extract more work out of their teams. That's not why agile was created and it's not particularly good at it either.
Agile becomes weaponized in several different ways, but two of the more common ways are one-sided implementations or frozen practices.
One-sided agile is easy to spot. Those companies use agility to provide more transparency and visibility on the activities of the development team and then continue poor practices (especially micro management) that negate any benefit of agility within the organization. Management (and project management) groups use agile as a tool, but don't adopt the practices themselves. Agile practices provides a great deal of visibility into the day to day lives of the development and testing teams, but that visibility needs to be a two-way street. The visibility can't be only into the technical team's work, but must also be into the executive vision and motivations. When "agility" means the teams adopting agile practices but management continues to work as before, issuing edicts from behind the curtain, then agile practices are being abused. This is a dysfunctional relationship. These agile adoptions flare up briefly and appear to be going well before flaming out. One-sided agile adoptions don't stand the test of time.
Frozen practices are also easy to spot. When iteration velocity is used at a tool for rewarding and punishing teams, instead of measuring working software, then you know your company is on the wrong path. When managers assign work to a teams instead of the team committing to their own work for the iteration, you're operating under a command and control mindset. The product developers (aka product owners) fail to attend demos or provide feedback, but later complain about the finished product and blame the teams. When the teams are forced to "sprint" over and over, and are being pushed for more and more work each time, it's an efficiency tool, not an iterative development model.
You're facing frozen agile clubs anytime an agile practice is used to justify punishing or blaming a team instead of empowering them, instead of tightening up feedback loops and directing the product focus. It's often an excuse to avoid putting in the hard work needed to ensure the team is moving in the right direction. It's easier to not fully engage, then blame development. Again.
Remember the original points of the Agile Manifesto... individuals and interactions over processes and tools. Especially those processes and tools that eliminate human interactions in favor of dictated orders. Use your agile adoption to encourage those interactions. Yes, they are "inefficient" from a time perspective, but those inefficiencies are more than recovered by eliminating many of the common misunderstandings that occur when we replace face-to-face communication with written documents. No matter how many pages you add to a requirements document, you can't the reach the level of understanding that comes from an interactive discussion. The document is faster, but the conversation is more effective.
The intention of the GROWS Method Practices is to ensure that practices won't be frozen. Practices begin with steps and advance to freedom. Try using the practice cards to help start those conversations.
If you think your company is in the midst of a weaponized one-sided agile adoption, I'd encourage you read over the Executive practices. Walk through the Vision and Progress Management sections with your manager. In my experience, many managers are doing their best to manage the work, and they're falling back to what they learned in years past. Give them a cleaner way to manage teams that involves a company-wide agile adoption and a true change of the culture and mindset all the way to the top... and you might find yourself understanding why some people enjoy agility so much.
Category: Agile
|
|
|
|
|
