Agile Teams Still Need Traditional Support

Scrum is an Agile Development Method Not a Product Management Framework

When I talk about agile for business, I’m talking about the need for businesses to apply agile concepts, so they can better meet the needs of an ever-changing worldwide landscape. As you know, I dedicated an entire post to how Business Must Become Agile or Be Left Behind.

When I talk about an agile team, I’m talking about how development teams apply scrum in product or software development departments within a business. The biggest misconception about scrum is that when you convert to scrum, you no longer need traditional program or product management.

The role of program manager, product manager, project manager and scrum master are all very different. All four roles are important, but you don’t necessarily need four people to fulfill them. How many people you need to manage the development organization depends on the size of your business, the number of projects and/or products, and the skill set of the resources assigned.

The Need for Program and Product Management are still Required

That’s right folks:

  • Someone still needs to develop and manage the product and/or program roadmap
  • Someone still needs to decide what new products, product enhancements and/or projects the development team works on
  • Someone still needs to decide what milestones to track
  • Someone still needs to organize the workload and ensure the team delivers to committed milestones
  • Someone still needs to report status against milestones to upper management

This sounds a lot like traditional product and program management, you say? Well, that’s because scrum is a development methodology, not a program or product management methodology.

Don’t Mess with the Development Team

The practice of scrum and applying the agile mindset to software development is radically different from traditional software development. As part of transition planning, decide how the development team will work with and report to the rest of the organization. Then, once the team commits to scrum, rip off that bandaid and allow the team to truly become agile.

Program and Product Managers Guide the Development Team

Think of program and product managers as wrappers around scrum development teams. These managers guide the team’s high-level priorities and ensure they deliver according to the business roadmap.

I suggest splitting the project manager role between the program manager and the scrum master.  Program and product managers set the roadmap and report to upper management or the PMO. Scrum masters work with the development team to determine if delivering to the roadmap is possible, work with the Product Owner to ensure the right stories are brought into each sprint and work with the program manager to reports status against roadmap milestones. Most importantly, the scrum master helps the team remain agile and efficiently practice scrum.

Release Management Must Deliver More Often to the Customer

Scrum ensures a quality working product is demoed at the end of every sprint. Whether or not the updated product moves to production or releases to the customer is another process that is outside the boundaries of scrum. Remember that even if your team practices continuous integration with automated tests during sprint development, it does not mean regression testing, automated manual testing and user acceptance testing can be bypassed as part of the release cycle.

Because an updated product is available at the end of the sprint, we hope that management makes the commitment to release more often. Don’t wait. Big band delivery is the old way of thinking. Successful businesses consistently provide value to the customer, those folks that buy your products and provide the income that goes toward your paycheck.

Want to better understand how to successfully practice scrum in the real world?
Then you should read our GSD Scrum Handbook.

Want personalized instruction?
Then come to our next GSD Scrum Training or call us for a consultation.

 

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

3 Comments

  1. Monte90 says:

    Incredible points. Sound arguments. Keep up the amazing work.

  2. Jill Dakin says:

    I like calling out the difference between a Software methodology and Project/Program management methodology. We have an environment where we don’t have Project Agile Teams, we have Agile teams formed around the business lines and Projects feed them. So our Scrum Masters are managing incoming work from many projects. Do you still think that you could split your PM and Scrum Master role up or do you have another suggestion for this type of environment?

    • Cynthia Kahn says:

      Jill, I was Scrum Master on a team like that. In my case, external projects had project or program managers that came from outside the team. The Product Owner and myself as Scrum Master worked with the team to size the stories and prioritize the work. So, for external projects, that is quite common. For internal projects, I did take on the project reporting. As you know, with scrum, the PM aspects are different. You work with the team to size Epics in terms of stories and story points (not tasks and hours) and develop milestones. You report percent complete based on story points closed vs. total Epic story points. The Product Owner decides priority. The team decides how many stories they bring in. The Scrum Master can take on some aspects of the PM role, but there really is no PM, because the PM role is shared in scrum.