I keep telling my development team to take ownership, but they just won’t!
Frustrating. They’re good people, but they just don’t take action when it’s needed. You keep telling them to list actions to take when there’s a production incident. They’ll just sit and wait if nobody tells them to fix it. They complain about the other teams responding slowly to their demands, but they just won’t take ownership and call them up by themselves.
Sounds familiar? Let me put on my telepathic hat and take a shot at what your situation looks like.
- Your team sometimes complains about stories that haven’t been refined ‘enough’
- Some stories can’t be included in a sprint when certain specialists (e.g., testers, DBAs) are on leave that sprint
- The Sprint Review meeting is primarily a demo for a couple of stakeholders; if the guests have any questions at all, they are directed at and answered by the Product Owner
- Team improvement level progress is measured by the percentage of Velocity increase over time
- Your Product Owner or Scrum Master seems to be the only one who cares about resolving issues
- Retrospective meetings are mainly complaint sessions; there never is a follow-up on action items from previous sprints
- The whole Scrum Team is hardly ever complete at any given Scrum event
- They’d better rename the Daily Scrum meeting into the “Twice-A-Weekly Status Update” meeting
- Work is pulled from the backlog when a developer has finished working on ‘their’ stories
- Jira is the tool your team uses for their stories and reports
Telepathic hat off. How did I score? 6 out of 10, maybe?
These things aren’t causing a team to be passive. They are effects of the same thing. Let me ask you a couple of questions before I tell you what ‘that thing’ is. Maybe you can guess.
- Is anyone outside the Scrum Team keeping track of bugs in Production for your product? What do they use this data for?
- Does your team need anyone outside the team to release ‘Done’ Backlog Items to Production?
- If a team member wants a day off, who do they discuss this with? Do they ask HR and tell the team, or do they ask the team and tell HR?
- When a major incident is discovered, are the teams in charge of resolving the issue, or does an architect, ‘Epic Owner’, or any other manager get assigned to fix it?
- What kind of questions does the Product Owner receive from the developers during refinement meetings? Are they usually about technical requirements or how an end user perceives the feature?
- When was the last time your developers met with actual end users of your product? What did they talk about?
- Is there some company directive, or is your team free to choose what tools they’d like to use? How many stickers do their laptops have, or are they only allowed the white sticker with the laptop number and bar code on it? How about sprint length?
- How many features that are based on initiatives from team members made it to Production?
- How proud are your developers of themselves when higher management uncorks champagne to celebrate the twice-delayed Big Release with them? (Sorry, but no, they’re not. Yes, they told you they were because you wanted to hear that. That’s just what you wish for them. Ask them again. When the bottles are empty. Then ask them why it is that they’re not as proud.)
Do you see where this is going? Okay, maybe one more question. Just for you.
- If your field of real influence is limited to the formatting of your code (if even so!), how much ownership would you take?
Not only that: how much could you take? If most of the time you aren’t empowered; if most of the time your initiatives vanish like smoke in the wind; if most of the time you just have to do what others tell you to; if you get rewarded for things outside of your control and punished for things you have no say over; then it’s really difficult to keep fighting for it. Frustration looms if you do.
So what can you do? How do you make your team take ownership?
Just start by giving them room! They’re highly educated people who don’t need petty rules. Stop smothering them. Trust them to learn how to do their work best because they can and because they want to do that anyway.
Let the team make errors, and allow them to learn from them. Don’t worry about production issues so much. They’ll fix them. And they’ll make sure they won’t happen again. Besides, are you trying to say there are never any issues in production now? While you have all these mandated tests, rules, and standards? You can’t be serious.
The team can have great ideas for your product too. Let them try things out. Let them speak directly with users of your product. Not just for the fun of it but also because they need to know how real end users use the product so the team can build better things for them and build them right. More people happy, more happy people.
So help your team by enabling them, not by ‘telling’ them. You’d be amazed about the energy unleashed when a team takes ownership if you’d just let them.
