Scaling Scrum – Team Ownership

I’ve been practicing the Product Owner role at a large fortune 100 company, on a program that has massive potential.  One effect at a large fortune 100 company at least, is that bodies get thrown at it.  In the course of not even a year, we’ve gone from 3 Scrum teams to 11 Scrum teams, 5 Scrum teams not in the same building, plus a customer support team, a massive dev-ops team and an operations center.  Wheh.  Plenty to discuss here in future blog posts.  Let me know if scaling scrum issues are of interest to you.

Today I’ll keep it focused at the team level.  Take this situation: Team A works on a specific feature for a few sprints.  Something new pops to the top f the backlog which Team A is uniquely qualified for, and they suggest going for it next sprint.  They talk with Team B and product ownership and everyone agrees that Team B will pick up the remaining work on Team A’s feature and make a few enhancements and add a few new features. I would suspect this is a common occurrence in large programs.  Probably sometimes in command-and-control ways (listen up people, we’re going to re-org these teams to work on different things….)  But even in a good self organizing system, this can create issues.

What responsibilities does Team A have to Team B while Team B is working on the codebase Team A originally created?

The perfect world answer is that Team A is responsible for knowledge-share, a few Q&A sessions, and nothing more.  Team A has left their codebase in good shape, with low technical debt, and plenty of artifacts that explain what’s going on and how to get work to done in this particular codebase.  They’ve showed their working software every few weeks and been transparent about what’s done and what’s not.  Team B has all the necessary skills needed to turn backlog items related to this feature into done software.  Team B does all the design, coding, testing, etc, etc, etc needed to produce done increments.  They rely on Team A only for the occasional question and explanation.  In the perfect world, both Team A and Team B can make progress simultaneously.

In the real world, this probably isn’t the case.  There is likely going to be significant drag on both teams for quite a long time.  Mangers like to call this a “transition period.”  Developers and teams like to call this “hell.”  The teams will fight over the state of the codebase “you’re handing this crap over to me?!!?!” and quarrel over getting help “can’t you just spend a few days [doing our work for us]?!?”

Scrum will make this very, very apparent (this is a good thing!)  It will not fix this for you.  (what’d you expect?)

As a manager, you want the team to own their work, even if they didn’t create it from the get-go.  A team that is whole-owner of their work is a team that learns.  They are a team that is solely responsible for quality.  They are a team that has all the power to create great products.  You want this.  Don’t get sucked into the short-term tactic of having “all teams help each other” and having alot of cross-team dependencies and other teams to parts of features or parts of development, etc.  It’s a short term tactic that optimizes the struggling team at the expense of all teams.

It’s not an easy choice.  It takes courage and vision to wait while a team struggles for a bit to find its way.  But it will.  It will learn and organize and grow and come out the other side all the better for it.


The Software Weatherman, Part 2.

Many people would answer my questions in the software weatherman, part 1 with a “yes, go for it” and many people would say “nope, not worth the risk.”  I’m not sure there is a right answer on the surface.  Perhaps it will be OK to risk it and perhaps not.  But if you are at all concerned with wasting the extremely expensive paint by taking this risk, you probably don’t go for it.

Software is developed in a similarly risk environment.  Software is painted in the outdoors, if you will.  You have to be concerned with such inherently unpredictable things as the weather.

This is good news.

If you work with your business to understand how software is created and how features grow into a product, you will create a shared understanding of the complex, creative, and at times unpredictable process of creating software.

The more they understand this, the more they understand the environment in which you create software, the more honest you can be about forecasting the work.  The business / your Product Owner / your customer already knows that they have bought some extremely expensive paint, and you can bet they do not want to waste it, or risk having something not be done and done right.

With this context in place, you’ll find it orders of magnitude easier to have those tough schedule/budget/scope conversations with stakeholders.  Your job is software weatherman, forecasting the project in an environment of uncertainty, more sure about the next day’s weather than the next month’s,  and treating your estimates as nothing more than a forecast.

Now, this doesn’t mean you are off the hook.  Even a rookie weatherman can predict the weather with some certainty.  They know it’s cold in winter and hot in summer.  You as a software weatherman have the responsibility to forecast in at least the same way.  It’s not acceptable to your stakeholders to hear things like “there’s no way to know” or “we all used the infinity card in planning poker” or “it’s so complex and there are too many unknowns.”  Even a rookie software developer can tell if something is a week or year worth of work.  Step up, and in the context of giving forecasts, give one!  You will modify it later as you learn more, do a little work, and re-evaluate.

If you’re business understands the environment in which you create software, they will behave more wisely.  You will see commitments and must-haves and multiple #1 priorities shift into ordered backlogs and agile roadmapping.  Give it a try.  Go explain to your business partners how you create software.

The Software Weatherman, part 1

You are about to embark on a project to paint your garage.  You have all the needed prerequisites to complete the job, including a very high quality and extremely expensive paint.  This paint is so good that it promises a lifetime warranty.  The instructions on the paint can are simple and clear: While in 60-90 degree temperatures with no rain, apply one coat, let dry for 12 hours, then apply a second coat, let dry for 12 hours.  Simple as that.  It’s a weekend warrior project for sure.

The weekend is nearing and you flip on the weather channel to see what the weather will be like.  Currently there is a high of 89, a low of 61, and a 20% chance of rain.

Do you commit to having the garage painted by the end of the weekend?

A little more time passes, and the weatherman now says there is a high of 83, a low of 66, and a 10% chance of rain.

Do you commit to having the garage painted by the end of the weekend?

Ok, it’s Saturday morning, and now there is a high of 87, low of 63, and 2% chance of rain.

Do you commit to having the garage painted by the end of the weekend?

Agile Yearly Dinners

Throughout my career  I’ve always been in an environment that implements the “Annual Performance Review.”

[insert your own horror flick sound effects]

There is a swath of articles and blog posts on the evils of stack ranking, pay for performance, annual reviews, goal setting, etc.  I’d like to share my thoughts on an alternative, something I’ve always thought was a better alternative, but have only personally experienced in recent times.

The Agile Annual Performance Review Yearly Dinner:

Step 1: Put something on the calendar a year out from the employee’s anniversary date.  Let the employee choose a restaurant at which to meet.

Step 2: Give the employee face-to-face feedback all the time during the year.

Step 3: Meet for dinner once a year, and do not conduct a review.  You won’t have to on account of Step #2.   Watch how happy everyone is.

Things that are conspicuosly missing:

  • Evaluation forms, or even the word evaluation.  Instead, you may have used 360 degree evaluations, notes from clients, and written or verbal self-reflection from the employee.
  • Any sort of ranking or number assignment.  You’ll never again have to speak that corporate BS about how “3 out of 4 is a great ranking!”
  • A checklist of personal goals.  Annual, individualized corporate goal setting is dead.  Instead you may talk about what was learned over the past year, how the employee learns best, and what you can do to foster play and experimentation.

Things that this assumes:

  • Employees are already paid well, and motivated by more than just salary.  Salary talks are a non issue, and short conversation at the annual dinner.
  • Corollary: Employees know when and how salary increases are done at the company.  If they are not alongside the employee’s anniversary (all raises are done in January, for example), then you ensure they know that.  And they know how the salary increases are calculated – hopefully based on company, team, and individual performance.
  • You as a manager are willing and capable of executing on Step #2.  Giving feedback is an art.  You must individualize your approach and tailor it to each employee.

I’ve found this personally gratifying and a whole lot less stressful than the previously dreaded annual performance review process.  I hope more people and companies come to appreciate this method.

Final thoughts: Don’t forget to pick up the check at dinner, you cheap bastard!