Written by Dean Stevens Saturday, 18 May 2013 08:32
I’ve been noodling on the phrase “Thinking Together”. Thinking Together is one aspect of the mindset that Product Owners need to embrace. I have been using this phrase with new Product Owners to explain why many Agile practices work. But each time I start to write about this simple idea, it gets complicated because I get into process steps and roles and responsibilities.
Yesterday, I returned to a big company with a pretty complex product portfolio where we had done quite a bit of work including starting up multiple Scrum teams. I recalled our first release planning with this group. There was a lot of uncertainty and even some anxiety about this “lightweight” approach.
They were missing their requirements and specification documentation. They were hesitant to assess the value and size of the features, concerned they might leave something out. I prepared a Release Planning agenda for them to follow. I also prepared a list of roles and responsibilities. And I had some one page cheat sheets on the activities for release planning. They needed some process rules initially to learn how to think together.
When I ran into a Product Owner from this big company months later, the changes they had made were obvious. He was facilitating release planning and was excited to walk me through it.
My friend the product owner brought me into the conference room where they were wrapping up their release planning. There were some product managers, the product owner, some tech leads, QA and even a project manager. They were taking a break chatting and smiling. There were some architectural sketches on the white board. There were four flip chart sheets with sticky notes representing epics and features. The flip chart sheets represented the work completed for the past release, the plan agreed to for the next release, and planning for the following release. They had one more sheet with parking lot items.
The product owner showed me the result of their Thinking Together. They had discussed the epics written on blue stickies and wrote all the features they might need on purple stickies and put them under the epic. Then they thought together some more and rated each feature with business value, complexity and sizing. They added some acceptance criteria and clarified assumptions as they went. They did this for several epics. Then they started adding features to the flip chart sheet representing the next several releases.
Now, they realized they would not get everything done that the product managers wanted. So they moved some lower value features to the parking lot and rearranged the features on the flip chart sheets until they agreed on a plan. By Thinking Together in planning the next couple releases, they pretty quickly learned together and gained a shared understanding of the work they would do for the next six months.
They had learned to Think Together to get the end result: a solid release plan.
Join the conversation.
Written by Mike Cottmeyer Wednesday, 8 May 2013 04:04
Hey everyone… I’m out in Vegas this week at the Scrum Gathering. Got invited to speak… which was really cool (thanks Daniel Gullo)… and did the most recent iteration of my Agile Program and Portfolio Management deck. Take a look and let me know what you think!Join the conversation. There are currently 2 comments.
Written by Jayne LaFave Monday, 22 April 2013 10:53
LeadingAgile’s very own Jesse Fewell will be a speaker at tomorrow night’s PMI Atlanta Technology forum in Alpharetta, GA. Check out the following link for more information:
Jesse will stick around to answer all of your questions about LeadingAgile. We hope to see you there!
Join the conversation.
Written by Mike Cottmeyer Wednesday, 3 April 2013 05:38
A lot of folks in the agile community feel like projects and project managers are a big part of the problem we have delivering software. My view is that projects are not really the problem… it’s projectized organizations that are the problem.
Projectized organizations form when we have people organized into functional silos and assign them as necessary to project work. The underlying assumption is that people are fungible resources and can be split indefinitely across projects to get work done.
Agile methods take a different approach. People are organized into cross-functional teams and focused on a product… or a set of features… or a component… or a set of services… within the larger production ecosystem.
Projects as a funding vehicle in most organizations are just fine. The shift in thinking is that projects have to be broken up and funneled through teams. Each team is responsible for a subset of the project deliverables with integration happening on regular intervals
I’d much rather integrate the work of many teams producing working tested features than try to integrate the activities of many individuals working within their own particular speciality. Done is easier to see and bottlenecks are easier to identify and resolve.
This is the #1 biggest problem we see with organizations trying to adopt agile. They do not have a pattern for organizing teams and managing project deliverables across teams. Until this gets sorted out… you are not likely to have much success using agile at any scale.
Written by Jesse Fewell Monday, 1 April 2013 08:53
I’m really excited to announce that I (Jesse Fewell) will be appearing TOMORROW for the latest PMI Agile Community’s Tweetchat. The topic is “Intro to the Agile Mindset”. We will all be on Twitter TOMORROW, April 2nd at 12pm EDT (Eastern US). The hashtag will be #pmiagile and I’ll be tweeting as @jessefewell with some commentary by @leadingagile.
Some of the proposed questions include:
- Q1: What is an Agile Mindset? #pmiagile
- Q2: How do I adopt an Agile Mindset? #pmiagile
- Q3: What barriers are there to an Agile Mindset within organizations? #pmiagile
- Q4: How does an Agile Mindset impact teams? #pmiagile
- Q5: Is Agile the same as Scrum? #pmiagile
Hope to see you thenJoin the conversation.
No events scheduled at this time.
If you want people to stop gaming the numbers, stop making the numbers a game
Working without a plan may seem scary. But blindly following a plan that has no relationship with reality is even scarier.37Signals Rework
When you don’t know what you believe, everything becomes an argument. Everything is debatable. But when you stand for something, decisions are obvious.37Signals Rework
The core of your business should be built around things that won’t change. Things that people are going to want today and ten years from now. Those are the things you should invest in.37Signals Rework