Rod Claar

Agile  and it’s various implementations, including Scrum,  while most often discussed in software development circles,  can correctly be classified as Product Development methodologies.  Most of the time the product being developed has software as a major component, but they are products developed to solve a problem or make a job easier or more efficient.  When we think about products in this broader context we can often identify some impacts on product management rooted in the Agile practices and thought process.  We need to understand these impacts to be prepared to mitigate them and propel the organization to the next level.

The first and most obvious is the impact of faster release cycles.  There are many things that Agile teams do to achieve faster release cycles, but the primary driving reasons are faster return on investment and quicker feedback.   In my experience the product management team are often not prepared for the high level of interaction that the Agile team will demand.  Even if they had prepared well in traditional terms, the depth of detail that will be required by the Agile team will outpace the product management team and make it harder for them to prepare the vision and business capability plan for the next release.  When the development team delivers early with fewer problems and the product managers are not ready to reload the team poor decisions on what to do next often result.  Then scrambling to fill the gap the desired feedback can be passed over leading to more bad decisions.  The cycle is almost unstoppable without a significant change in product management and market research practices.

The next common goal of an Agile team is continuous shippablity.   An organization delivering more reasonable  scope, quality higher and a robust base of automated tests, sooner or later someone will ask why we can’t just ship it to meet a new market, for a special customer or to beat the competition.   This is like having a 225 m.p.h. car and trying to get it up to speed wearing a blindfold.  You might get lucky, but more often you will be off the road very quickly.  A few years ago when working at a software company, sales asked us to adapt our product to a different market.  The engagement was a total disaster.  We did not take time to understand what this new market wanted.  Our brains were tuned to our normal market and could not understand the context and the paradigms in place in the new market.

In both of these scenarios what is missing is more information about the customer and how they use the product.  Traditional market research can deliver the answers, but it takes a lot of time and generally a lot of money.    Some products can support the cost of the market research, but many medium to small organizations cannot afford formal market research.  Trying to go to market without having the knowledge of how customer will use the product can sink even the best product.

What  is required are techniques to get the market research to make good product planning decisions in pace with the development team.  The Agile planning cycles of iteration, release, vision, roadmap and portfolio need to match up with processes that answer the questions about near-term product improvements, product evolution and other markets.

If we could lower the cost of market research and product planning while still delivering valuable and accurate results, we would have a better shot at delivering the best value to our customers as fast as possible.  This is the true promise of Agile.

Recently I had the opportunity to attend Luke Hohmann’s Innovation Games® Consultant Master Class in San Ramon, California at the Chevron campus.  The class was held in Chevron’s Innovation Space and attended by 20 or so of the smartest Agilests on the planet.   This class was aimed at helping this group of world-class consultants understand how Innovation Games® can be used to deliver cost-effective market research for the Agile team.

Luke is a great facilitator and this two days was packed with great concepts and practices.  He and his company is on a mission to restore the concept of serious games to business.  The idea of serious games was all but destroyed by computer games and online gaming.   Serious games are still fun but have a purpose.

Luke told us that “Innovation Games® are serious games that power innovation by enabling you to better understand your customers”.

With the knowledge and skills gained from this class we will immediately start offering a new course “Innovation Games® for Agile Teams”. This course will contain some lecture but will be predominantly discussion and hands-on exercises to help you understand how Innovation Games® can be used by Agile organizations to help provide the right vision and feature set to the development team and in turn your customers.

Agile teams who employ Innovation Games® find some of the dull and repetitive practices of Agile comes alive in a fun and engaging way.  Scenarios might include:

• Using Product Box to identify customer requirements.
• Using Speed Boat to improve retrospectives.
• Using Buy A Future to prioritize the product backlog.
• Planning a project using Remember the Future.
• Clarify the release plan with Prune the Product Tree.
• Understanding how your product is used through Me and My Shadow and Start Your Day.

Each student will receive a copy of Luke’s book Innovation Games: Creating Breakthrough Products Through Collaborative Play.

Course Outline

• Overview of Innovation Games®
• Customer Collaboration
• Continuous Planning
• Portfolio Prioritization
• Product Backlog Prioritization
• Strategic Planning
• Release Planning
• Agile Retrospectives

Audience

All members of an Agile team are invited to join us with a focus on product planning and management.

Format

Standard - 1 day.

Extended - 2 day with more game played by participants.

Schedule

The course is available for on-site delivery and will be offered as a public course.

For more details see http://effectiveagiledev.com/ or call 530-SCRUM-42.

You might be thinking that my title would get a response from Homer Simpson (Doh!), but too many teams try to do Scrum or Agile in a rigid and prescriptive way. There are a couple of main reasons that I see this. The first is the desire for new teams to “do” Scrum right when they are new to Scrum. I resemble that feeling! On my first Scrum project (several years ago) I defended the process against change rather than being open to process change. Oh well, we all have to learn somehow!

Change for the sake of change is not a good thing. Any process change should be driven from retrospective discussions and the desire to reduce or eliminate impediments. What is holding your team and product back? What was the root cause of the problems you encountered? The team should discuss these issues and pick one or two top issues and agree to work on them and try to find solutions to them. If that means changing Scrum, then CHANGE SCRUM!

The other major cause I see of process rigidity is on teams and projects that are large and complex enough to require an electronic system for tracking work items, making distributed team communication easy to find and use and reporting out status and progress. There are a lot of tools out there and any tool, used to drive the team and project, can strip agility from your organization. However nearly all teams have some distributed component and we all know that the last simple project was done in 1959! This means that almost all teams and project need a system to help manage the project.

I’m a white board and sticky type of agilest. Give me a team room with white boards and a bunch of multicolored stickys and I’m a happy camper! Why? Because I know that the white board and stickys are NOT the project, the people and the conversations they have with each other are the project and the white boards and stickys are used to drive those conversations and track the work.

