The best work?
Key idea: How do we know our Agile teams are getting the most important stuff to work on?
It seems to me we have the theory that, magically, “the users” will always ask us to work on the most important things that we could possibly do.
So, let’s parse this a bit. The users might be the business or management or the customer, and the best work might be the most important thing we could do, or the most valuable or the highest business value, etc.
OK, so as soon as we make transparent the hypothesis we can see at least four holes:
- The users are always human, and almost never can identify the highest value things, even for themselves. Consistently and reliably.
- Identifying the highest value things (product, project, story, etc.) is, in large part, cost-benefit analysis. Only if the decision maker has complete understanding of all the benefits and all the costs (risks), can she or he make the best decision. If we technologists don’t tell the business folks about the costs, how can they possibly give us the best stuff?
- Do you know what you are really capable of? For sure, most business guys do not know what technology is really capable of. And, specifically, they don’t know what your Dev team is capable of.
- Are we technologists capable of keeping up with all the extensions inherent in existing technology? Or keeping up with technology innovation? No. Even less can the business guys do that.
How do we fix this mess?
The issue here is that, although we are doing important work, we are still “failing” to some degree if it is not the most important work at the moment.
I will suggest we need to get business and technology people together more, and the technologists need to ask, “How could we be more sure that we are getting the best, most important work to do, so we, together, can make the greatest possible contribution around here?”
There are about 250 business days each year. I bet there are 250 ways to phrase that question.
Subscribe to this blog
Interested in a Lean-Agile-Scrum course or Workshop?
- Agile Advice – Mishkin Berteig
- All about Agile – Kelly Waters
- Brad Appleton's ACME blog
- Brian Marick's blog
- David J. Anderson's Blog
- Esther Derby's blog
- Hal Macomber's Lean Project blog
- Henrik Kniberg's Blog
- Implementing Scrum – Mike Vizdos
- Net Objectives' Blog
- Organizational Agility – Pete Behrens
- Partnership & Possibilities – Diana Larsen
- Rachel Davies' Blog
- Scrum Log – Jeff Sutherland
- Steve Denning at Forbes
- Succeeding with Agile – Mike Cohn
- The Lean Agile Executive Blog
- Tom Peters blog
- agile business
- Agile principles
- Better Agile
- business value
- BV Engineering
- Change Management
- elements of agile style
- Getting started
- Jeff Sutherland
- Key problems
- knowledge creation
- Lean Software Development
- Little's Law
- Little's Second Law
- managing agile
- Nokia Test
- People issues
- Recommended reading
- Release Planning
- Scrum Intro
- Scrum meetings
- Scrum roles
- ScrumButt Test
- Yogi Berra