Peter’s presentation was to me a direct segue from my observations on Leffingwell’s presentation. It was about make programming fun again, to motivate people so they get to that next level where you are looking forward to Monday, to delight your colleagues with the best you can do, where colleagues are friends, where you work hard and play hard. “Have fun!”
His argument is that we need to focus on the long game but not forget the short game.
“Just in time planning, definition, estimation and design are good but people need to understand the roadmap”
So when teams don’t see the long picture teams will be make decisions to account for this uncertainty. That reminded me of “shared vision” that Jim McCarthy talked about: with it you can make short term decisions and align yourself with the long term, have a north to your compass.
Add a personal perspective that gets you excited about “changing the world”. That brings me a reflection on being part of a team, an organization, which provides value to society. Are we helping people be happier, better themselves?
“Tools are important, but not the most important.”
I talked at length about this on my talk at Scrum.org Face to Face, and it seems to be a recurring theme on this ALM Summit. We concurred that “peoples and interactions” are the substance of bringing motivation back to the team. “Tools should be supportive to the process”. If the tool gets in the way, if it brings you pain, if it takes fun of what you are doing then there is something wrong (for those in the Pulse team: Peter is a program manager in Visual Studio/TFS – feel free to send me a summary of your pain, and I will send it to him).
Peter then moved to talking about “Simplicity doesn’t mean stupid”:
“Just Barely Good Enough==the most effective possible
Apply this rule to everything in your project, team, tools & artifacts”
This point by Scott Ambler is better understood by looking at the following diagram:
Listening to Peter talk about this is very convincing about the value of this principle – however, I also respect Rebecca Wirfs-Brock as one of the pioneers of Agile, when Agile was not even called that – and she argues the opposite: http://wirfs-brock.com/blog/2006/09/29/barely-good-enough-doesnt-cut-it/. I will need to think more about this one.
“Beware Unintended Consequences – your team will react to anything that hurts or scares them”
As an example he mentions the expression “don’t break the build!” – developers will react to that (“no one wants to have a toilet seat or crocodile doll in your office ” by imposing restrictions on themselves (check-in less frequently, check-in bigger chunks, which lead to big merges). It should have been stated “You broke the build? OK, but fix it immediately”. Why the short phrase? Because the earlier statement was just too big, “Don’t break the build” is easier to remember. And scare. Another classical example of this are metrics – use them wisely and for your own understanding, because the moment you try to drive motivation based on metrics the team will contort their behaviors to satisfy those instead of focusing of having pleasure from shipping something new.
Well my take on his idea is to think about what the unintended consequences of rules. If they bring the team down, then recognize, think about them, and change them – don’t let them spoil the team motivation because of tradition and legacy imposed on you.
Then Peter talked about Dan Pink’s ideas about motivation, which he summarized as:
· Autonomy – Empower and trust people to make decisions
· Mastery – Give your team members the opportunity to improve and grow their craft
· Purpose – Show them the big picture and their place in it
Funny is that Eric Weber had talked about the same ideas in his presentation (“Scrum and Drive”) during the Scrum Face to Face meeting. And it seems a running theme across the minds of Agile thinkers.
Finally he talked about “Outcomes are more important than processes”. What I understood from this is that at the end of the day, we should think of ourselves not as “cost centers” (especially if you are in IT) but as “business differentiators, as contributors”. It is not nice to be considered from the outset as a burden. Motivation goes down from there. Why stick with this tradition dictated by process when what matters is to motivate people to the next level of excellence?