Archive for category enterprise

It’s an Agile Sabotage

agile sabotage
Agile adoptions in the Enterprise are difficult and complicated, perhaps that is why I often read stories on Top Down vs. Bottom Up techniques. I feel as though we focus too much on these and overlook the Middle, which can lead to disaster.

Middle management is arguably the toughest obstacle in any large scale Agile adoption effort. This is most apparent in situations where they’ve repeatedly fired people below them to make ends meet. An environment like this does not exactly foster job security and yet middle management becomes adept at navigating the murky waters of office politics. Anything new and disruptive in nature such as Agile, is generally not received well.

Top down Agile adoption is the way to go, you must have executive buy-in!

In a top down approach, one would assume that mandates from above would be followed within reason. However those in middle management can seriously hinder an Agile adoption by sheer incompetence or worse, sabotage. Unless your top down approach has eyes from above keeping tabs on things at the day-to-day level, there is a good change middle management will screw it up.

Grass roots Agile is the most rewarding, and you’ll be a beacon of success for the rest of the company!

With grass roots Agile, one would assume that your successes would be recognized by the executives as you deliver value early and often. However more often than not, those success stories are reported up the chain by middle management, not by the worker bees themselves. Middle management can craft the message as they see fit when sitting down to update their superiors. I’ve witnessed people take credit for work they did not even begin to understand and massage the communication to further secure their job. It happens every day.

Middle management can make or break your Agile transformation.

I recommend that anyone stepping into the Enterprise do their homework on middle management. While your Agile efforts may have a three pronged attack on the top, middle and bottom of the organization, I suggest burning significant calories on the middle. Spend one-on-one time with them and try to understand their background by asking them how they achieved their status within the organization. Gather insight into their personality, and their thoughts on new techniques or ideas. When on site during the transformation, make it a point to be involved with their day-to-day activities to address any fears they may have.

In conclusion, don’t get too wrapped up in Top vs Bottom and overlook the Middle. Your Agile transformation may just fail as a result.

Tags: ,

Sizing Up the Enterprise

As teams begin to estimate User Stories, they may explore different approaches such as T-Shirt sizes and Fibonacci sequences that stop at 8 or go much higher.

This freedom to choose a relative sizing style allows a team to adopt what fits well within their work environment.

While this flexible approach is quite useful at the grass roots team level, it does pose an interesting challenge in the Enterprise setting where Agile teams roll up into an Agile PMO.

How do those in charge of the overall strategic planning, make informed cross team decisions with Product Backlogs of such varying size criteria? How can they identify the features that involve the least complexity, effort and doubt coupled with a high return on investment?

scrumology.net agile pmo sizing

Before we go into my suggestions on how to address this, let’s explore a common fallacy that is being evangelized in the Enterprise today.

Mandating Story Points to Ideal Days Solves Cross Team Sizing Inconsistencies

“1 Story Point = 1 Ideal Day (6 hour work day)

Seems quick and easy doesn’t it? Mandate that all of your Agile teams conform to this and your problem is solved!

By doing this, however, you’ve inadvertently stripped the Story Point of its original intent while roadblocking your team from personalizing (and humanizing) the process. You risk dismissing the conversations about complexity, effort and doubt while focusing on the mythical 6hr work day.

Another unintended side effect of tying Story Points to actual hours is that it isn’t long before people make the dangerous link between Story Points and Budget.

So what is the silver bullet to this issue? As is the case with all things Agile, there is no silver bullet! Solving this issue depends on the nature of the Agile teams and their relation to the business within the Enterprise.

Are these teams separate business units within the organization, or do they all contribute to the same product?

If the teams each have their own role within the organization and are only loosely tied to the same business goals, my suggestion is to let them be for the most part. Sizing, and especially Velocity, does not translate well across teams or up the organization. It will be an apples to oranges comparison, and you should keep your eye on delivering business value. As long as your teams are collaborating by sharing their Release Plans, does it really matter if they use a T-Shirt size or a Fibonacci scale as a means to an end?

If the teams do happen to roll up into an overall product, then I suggest that sizing occur from a single Product Backlog before decomposing them into each Team Backlog. With this approach, you can have the overall strategic conversations early. I would much rather have representatives from each team weigh in on a single Product Backlog, than try to make sense of it from the bottom up. This also brings a consistency to the sizing while allowing each team to have flexibility at the Sprint Planning level.

To summarize, tread carefully when trying to apply consistency across Agile teams within the Enterprise. It may not make sense to mandate sizing techniques, especially if it causes more harm than good.

Tags: , ,