Busy is not productive

Often, I am asked to help teams that are not accomplishing their goals.  The team insists that everyone is working hard and always busy.  They feel that the problem is in the requirements, schedule or demands of management.  Their customers and management feel like they are not getting what they want out of the team.  If the team is busy but not delivering enough value, what is happening?

Almost certainly the team is not using value-based metrics.  They are either working without measuring progress or using self-serving metrics like velocity or utilization.  A team can work all day but unless that work furthers a customer or business objective, the work is not productive.

If your team is busy but not perceived as getting the job done, reconsider how you are measuring work completed.  Be sure to include some kind of value metric. In the best case you can tie directly to business objectives like sales, conversions, margin or new customers.  If your lead time or delivery cycle is too long, consider asking your product owner or stakeholder to score stories on business value.  Measure points velocity but also consider business value.  If you are completing a disproportionally high number of low business value stories, consider your iteration mix.  Make sure to include enough stories that the business finds valuable along with those your team values (like tech tasks or tech debt remediation).

Being busy is not inherently a bad thing, but busy and non-productive is bad for morale.  It usually results in the business asking more from the team, leading to long days and death marches.  Always be prepared to demonstrate the value of your work to the business and adjust accordingly.  A team working fewer hours productively will be valued higher than a team working hard and accomplishing little.

=Kevin

Change is hard – pace yourself

Organizational change is hard.  In fact, any change is hard.  Whether it is successful or not, people are more comfortable with what they know and asking them to do things differently can be difficult.  When businesses adopt a program of change, they do not do it lightly or without purpose.  That said, they often engage in a program of change without really understanding what they are changing or why.  It is simple to believe that if what we are doing now is failing, doing something different will be better.

Today, many enterprises are looking to agile software development as a solution to slow releases and stagnating technology.  The belief is that agility will produce more software faster at lower cost.  While fully embracing a culture of agile innovation can achieve that result, the journey is long and difficult.  Often, organizations take on too much too fast and lose sight of the business goals or problems they are trying to solve.  These change programs are overwhelming and can lead to worsening problems and a retreat to the practices that, while know to fail, are comfortable and familiar.

A more pragmatic approach to transforming a business is to examine why change is desired and address the biggest problem first.  Focus on solving for one major business goal before moving on to the next.  This way, the business can consciously change to the appropriate level of agility and innovation for its culture and market.  Continuously evaluating the effectiveness of changes relative to business goals will give leadership the tools to decide how much to move forward or when to change course.  The cultural changes will have tangible value, giving the execution team something to rally around and feel proud about.

Change is hard, but with a focused plan it can be manageable and successful.  Change takes time, but measurable progress builds confidence and makes it easier.  Change can be frustrating, but understanding why it is happening will energize the team.  In the end, successful change is fun and rewarding for everyone involved.

Let’s cut the enterprise some slack

Dear Agileists,

We have an opportunity to get it right this time.  The next round of enterprise agile transformations is under way.  In past transformations we expected a lot and were disappointed when things did not change fast enough.  The constant pressure and criticism put a sour taste in the mouths of the people we were trying to help.

After some time away and more overdue waterfall projects they are trying again.  This time can be different.

The Agile Manifesto values “Individuals and interactions over process and tools”.  This usually gets applied to breaking down heavyweight waterfall processes and replacing them with Scrum or XP or Lean.  We get upset when they want to include some upfront planning or governance or post-release testing.  A hybrid process can meet the needs of the organization while still delivering valuable software quickly.

This time let’s iterate to success.  Let’s keep the things that work and stop the ones that don’t.  Let’s focus on the result and not on the process.  And let’s cut the enterprise some slack.  This is a big change that they’re trying to make and we are here to help.

=Kevin