However for most teams and most organizations, my agile dream project just does not exist and trying to force it to be is foolishness. Most organizations are going to need a tool.

What makes a good Scrum / Agile tool?

1) It must not have a fixed process flow. The team must be able to tweak the process to fit their culture and organization.

2) It must be simple enough to enable not get in the way. The team must drive the project rather than the tool.

3) It must produce status and progress reports that are customizable and accessible to the business. Feedback is the process that keeps Scrum / Agile on
track in a world of changing priorities. Having status and progress reports that truly inform the stakeholders and project sponsors of where the project is drives the prioritization process to meet business needs.

4) The process must have a business value driven approach. In other words the project management tool must drive business value and make business value delivery clear to the team and stakeholders. If a tool is a bottom-up project management tool, the team is building the trees at such a high rate of speed that the forest of business value is totally obscured.

How the team uses the tool and how the tool allows the team to focus on delivering business value is the main critical issue. A tool must be flexible.

This week Daptiv released Daptiv Scrum that can be used in conjunction with their popular Daptiv PPM product. These tools allow companies to manage and track all their work in one centrally visible source. This allows the business to see the benefits of an agile process. After configuring the system to match the process at the organization the team and management can be comfortable knowing that the team is driving the product rather than the tool. Along with the standard Scrum roles of Product Owner and Scrum Master you can create custom roles to meet your need for engineering leadership, release management, configuration management and other custom role.

One of the biggest advantages of Daptiv Scrum is the ability to easily manage a story driven product backlog. Priority changes are done via drag and drop right in the product backlog.

Daptiv Scrum also gives you the reporting artifacts you need to manage the scrum process: Sprint Burndown, Release Burndown, Sprint Summary including calculated velocity, Sprint Tracking, and Features by Product Category. They’re all here.

However one of the best advantages is the ease of setup and maintenance. Built on a web model, Daptiv delivers automatic updates via the web which frees your team from updates and configuration issues. This ISO 27001 Certified organization provides your team with the security, redundancy, uptime, maintenance and new features so your organization can focus on delivering business value.

For more information about Daptiv Scrum see their web site at Daptiv.com See the press release at http://www.marketwire.com/press-release/Daptiv-Inc-1001235.html .

Oh! I almost forgot!  Play the Escape from Scrum Island game!

There has been a lot written about the role of the Product Owner in Scrum over the years and it seems to me that in the last month or so the question has received a lot of attention in blogs, twitter and other social media.

I don’t think there is a “best practice” answer.   Let’s look at what we do know and then see if we can find an answer.

The goal of the Product Owner must be to deliver the right business value.  To do this they engage the team(s) to create solutions that deliver the business value.  The Product Owner is listening to and evaluating the needs of the stakeholder community.  They must have a great business sense and understand their market and customers.  They must understand what is technically possible.  From all this input they deliver a stream of input to the team about what the priorities are.  They are constantly updating this information and evaluating the output of the team to check it for completeness and correctness.

While the team has the same goal of delivering business value, their problem space is much different.  In all but trivial domains and projects this requires a team approach.  Team building is not about money.  Ask Yankees owner George Steinbrenner!  Team building is not about technology or computers.  Team building is about people.  However the problems faced by the team in delivering the solutions is about technology.

The team takes direction (course) from the Product Owner, but the Product Owner cannot work in the engine room of the Scrum ship!  It is not that they are not qualified (they may not be) , it is just that their primary role is so important and time consuming they would be neglecting that duty if they did.

The team must take the direction (course) from the Product Owner.  Their work demands their complete attention.

We know all this.  The real question is how do we best create the communication and feedback that the Product needs so that the business can be successful and thrive?  Scrum provides a great starting point.  Lean helps us understand the product view and the flow of business value.

The process of planning a product release must include input from the team.  Sprint planning is a cooperative process between the Team and the Product Owner.  

The daily stand-up is a Team meeting that is core to team building.  Scrum tells us that the product management team can listen to this meeting, but it is the Team’s meeting. If I were a Product Owner, I would be at the daily stand-up if at all possible.

The Sprint review and demo are about the Team getting feedback from the Product Owner and anyone interested. If I were on a team I would NEVER go into a Sprint review without knowing what the Product Owner thought of the Sprint output.

The Sprint retrospective is a Team meeting.  This meeting is primarily focused on team building and process refinement.  This needs to be a private Team meeting.

Can the Product Owner be a benefit to the Team in the daily process of developing the solution?  That depends.  How  much time do they have?  How well do they understand the technology?  How well do they work within the Team?  No one can know the answers to these questions without observing the Product Owner and the Team.

Will the Product Owner be a helpful, accepted and valuable member of the Team?  That depends.

Can the Product Owner deliver the stream of information and decisions to the team with a high level of accuracy?  That depends.

With all these unknowns, I don’t believe that anyone can say how any particular Product Owner and Team will be able to work together best without some first-hand knowledge.  When I’m acting as the Agile Coach, I suggest that the Product Owner start out somewhat restrained in their interaction with the Team while the Team figures out how to be a team.  I’m not saying that they should not be available and should not speak up when there is an issue.  I coach them to not inject themselves into the Team.  As the Team matures and as the Product Owner gets accustomed to their new role this may change, but any change that I recommend will be to improve specific process and communication issues.

The Scrum Master, if they have the experience, can and should help with this. However new organizations would do well to get an experienced Agile Coach to help with this and the other issues of being more Agile and delivering more business value.

This is worth watching! Make sure you full-screen it!

Scrum methodology from Soul' on Vimeo.

Note: No developers were harmed in the making of this video!

  

 

I'm speaking at Agile 2009

May the Forces Be With You, Exploring the Forces Driving and Restraining Agile