Don’t Motivate Your Staff to Cross Purposes

Don’t Motivate Your Staff to Cross Purposes

I believe that establishing a culture is the most important thing in making world class software. And, I believe that establishing the company’s vision and getting everybody pulling in the same direction is paramount to establishing culture. Most companies never do this. It’s easy to test, just ask two people what the company’s vision is and see if you get the same answer. Likely, you will not. In reality, this should be a stop-and-fix issue, but it’s so endemic to our culture that we only do such tasks after we’ve crashed and burned and bring in the consultants to tell us why. It’s cultural debt, and it’s as crippling as technical debt.

An outcome of not having a single vision is that since we don’t have a shared vision, we motivate different groups of people in different ways. These people will never pull in the same direction. Success will be erratic at best. Recently, I was talking to one division’s engineers. Let’s call them Teams A. They were supposed to launch on a Friday, but found one bug, and since that was against their Definition of Done, slid the release until the bug was fixed. This took one day, and they released on Monday. This slip was inconsequential as their software is a large and complex suite, and most of their customers wait years to update, even though the team is now releasing every month.

Another division of the company, let’s call them Teams B, owns software that the customers want as immediately as possible. These customers would take monthly releases, but this team just moved from yearly releases to six-month releases and does not have a CI/CD pipeline. With three sprints to go, they had 300 bugs, but were sure they would close them. Unfortunately, on release day, that had grown to 1100 bugs, including that the version could not be installed! But they released "on time," and began planning their fixes.

Guess which team got bonused? If you guessed the team that released non-working software on time, you would be – sadly – correct. On top of this, Teams A’s manager found out that the Product Owners are bonused by how many features they can pack into a release. So now you have three groups of people being focused on different legs of the iron triangle. Teams A is focused on quality, and will give up their bonuses to do the right thing. Teams B is focused on predictability, although one could argue the only real thing you can predict about them is low quality “on time” release. The business isn’t focused on either of these things. They are focused on scope, and driving teams to be feature factories, as if all features were the same size, complexity, and business value. It’s like counting clouds to predict the weather.

The things that happen as a result of motivating people to work on cross purposes like this are predictable. Overall low morale. Teams focused on the right things seen as failing. Teams who hid their problems until it was too late seen as successful. Product owners not having any idea of the business value of their requested features. Customers perpetually disappointed in the quality they receive. After a while you will get new management, with new initiatives, who still never align the workforce around common goals, and the situation repeats.

If you want to be world class, look at your culture. Establish your vision. Look at how you motivate your teams. Are you motivating them to pull in the same direction, or are they all working on different things? Is everybody working towards the same goal, or are they cross-motivated? Once you have a culture with a firm vision that everybody is motivated to make happen, then you will have the foundations for world class software. Until then, the problems you solve will not be the root problems and the changes will not stick.

Clearly SAFe is the answer. ;-)

Justin Sykes, CSPO, CSM

Agile Software Development | Product Manager

7 个月

Sadly, I had a manager once that was so focused on predicability that they developed a reputation for delivering no matter what with an extreme work ethic. They became very skilled at negotiating around (known) bugs and differences in opinion regarding planned features in order to receive necessary release approvals for on-time delivery... no one worked more hours than this person (to my knowledge) nor pushed their teams equally as hard. They ended up getting promoted rather quickly as result of this...

要查看或添加评论,请登录

Jon Tobey的更多文章

  • Cyber Monday Special: Free Bulletproof User Story Template!

    Cyber Monday Special: Free Bulletproof User Story Template!

    Better requirements gathering through User Stories in 500 words or less In my series on story mapping, I made the…

  • Metrics that matter

    Metrics that matter

    People are forever asking me for Agile metrics, and are rarely satisfied with my answers. This is because most…

    5 条评论
  • Story Mapping for Agility, Part 2: Making it Agile with Business Value

    Story Mapping for Agility, Part 2: Making it Agile with Business Value

    Typical project management measures projects in time, budget, and scope. There is a lot of value placed on following a…

    4 条评论
  • Does your value stream map reflect your Agile values?

    Does your value stream map reflect your Agile values?

    I love value stream maps and think they are fundamental to any business transformation, especially an Agile one. Like a…

  • Story Mapping for Agility, Part 1: Escaping Scrummerfall

    Story Mapping for Agility, Part 1: Escaping Scrummerfall

    Agile is what we are, Scrum is what we do. Edited by Jay Quibodeaux Be sure to read part 2, Story Mapping for Agility…

    1 条评论
  • The Fallacy of Bottom-Up Agile Transformation

    The Fallacy of Bottom-Up Agile Transformation

    Neither I personally, nor anybody I know, have ever seen “bottom up” transformations work in corporate America. If your…

    2 条评论
  • How Agile Estimation is Like Brewing Beer

    How Agile Estimation is Like Brewing Beer

    A brewer friend of mine asked me what a story point is: Imagine a user story is a beer recipe. We are designing it to…

  • Six of One…The ABC Game

    Six of One…The ABC Game

    Transitioning to Agile is as much (or more) about how you think as much as what you do. Often, we get trapped in what I…

    2 条评论
  • Fundamentally Agile: Why is Closing Sprints So Important?

    Fundamentally Agile: Why is Closing Sprints So Important?

    In waterfall, we commit to (or have commitments made for us) delivering on time, within budget, and a to defined scope.…

    1 条评论
  • Fundamentally Agile: Output/Outcome

    Fundamentally Agile: Output/Outcome

    fun·da·men·tal forming a necessary base or core; of central importance. Often when I start a new coaching engagement…

    1 条评论

社区洞察

其他会员也浏览了