Whether you're trying to bring agile software development to a company or evangelize management to continue to support an agile team it's important for ScrumMasters to realize they aren't alone. In fact, if the SM is the sole evangelist for the process in the company you'll end up fighting an uphill battle that you'd wish you brought in support for. Even if the business (or customer, if you want to substitute) agrees with you and allows you to "go back to your desk and be more agile," you'll likely find yourself in a place where the engineering team thinks they are agile and the product/business side continues to be stuck in the waterfall. I've been here before and it's a tough position to find yourself in.
The best support a ScrumMaster can have is a committed Product Owner. As the title implies, the Product Owner owns the product (duh), so they have lots of influence and sway over the way the business-side functions and how those outside of the engineering teams view feature development. While you already have your team of engineers on board, you're only halfway there. The Product Owner is the key influence in getting the rest of the business to think in an agile state of mind.
What Makes a Good Product Owner?
The Product Backlog
The Product Owner manages the product backlog which is really just the list of all feature requests created by stakeholders throughout the company. In other words, the Product Owner controls the priorities of the business and keeps them in balance with the direction of the engineering team. If you want something built, you go through the Product Owner first and make a damn good case for why your feature deserves the very limited resources of the developers.
The product backlog is the number one tool for conveying to the business how beneficial agile/scrum can be in meeting everyone's needs in a quick & efficient manner. Throughout the month, my company allows various stakeholders to submit feature/project requests along with rationale for doing so and a suggested urgency (high, medium, low). At the end of the month, we meet with all stakeholders & executive staff to go over all items in the list for prioritization. The moment the backlog appears on the shared screen in the board room, it becomes apparent for most stakeholders that if they haven't done a good job developing their business goals (ie revenue gained, time saved, etc) not only will they look foolish in front of the company's decision makers but their feature, which they undoubtedly said is "high" priority, is unlikely to be developed without further upfront analysis. The features with the highest impact on the business rise to the top while those with the lowest impact drop to the bottom. For the next two sprints the development team works top down on priorities and we start all over again.
This is the power of a well-maintained backlog. It gets everyone aligned with the company's top priorities which are quickly delivered into the hands of the engineers. It is impossible to be an effective Product Owner without maintaining a very high quality and organized product backlog since it is the document which business uses to pour their ideas into and development takes their marching orders from.
When the business sees top priority features being rolled out every two week iteration the benefits of agile are pretty clear.
But there's more to being a top Product Owner than just maintaining a list of priorities.
A Product Owner is a member of the team
This is a fact that is lost on many agile shops and one that can make or break the success of a team. Traditionally, there are few groups more diametrically opposed as product and development. If you reread that sentence it seems ridiculous to consider, but technical staff sees the world differently than the "idea people" of a business. One group sits in a room with expensive machines with retina displays and dreams up the fluffy widgets while the other sits at the end of the assembly line and has to make sense out of all the unusual things that come out of "happy land". (Can you tell what side I'm on?)
For agile to work, this orthodoxy needs to be torn down from the start. One side does not get to be the idea side while the other is the action side. Ideas are not simply handed off to developers and then forgotten about until demo when the engineers are left "holding the bag" on missed deadlines or features. The best agile teams have seamless integration and collaboration with the Product Owner and stakeholders. Good Product Owners know that their jobs don't end once development has begun and that engineers will never be stranded to confess their wrong-doings in front of a jury of their peers once the project comes to a close and things are missed.
Product Owners are there, lockstep, with engineering every step of the way to make sure when the ScrumMaster or team comes to them with roadblocks (of which there will be many) that they are successfully navigated. Many times the things we're told to build just don't make sense or can't be completed in the time originally committed to by the team (google "cone of uncertainty"). This is one of the most glaring realities of software development and the biggest stumbling block for agile teams.
Can't get all of the gee-whizz javascript features to work in all of the browsers required for launch? The Product Owner scales back the gooey requirements, adjusts which browsers we care to be compliant with, or extends the workload into another sprint to make sure everything works the way they want it. Most importantly, good Product Owners communicate any changes in scope or time to stakeholders and upper management. The business will be more than thrilled to be a part of the decision-making process when changes need to be made, but if they don't know that there are roadblocks to begin with, they will just assume that everything is on track and be stunned when things aren't the way they expect at the end.
There is always an agreeable compromise to be made on any bump in the road but they have to be dealt with transparently and promptly by the Product Owner and team as soon as they arise. This constant stream of communication between the team, Product Owner, and management is the linchpin for success. Most professional adults can handle the truth and adjust accordingly. However only if stakeholders are given a view into the process and see how their decisions help shape the direction of the project can a development team expect to keep them happy. Making sure this occurs is the key to a great Product Owner.
In top agile teams Product Owners are best friends with the ScrumMaster. They both know that all projects are collaborative exercises between developers, designers, & stakeholders. There is no baton hand-off as in relay races. Software development is not an assembly line. Same as the SM weaves agile fabric into the development team, so must a Product Owner evangelize to the rest of the business. Only when both have their constituents believing the message can an agile team truly flourish to deliver cutting edge features to market in the turnaround time now expected of modern software development teams.
If your team is on the rocks or there is a big disconnect between what the business side thinks you do from what you actually do, start with reevaluating your relationship with the Product Owner. If you two aren't on the same page, it's impossible to expect company-wide trust in agile development.
No comments:
Post a Comment