I like the scrum process for helping to align development team members on what is important and
making daily contributions towards the sprint objectives. I was reminded by this by the following quote I read from Peter Drucker.
The executive who wants to be effective and who wants his organization to be effective polices all programs, all activities, all tasks. He always asks: “Is it still worth doing?” And if it isn't, he gets rid of it so as to be able to concentrate on the few tasks that if done with excellence will make a difference. - Peter Drucker
I have been thinking about this throughout my career for ways to implement a management system that helps to align the high level goals and objectives into tactical actions. I typically feel that management sets nebulous aspirational goals that rank and file employees have to independently dissect and hope they are aligned; or that they just ignore. The ideal state is that management goals (policies) can be decomposed and cascaded down to the front lines; such that everyone can feel they are working on the right things in the right order.
Start with strategic planning (Hoshin Planning). What is the vision mission and key metrics of the organization. What are the stages of development to achieve this (MVPs) play catch ball to break down the mission and metrics into tactical deliverables or MVPs. Break the MVP into features. Break the features into smaller
milestones. Create stories. Prioritize the stories into what are the
important things to accomplish or figure out.
Create the backlog of stories.
Rate and identify the stories.
Plan out sprints of two week periods to keep the team focused on a few
things and then add more work as the stories are completed and update the
backlog with the learnings or rework needed to make progress. Tie the progress back to the Hoshin Planning metrics and take actions accordingly.
The benefits of this
is it really focuses the team to work on a few things and deliver on tasks that
make the most impact. Also if there are
technical risks it helps to ferret out problems early. This gives the team faster feedback on what
paths will yield fruit and which are dead ends.
Expect and plan "Spike stories" to de-risk and test
assumptions.
I came across a
great story about how successful problem solving depending on learning quickly by
quickly trying different ways. This was in a fantastic book by Eric Barker: Barking up the Wrong Tree. Teams can
get stuck in talking and debating to not waste effort and resources; however,
many times it is just a kind of procrastination. A good approach is to jump in and start
trying things….
Here’s an example. It’s called the Spaghetti Problem. It’s a pretty simple challenge: build the tallest structure you can that will support a marshmallow. It has to be freestanding and your team gets eighteen minutes to do it. You get these tools: 20 pieces of dry spaghetti 1 meter of tape 1 piece of string 1 marshmallow Peter Skillman (who has the awesome title of General Manager of Smart Things at Microsoft) designed it as a creativity exercise. He ran the challenge for over five years, testing more than seven hundred people, including groups of engineers, managers, and MBA students. You know who outperformed everyone? Kindergarteners. Yes, six-year-olds beat everyone. (In fact, the MBA students were the lowest performing group.) Did the tykes do more planning? Nope. Did they have some special knowledge about Italian food or the consistency of marshmallows? Nope. What was their secret? They just jumped in. Like Wiseman’s lucky people: they just tried more stuff. They started failing immediately—and learning quickly. This was their system: prototype and test, prototype and test, prototype and test—until the time was up. When there is no set path, this system wins. It’s an old Silicon Valley mantra: Fail fast and fail cheap. Research shows this method of trying lots of little experiments to see what works best also works for people over four feet tall. Like you and me.
Barking Up the WrongTree - Eric Barker
Comments