Agile Growing Pains – Making the product owner role work in a fast growing enterprise
Posted on February 12, 2010
Filed Under Articles | Leave a Comment
From my organization’s Product Owner land, we have many people participating in the individual tasks and requirements of the Agile Product Owner role from an engineering and product management perspective, but, no one person has taken it on, nor has the organization fully figured out how to embed the role. I keep scratching my head about why this is so hard, but clearly, it has it’s challenges. Internally, I view this as a process lifecycle and growth social artifact. In our process lifecycle, we’ve adopted Scrum, we are agile in our engineering execution efforts, we do release planning (note to self, this is another blog I could go off on), we have short release cycles and quick iterations, and we plan to re-plan often. We’re certainly not perfect, but we are committed to continuous process improvement and delivering incremental product value to market early and often. But, this APO social artifact has still not found a home.
Interestingly enough, we have clearly defined the role and organizational need as follows:
Position Summary
Wanted: Qualified Product Owners who will work with our product management and engineering teams to deliver products, on time. The Product Owner will have responsibility for engineering project management and product completion.
Responsibilities:
- Tracks internal cadence and delivery of engineering projects
- Drives engineering iteration objectives
- Provides day-to-day tactical objectives, and provides quick, JIT decisions to system level questions and defect triage.
- Works with engineering to decompose business stories into system level stories and/or designs.
- Manages the iteration and cross project tasks and dependencies
- Drives acceptance testing
- Prioritizes the iteration and defect backlog grooming and management
- Delivers the iteration
Experience requirements:
- Excellent project delivery skills, with at least 5 years experience participating in winning engineering projects
- Excellent communication and technical skills.
- Must have proven work experience as an technical “influencer”
- Scrum or XP Process-like experience in organizing and motivating teams to succeed.
- Ability to work in a dynamic and flexible environment
There it is, in a nice, concise job description. But, clearly, it’s not that easy. Here are some of our APO social artifact adoption challenges and possible mitigation strategies:
| Challenge | Mitigation Strategies |
| Engineers want a direct tie to Product Managers to ask detailed feature questions. Don’t want an APO in the middle. Product Managers don’t have time and are externally focused |
Hire within. This role needs to be a trusted entity who can carry the requirements forward on the business organization as well as be a technical leader in the engineering organization who can make the detailed implementation decisions on behalf of the Product Manager. |
| Yet, another management layer. Who needs that? | Perhaps true. But what better way to ensure product delivery and JIT decisions that increase velocity and decrease time to market? |
| Engineering wants Product Management to be more involved. Product Management is building a strategic/outward facing organization in order to grab those market opportunities. |
Growing pains! Again, lack of trust in the APO role. Never had one before! FUD factor. Hire within and have the APO live the dotted line. |
| Product Management thinks engineering should absorb the APO role. Engineering thinks Product Management should absorb the APO role | Someone has to! Don’t get stuck on where this role lives within the business. The reporting lines should be dotted throughout the organization. The need is there regardless of where it lives in the organization. |
| Strong personalities throughout the organization are tough to negotiate. No one within the organization wants the role or the encompassing responsibilities. It seems too big, too hard. | Yes, it is hard. And, good ones are hard to find. The APO needs unrelenting negotiation skills, engineering empathy and respect, and yet have the ability maintain business prowess. He also needs to be “Switzerland”, and not visibly take sides, rather be a cross-team leader while continuously balancing business requirements and engineering scope. No wonder the position isn’t filled  |
Perhaps a more logical adoption path for a start up moving from a technology-driven organization to a market-driven strategy would be to build the Product Owner role as the predecessor to the Product Management role. After all, most technology companies start in an R&D phase, and then move into the product and marketing phase. Funding the Product Owner role before the Product Manager role would enable the Product Owner adoption early and fill the gap. The next obvious position to fund in an organization’s lifecycle would be the Product Manager role as initial R&D winds down, and product markets open up.
But, we live for change, plan to re-plan, and continuously improve. Our APO social artifact will become a full-time role soon, I’m sure.
Agile 2010
Posted on February 4, 2010
Filed Under Articles | Leave a Comment
I’m pleased to once again be on the Agile Conference Review Committee for 2010 for the Agile Product Management track. The Product Manager review committee is kindly lead by Rich Mironov of Enthiosys.
This year, the conference is in Nashville, TN, August 9-13. The deadline for submissions is February 26th. Get your submissions in early!
Visit http://agile2010.agilealliance.org/ for more information.
Our Agile Celebration: “The Blessing”
Posted on February 1, 2010
Filed Under Articles | Leave a Comment
It started with release Beta .0-something. Being the agile development shop that we are, we wanted to ship to our customer as early as possible. Everything had to go: software, firmware, documentation, and early proto-hardware devices. Sunday was the day we were pulling all the artifacts together for a hand-delivered Monday morning flight.
Sunday afternoon. I arrived after a 50 mile bike ride and proceeded to crash on a couch. The power went out in the building. I fell asleep.
Next thing I know, the client engagement manager arrived. Then, her boss, then mine, all with kids in tow. Chaos ensued.
The client engagement manger was packing up devices, meters, firmware, programming tools, basically everything she needed, but in reality, had no idea how to use once she arrived at the client site (but had us back at HQ to walk her through anything needed). We did everything we could to make sure it worked as-designed, on-site, upon arrival.
It was then that I called everyone to a meeting.
We sat down in a tight circle. We calmed our bodies through simple breathing exercises. We lifted our spines and hearts. You could feel the collective energy relax. The children became quiet. Some crawled into our respective laps. The slow, relaxed breathing continued. We said a few words in honor of this momentous event. It seemed to work. Everyone left the building with a calmness and confidence that we would succeed. The outcome of that release was all good customer feedback. (from what I remember).
That was almost two years ago. The tradition continues. Every time we release, we call the entire company together for “The Blessing”. It’s a simple, yet powerful acknowledgement of our achievements, our struggles, our goals, and our past, our present, and the light towards our future.
We usually sit on the floor together, knees almost touching. We calm ourselves through breathing in goodness, and breathing out negative thoughts. It’s quiet and peaceful. Our nervous systems can do nothing except to calm ourselves after the always stressful challenge to get to the release. All we hear is each others breath. We relax our faces, our jaws, our necks. We roll back our shoulders and open our hearts. We acknowledge that we are all one, and that this product release would not have happened without each other.
Some peaceful words are spoken by anyone who wishes to share. It’s an open forum. Our lips have a slight upward curve, as we all become proud of the work we created.
This event is our celebration. We laugh about it in reflection, as we go home and tell our spouses and family about our day. No where in my career have we had such an open environment that we come together and bless our accomplishments as a company. Everyone: Marketing, Bus Dev, Partners, Client Engagement, Support, Product Management, Engineering, Operations, Sr. Management, we all participate. It’s the pinnacle. It’s the goal, it’s our entire companies livelihood, and everyone participates.
This is how we celebrate. It’s tradition. It brings us all together, relaxes our souls, bonds us as a team, and honors our collective work.
This week, we’ll bless another release with our tradition. Celebrate!
PS: yes, we drink beer too…just not at the same moment!
Holiday Readings
Posted on December 26, 2009
Filed Under Articles | Leave a Comment
In my 11 days off, I have the following readings on my nightstand:
SCRUM Product Ownership — Balancing Value From the Inside Out
A great resource for Product Owners and their teams. Thanks for writing it Bob!
The Economist
(ok, not a book, but always good reading)
The Imperial Cruise: A Secret History of Empire and War
A must read for history buffs
Born to Run: A Hidden Tribe, Superathletes, and the Greatest Race the World Has Never Seen
If you’re a runner, you’ll love it. I already read it, but may go again.
The 19th Wife: A Novel
From the author of The Danish Girl
Hot, Flat, and Crowded 2.0: Why We Need a Green Revolution–and How It Can Renew America
Another Thomas Friedman mid-blower.
Hope you get some good reading in too! Happy Holidays…
Why Agile: an executive and agile champion’s discussion
Posted on December 18, 2009
Filed Under Articles | Leave a Comment
I’ve had the honor of working with both Israel Gat and Ryan Martens. Both of them are fantastic agile mentors.
SD Times just posted a wonderful role play with these experts entitled “Wrestling with scaling software agility.” This article addresses some of the key issues agilists encounter when justifying and communicating agile development methods to executives. A good read.
The Agile Prankster
Posted on December 3, 2009
Filed Under Articles | Leave a Comment
Release Hardening
The most stressful part of the release. Here’s my persona at the moment:
- Constant monitor of all bugs, unfinished stories, and blockers. Not the most popular team member at the moment. The monitoring part seems like I’m just nagging. People run away when I approach. Ultimately, I just suck.
- Briber of teams: “Damn, if you actually do all you committed to in this iteration, I’ll take YOU ALL out to Thai food”! Nice motivator…(we’ll see if that works)
- Accountant and reporter for Release Criteria: 455 regression tests/10 testers/10 work days to go, seems reasonable, except, *It’s Broken!* There are still XX bugs to burn down, XX days left, we still need soak time, and QA cannot fully test the system. Unblock that! Clock ticking away…
- And, of course, the date isn’t moving. It can’t. I’m as un-lovely as it gets. I’m completely accountable for this release. Sleep is light at best.
- But, this is why I do it. I love it. I’ve been here dozens of times before and agile teams always get through it because they’re agile. Unfortunately, it’s still stressful.
Imagine my constitution. It’s Monday morning, my remote cube mate who is visiting from Utah tries to be cordial. I’m, um, just not. Cracking a smile is painful. I lighten up through the week, but obviously, just not enough for The Agile Prankster.
Mid-week, after a much needed workout, a bowl of 1/2 eaten macaroni and cheese is discovered in my desk drawer. I pulled it out and cracked up! On goes the detective hat.
It was lunchtime. I meander into the kitchen. I sit down with the developers (who amazingly made room). Made small talk about finding a 1/2 eaten bowl of macaroni and cheese in my drawer. “Wally was eating macaroni and cheese for lunch”, says the software architect. BUSTED! The Prankster has been discovered!
I march back to my cube farm to see Wally, firmware architect, grinning ear to ear, face red. Carrot in my hand, I say: “This carrot represents the turd I wanted to place on your chair!” We crack up…
Wally, you’re it. Watch out for creatures or old food in your travel bag next time you visit. You win the award for the Agile Prankster.
Thanks for lightening up my week. Game ON!
Agile Release Planning Musings
Posted on November 5, 2009
Filed Under Articles | 5 Comments
Software team noodling it out
I always stress out before release planning. Then, I always wonder why I stress so much during, and finally after release planning.
As the organizer and scrum master of this event, I thought I’d reflect and share some of my personal musings:
Before Release Planning
- Product Owners will always ask for more than can fit into a release cycle. This is normal and predictable behavior. Get over it.
- Even though the stories are prioritized, they are all “must haves”. Breathe deeply when your Product Owner tells you that.
- Development will take as much time as you allow for systems engineering. Try to keep them out of the weeds.
- Priorities will change up until the moment before you print cards. Keep a Sharpie handy.
- You will be printing cards up until the moment the release planning event starts. Ask the team to help sort them out in priority order, or else they’ll all be watching you do it.
- When you tell your husband you’re stressed out because there are 220 User Stories in the release planning event that day, he will say “What’s a User Story?” Just smile and tell him you love him.
Take my photo and I'll take yours!
During Release Planning
- Developers take priorities seriously and estimate according to priority (even though PO’s insist they are all “must haves”.) Just for fun, count how many times you hear: “What’s the rank of this story?”
- If you put a bowl of candy in the middle of the room, it will get eaten. Try to keep your own hands out of it, for your own sanity.
- The moment a Product Owner leaves the room, a developer will have a question for them. Just follow them into the bathroom.
- All attendees should get into it. If there are any stragglers, Nerf guns are good tools for the event.
Hey, stop it!
After Release Planning
- Commitments of 1’s (fingers) are really bad, especially if it’s the middle finger.
- Commitments of 4’s and 5’s (fingers) happen once in about every five releases. Those pump you up.
- Commitments of 3’s are discussed, but always accepted by Product Owners, as they’d rather have the team stretched, and potentially get more, then leaving with a feeling of over confidence.
- Commitments of 2’s usually beg a restart. You sucked at proper preparation with your team if this happens.
- All the stories that landed in “overflow”, or “not committed”, are suddenly no longer “must haves.”
- There’s a huge feeling of relief in the room when it’s all done!
Congratulations at getting through it!
Developers always wear shorts, especially in the winter!
The Road to Agile Growth (part II)
Posted on July 19, 2009
Filed Under Articles | Leave a Comment
In my last blog, I communicated some of our challenges on scaling, and The Road to Agile Growth. Building the Optimal Scrum Team is definitely top of mind, and how we get there is secondary. But really, the most important thing was how to build the team, so that we could get there.
We’ve come up an idea, and that is to pilot the Optimal Scrum Team with FTE placeholders, rather than names. As we go through our preliminary estimates of our next release, we recognize the need to put dedicated FTEs in the form of estimates on our project plan, but we don’t necessarily need to put names on those FTEs. This allows for the entire team to be leveraged at the appropriate tasking level, and it also allows us to move the talent around to source new challenges as they arrive. We think this could benefit the team and work for the following reasons:
1. All team members will eventually play a part in this pilot team. No one gets singled out.
2. Knowledge transfer and ultimate intellectual property coverage of the technology will occur faster, as the team is physically located together, and can be rotated at iteration boundaries.
3. Key team members can be planned to be re-sourced as they are needed on other POC projects.
4. It gives us the opportunity to adjust and grow our Optimal Scrum Team architecture, so that when we do have the dedicated resources, we have our optimal team architecture nailed.
We’ll deploy the team within the next two weeks. Internally, we are not calling it the “Optimal Scrum Team”, rather, it’s our “Virtual (project-name) Team.” Stay Tuned!
The Road to Agile Growth (again)
Posted on June 28, 2009
Filed Under Articles | 2 Comments
My lack of blog posts has not been for lack of agile interest, rather, it’s been because of the “tornado” we’re in at my company. We experienced high waves of growth in mid 08, followed by the horrible economic and market downturn in late 08, and, then, almost immediately followed by unbelievable growth and funding conditions in early 09. (Thanks President Obama!) The turmoil is exciting, yet stressful in itself (as the canker sore above my left upper canine is currently exhibiting).
The good news is that we’re on the upslope again. In his visit to our headquarters last week, Colorado’s Governor Bill Ritter recently put us in the “sweet spot” of the state’s new energy economy.
So, how does this relate to the Agile Product Owner’s blog? Well, because we’re in growth mode again, we’re once again thinking about how to best scale the organization for optimal software and embedded firmware efficiency, and always be one step ahead of the market. This creates opportunities for current and future employees, while it can also fashions discomfort of the unknown in the transition.
I’m a huge fan of Dean Leffingwell’s Scaling Software Agility blog. He clearly has his finger on Scaling the Agile Enterprise. However, as self-admitted in his Product Managers AND Product Owners post, most of the methods discussed are cultured from enterprise organizations. We’re still a baby-enterprise learning to walk/run. The challenge is, aside from just hiring the crap out of the huge unemployment pool and filling the holes (highly unmanageable and not recommended), how do you strategically grow the organization, and what are the most efficient transition/knowledge transfer/migration/ steps along the way?
Let’s start with the Scrum Team. I like this ideal scrum team architecture from Dean’s blog:
Optimal Scrum Team
While we have the characteristics (collocated, dedicated, focused, cross-functional, self-organizing), the teams are physically not organized as such… yet. It’s highly likely we’ll get there soon, as we are seeing the benefits to this team architecture.
So, my intention here is to document how we get there from here. Here are some of the challenges:
- 1 Scrum master serving 5 functional teams (ouch!)
- 0 Product Owners (or whatever the argued title is) as defined in this blog and many others. The role is there, however shared between product management and engineering management, and it’s stressing the process. (‘ak!’, you say, ‘how can you even be the Agile Product Owner without currently being one?’…’sigh, I know‘…I reply…)
- 1 UI designer software, 0 UI designers embedded
- 1 Sr. Architect
- 1.5 Technical writers and they don’t live in engineering
- 4-5 QA professionals, not paired directly with the scrum team
- Dozens of developers, organized in various teams
Aside from the obvious answer: ‘just reorganize and staff it’, what are the strategic and tactical steps we can do along the way to get there? Don’t know exactly, but I’ll share when I do. Let the journey begin…
Agile Product Owner/Agile Product Manager- Series
Posted on February 27, 2009
Filed Under Articles | Leave a Comment
For those of you still trying to weed through the APO/APM roles and responsibilies, I highly recommend Dean Leffingwell’s latest series on the subject. Dean takes an appropriate and mature enterprise view of how to grow or transition to the agile organization, even down to the most effective size and mix of teams for optimal efficiency. This team-based approach defines clear roles and responsibilities, and provides the cleanest definition between the two roles (I say roles, not titles!) that I’ve seen to date.
He also elaborates on the need for Product Owners by stating the following:
Further, as taught and commonly practiced, the Scrum Product Owner has additional, tactical activities that directly contribute to the team’s success. These include:
- Setting objectives for the Sprint (iteration)
- Prioritizing and maintaining the backlog
- Participating in the Iteration planning meeting
- Elaborating stories on a just in time basis with the team
- Accepting stories into the baseline
- Accepting the Iteration
- Driving release planning
That’s just a teaser. Be sure to visit the article. In the end, you’ll walk away with a nice recap of the critical duel, yet partnering roles the Agile Product Owner and Agile Product Manager play within the organization. Nice work Dean! Read the entire series here.
keep looking »