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  503.799.5500

read more

Overcome Resistance to Agile in Your Organization

A Simple Approach to Overcome Resistance to Agile

The biggest obstacle to successfully transition to agile is resistance to change. People resist change for many reasons, including fear of the unknown and job insecurity. If you are a proponent of agile development, then you need to overcome fear and uncertainty in order to get buy in.

If the desire to become agile begins at the highest levels of the organization, it’s the software development team that must become agile, so that team holds the key. If the desire to become agile begins with development team, management must agree to this new approach. Top to bottom, all levels of the organization must embrace the agile mindset.

How can you overcome fear and uncertainty? Make it easy for everyone to get on board.

  1. Explain how agile fits into the existing structure
  2. Start with 1 team
  3. Educate everyone involved
  4. Commit to working out the kinks
  5. Prove that agile works better

Before you suggest that even 1 team convert to agile, make you truly understand agile and the agile mindset. Get trained on agile scrum. Then test the water by asking your manager to pay for your training as part of your professional development. We recommend you read our post How to Get Your Boss to Pay for Scrum Training.  If your manager won’t pay for it, pay for it yourself. Show your commitment to the cause.

1. Explain How Agile Fits Into the Existing Structure

This seems like a no-brainer, but you’d be surprised to learn most companies that transition to agile do not even think about how agile fits into current business processes. If you want to alleviate fear and uncertainty, figure out:

  • How the new team’s roles and responsibilities map to existing roles and responsibilities.
  • How agile teams plan with and work with traditional teams.
  • How will status reporting occur? The agile teams must be able to report progress in much the same way traditional teams do.
  • How agile teams fit into the existing project management or product development structure.

Put together a proposal. Show that you are prepared and serious about taking action.

2. Start with 1 Team

Agile scrum is a software development method. Only the development team really needs to change. We suggest starting the transition with only one team. This lowers the risk to the organization, gives everyone a chance to get used to the idea, and also gives you a higher chance of success.

But, you must start with the right team. In addition to the Scrum Master, we believe you need a Product Owner, Business Analyst, Tech Lead or Architect, Developers and Quality Assurance.

You need a committed Product Owner, not an Executive Sponsor. Make sure that person is respected by the product team, understands the requirements and can prioritize the work. The Product Owner must be available to attend daily Standup, Story Writing and Grooming, Sprint Planning and Retrospective. That’s a much bigger commitment than that of Executive Sponsor, who periodically attends Steering Committee meetings.

The reason that you need a Business Analyst is because the Product Owner may not understand how to translate business requirements into stories and acceptance criteria. Business Analysts are well suited to team up with the new Product Owner and help out.

The transition to agile does not mean architectural design is no longer needed. Quite the opposite is true. Because the team is delivering functioning application code at a much faster rate, the role of Tech Lead or Architect is critical to team success. The team needs someone who understands the big picture, can build a development framework and ensure all the small pieces of functionality fit together at the end.

Choose the right developers. Yes, make sure you have all the skills to code all aspects of the application on the team. However, don’t pick developers who don’t want to switch. Just like with the Product Owner, pick developers excited to learn something new and who are willing to attend the required meetings: Story Grooming, Sprint Planning, Standup and Retrospective.  

Finally, scrum dictates that you cannot close a story until the acceptance criteria has been validated working as expected by Quality Assurance. Make sure that you have the right number and mix of testers.  

3. Educate Everyone Involved

Now that you have the right team, you need to train them. To minimize risk and to validate management commitment, get everyone on the team the proper training. The team must start with a good understanding of scrum and an agile mindset.

If you cannot get management to provide adequate training for your team, do not attempt the transition. Seriously, don’t even start. Agile scrum is way too different from traditional software development. You at least need enough management commitment to ensure everyone on the team starts with the tools needed to succeed.

To get even more buy in, ask management to attend the training. They more they know about scrum, the less uncertainty they feel about the transition.

If you can hire a coach, even better!

4. Commit to Working Out the Kinks

As they say, “Rome wasn’t built in a day.” The same is true for the transition to scrum. It’s a big change. Before you begin, get assurance from management that you have at least 6 months to get the team fully functioning.

Let’s be clear: We do NOT advocate a slow or partial transition.

What you need to do: Rip off that bandaid and practice every aspect of scrum from Day 1.

Because you are switching cold turkey, you need time to get in the groove. We know. Planning, building a backlog and sprinting are new processes. The team may be a bit awkward in the beginning.

Keep up all scrum practices. Don’t skip a step.

Use Retrospective to improve the way you work together.

5. Prove that Agile Works Better

There is no better way to prove that scrum is better than when the team delivers higher quality products to your customers in a much faster timeframe than before the transition. Agile provides you the opportunity to show off your excellent work at the end of every sprint. So, demo often to your customers. If the customer wants or needs a change, pivot.

Practice scrum, meet your team commitments and deliver high-quality products to your customer.

Walk your talk.

That’s how you prove agile works better.

GSD Scrum Training

Do you need some help with your agile transition?
Then come to our next GSD Scrum Training or call us for a consultation.


Cynthia Kahn

Cynthia Kahn

Cynthia Kahn  503.799.5500

read more

Business Must Become Agile or Be Left Behind

How 7 Agile Concepts Make Better Business Practices

Every time I read an article that declares “Agile is Dead” I roll my eyes. The reality could not be further from the truth. In this ever-changing business climate your company will need the ability to move forward with limited information and pivot quickly to survive into the next decade.

The concepts in agile, particularly scrum, have relevance far beyond the Engineering and IT departments. In this post, I’m going to briefly cover 7 scrum concepts and how those concepts can be modified to run your business with agility:

  1. Organize Effective Teams
  2. Rethink Business Planning
  3. Write Better Business Requirements
  4. Execute Business Plans in Shorter Business Cycles
  5. Practice Continuous Improvement
  6. Measure Velocity
  7. Practice Transparent Status Reporting

1. Organize Effective Teams

The Engineering and IT departments have known for years that they can no longer develop software applications in isolated silos. Both traditional and agile development teams have members from multiple technical disciplines, such as programming, business analysis, data analysis, quality assurance, security and architecture. They understand the importance of engaging the right mix of technical talent to design, develop and test an application.

Why has this common practice remained isolated to the technical side of the business? Why do Finance and Accounting, Sales and Marketing, Product Management, Human Resources and all the other myriad of departments continue to work in silos?

Every year, businesses plan to achieve specific corporate objectives, then each department develops its own set of strategic plans to achieve those objectives. What if those departmental strategic plans conflict with each other or create duplicate expenses?

If the execution of strategic plans is vital to achieving corporate objectives, then businesses should organize blended teams with the skill sets required to achieve them. Cross-functional teams increase creativity and synergy. Why would any business want to continue working in silos? Those businesses who get this concept can become leaders in their industry.

2. Rethink Business Planning

High-level strategic plans cover the fiscal year, with key milestones and metrics measured either monthly or quarterly. Success metrics are numeric. Numbers can be manipulated. It happens all the time.

Agile changes the focus from numbers to delivering value to the customer. Isn’t the customer our main focus anyway? If companies organize around strategic plans and those strategic plans provide value to the customer at lower cost, the tactical plans could break down each strategic objective into concrete deliverables that provide added customer value throughout the fiscal year. Meeting deliverable timelines should be the true measure of success.

We could take the agile concept of Epics, which are high-level use cases, and apply them to business strategy. For example, if a business has the strategic objective to attract a new target market, the team could break down the objective into discrete business deliverables: new avatar of the ideal customer, new content that speaks to that customer, new variation of the product that attracts the target market, new marketing campaigns, new sales personnel, new targets for increased sales.

After all the strategic Epics have been defined in terms of business deliverables, all those deliverables could be organized into a strategic plan for delivery at specific milestones, in much the same way application and product development teams plan for releases.

3. Write Better Business Requirements

Every strategic business deliverable is probably made up of several small deliverables that must be completed by members of the cross-functional team. If business borrowed from the agile concept of user stories, each small deliverable could be defined in terms of business requirements (what needs to be accomplished) and acceptance criteria (how we know we did it right).

If we look at one of the deliverables above, new content that speaks to the customer, we probably need to write multiple types of content, such as content for the corporate website, social media and print advertising. Requirements for each content type should be documented in the form of a story that includes acceptance criteria with specific language that speaks to the avatar of the customer.

Do you have to know the detailed requirements and write stories for each type of content at the beginning of the fiscal year? No. But you do have to identify the high-level Epics, break the Epics down into business deliverables and set milestone dates for each deliverable. You should have some idea how long each deliverable takes, so stories are written and approved with enough advanced notice to give the team time to complete them.

4. Execute Business Plans in Shorter Business Cycles

Just like with agile scrum, the sooner you deliver business value and get it in front of the customer, the better chance you have to pivot if you’ve made an incorrect implementation choice. Instead of quarterly reviews, if businesses could practice monthly reviews as part of their month-end close, then the teams could report status more frequently and small problems could be addressed before they become big problems and the team misses a strategic milestone. If the team misses an objective, then the business does not achieve its corporate goals.

Evaluating the results of concrete business deliverables adds transparency to the status of team plans and strategies to achieve corporate objectives. If a strategy is not working, pivot and try something else. Write new stories for success. If a team needs help, reorganize and regroup.

5. Practice Continuous Improvement

The scrum retrospective is one of the most powerful concepts that should be adopted by all business teams. Conducted at the end of every monthly business cycle, retrospectives provide the team with an opportunity to review what when well and identify areas for improvement. The team reviews each problem area, brainstorms ideas and votes to adopt the best process changes.

Make small business process changes, before small issues become big impediments. Teams that are empowered to make their own choices about how they work together, work better together.

6. Measure Velocity

What is velocity? It’s a measure of how many deliverables the team can deliver in a business cycle.

This means that business stories must be groomed and sized, just like any other agile scrum story. Before bringing a story in for work at the start of a business cycle, the team should review it for completeness and assign it a relative size.

Simple tee shirt sizing works great. The key is to stop thinking in terms of hours to completion and start thinking in relative sizes like Small, Medium, Large and Extra Large.  If a story is Extra Large, try to break it down into smaller deliverables. Finally, assign story points to each size. A Small could be 1 story point, a Medium could be 3 story points, a Large could be 5 story points and an Extra Large could be 8 story points.

The idea is to plan for and bring in the right amount of work in each business cycle. After about 5 months, if team size remains constant, velocity should be a good predictor of how many deliverables the team can produce each month and whether or not the team has the capacity to achieve its objectives.

7. Practice Transparent Status Reporting

When you know the team’s velocity, you can size each business deliverable and roll that up into an Epic size. Status reporting against corporate objectives becomes more transparent.

If you know the total story point size of an Epic, then you can compare that to the total number of story points completed. The percent complete at the end of a business cycle gives upper management a concrete indication whether or not the team is on track to achieve its corporate objectives. Those numbers are not easily manipulated.

Wow! You can see how agile concepts apply to all aspects of business, especially corporate strategic planning.

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


Cynthia Kahn

Cynthia Kahn

Cynthia Kahn  503.799.5500


read more