Agile – Adopting to Change vs Following a Plan – a football analogy

Agile – Adopting to Change vs Following a Plan – a football analogy

As I sat watching Sunday Football, and thinking of my upcoming blog… I became aware of the similarities between football and Agile! Consider this, each time my football team has the ball, they have an end goal; to get points on the board. They also have intermediary goals, to deliver 1st downs in order to retain the ball. They studied the opposition, and made some plans for the game. Then at the beginning of each play, they make a plan in the huddle, and execute. At half-time they have a retrospective.

So if you are into football, ask yourself; what would happen if they had to plan the entire game in advance? What would happen if they couldn’t respond to change within game or even the down? The ability of each player to take responsibility for their work, seeing the big picture, and responding to change as needed keeps the game going. It also parallels what we do when working in Scrum Teams.

Our big picture is provided by the Product Owner. Our end goal to deliver on the big picture incrementally by accomplishing 1st downs. Sprint Planning allows us to see where we are and identify our plan for the sprint (football’s quarter). Our Daily Scrum allows us to plan the play for a day just like in a football huddle. Based on outcomes, we adapt to change continuing to focus on the end goal.

It takes the entire team to play the game. Each player must be accountable for what they are doing. Otherwise the quarterback gets sacked, the ball is fumbled, and overall play is stymied. There is total visibility. No one can hide if they don’t deliver. Sound familiar. It should. If it doesn’t, than your team may not be transparent about its work.

The Product Owner is like the Quarterback, supplying the team with user stories for the sprint. The Scrum Master is like the Coach, supplying support from the sidelines.

So when it comes to adapting to change vs following a plan, think about that football team you watch on Sunday night.  First, embrace the fact that being Agile allows us to adapt to change and that adaption is what helps us win the game. Second, make sure you make the most out of the huddle, or Daily Scrum, by truly planning how to move the ball, or story, down the field.  Finally, hold the team accountable while you drive to the end goal.  No football team ever wins on the basis of one player alone.

As your organization prepares to transition to an Agile one, you will most likely want to know all that the transformation entails.  One of these things will be transforming your technical practices to better align with the Agile Engineering Practices…so how can you make it a success?

Plan For It 
Organizations typically will look at the process, the teams, and the projects they will transform in their move to Agile.  However, they often forget a key piece of the puzzle: the technical ‘stuff’.

In the scheme of things, it is fairly easy to change the process that one is doing from process A to process B.  It’s also relatively easy to choose the projects that will move to Agile and the teams that will work on them.  The hiccup is that they almost always forget about the changes that must be made to the technical architecture they have in order to ensure the complete transformation.

Identifying the technical changes that need to be made and ensuring they are part of the transformation plan are keys to making your agile transformation a success!

Architecture on the Brain
In most organizations, the technical architecture is one that is usually aligned with projects or, sometimes, aligned with what was pushed and when.  The architecture is most likely not aligned with the various applications or features that the organization produces.

When this is the case, the teams most likely will have a difficult time aligning themselves in a way that they can concentrate on any specific application or feature.  This concept produces issues for teams’ ability to work on a defined backlog, and even worse, creates barriers to them completing anything of value during a sprint.  This type of architecture is steeped in dependencies and blurry lines.

In order to ensure the architecture is set up to allow for the Agile Engineering Practices, it is imperative that the architecture be examined and plans be made to make the necessary shifts in the alignment of the architecture to match.

What About Environments?
Environments are another aspect that can cause issues when attempting to institute Agile Engineering Practices.

There are usually multiple environments, like DEV, QA, SIT, UAT, and PROD, that the team will move their completed increments through.  The biggest concern with this is that most of the time, the environments do not match up and they have varying states of the application and data.  This poses numerous obstacles to the team being able to produce effectively.

To deliver value effectively, teams need to be able to accurately test the stuff they are producing.  In order to accurately test, they need to have a “clean” environment to move their increments into.  When environments are not in sync and/or are not aligned correctly, teams will have issues creating successful builds and testing them.

When the environments are not correctly aligned and/or they are not working properly, there are major consequences that can result.  These consequences can range anywhere from not completing a sprint’s increments to producing low quality results to ending up with unwanted value.

A Couple Things to Think About
If an organization doesn’t identify and plan for the technical architecture changes they will need to support their Agile transformation, they will most likely cause more delays and, more importantly, pose more barriers to the team’s effectiveness.

Examine what your team has in its way when it comes to developing, testing, and deploying code.  What kinds of measures do you feel your team needs to take in order to deliver value on an incremental, consistent basis?

Stay tuned for the next installment where we will look at ways to make the technical transformation a reality…

The role of a Product Owner in Scrum includes owning the backlog and preparing stories for sprints. As I work with product owners I remind them that not every item in the product backlog needs to be ready to develop.

Agile backlog and user story progression reminds me of the pyramids.


When we first start, we are at the base of the pyramid. Our customers have such big ideas we call them features. When we start to think more about the feature ideas, we create epics further defining what our customers will want. Those epic stories are still too big to fit into a sprint. So we continue to break them down into small pieces called stories.

As the stories get closer to being taken into a sprint, the story must be small and refined. A good Definition of Ready (DOR) will help us understand when stories are ready to move from the Product Backlog to the Sprint Backlog. The DOR helps the team agree on what must be included with the story in order for the dev/test folks to do their jobs. The basic story and acceptance criteria are required parts of the DOR. In addition, the team will add various items to the DOR list, e.g. wireframes, examples of formulas, and database excerpts.  Product owners should be working on stories they would like to see be developed within the next 2 – 3 sprints.

So in my example here, as stories percolate to the top of the pyramid, product owners review them with the team in grooming sessions. Then at sprint planning, the top stories are pulled out of the product backlog and become the sprint backlog.

The saying “just enough, just in time” helps keep product owners focused on ensuring the right stories get to the top of the pyramid, just in time for the team to work on.

For more information, check out Mike Cohn on the topic: