It is the day after the night before and I am starting to turn my mind over to the homework for the week. I realized this morning that aside from the homework assignment, I also need to start executing on my strategy to reach my goal. I thought I would do something fun and discuss how I would coach someone in my world to execute it using agile practices. Please read on if you want a glimpse of how I teach teams to approach their projects.

As I mentioned before, I am a coach and trainer in real life. I take software development teams and either help them become more productive using Agile practices or I teach them how to start adopting the practices. I use a methodology called Scrum in my work to help teams execute their projects.

In Scrum, you need a few things… You need a Product Owner, who represents the customer and is the person in charge of prioritizing the work and accepting the deliverables. You need a Product Backlog, which is a list of work items to deliver. Finally, you need a Team to deliver the work in the backlog.

The team incrementally delivers the work in the backlog in a sprint (or iteration), which represents a fixed period of time (i.e.: a two week cycle of work). Multiple cycles of work make up what we can refer to as a release. I am oversimplifying this to help you understand the cycle. If you would like to know a bit more, please refer to my “€œAgile Planning in Real Life“€ article.

Some people believe Scrum is only for software development projects. My team at work is proof this is not true as we are a methodology team and we can produce training courses, processes or do coaching inside a sprint. The keys to Scrum are understanding how to break down work in small chunks and making sure you prioritize your backlog.

Figure 1 below shows the mind map of my strategy. The first step is to convert my behaviours into a prioritized Product Backlog. For the strategy map, I need to identify which ones are actionable items and put them in the backlog.

Figure 1: My Strategy Mindmap

Figure 1: My Strategy Mindmap

Table 1 shows my initial Product Backlog. As you can see, some items such as “€œDo not procrastinate, 5 weeks goes by fast” did not make the cut.

Table 1: My initial product backlog

Table 1: My initial Product Backlog

The next step is to find out the dependencies between the items in the backlog and set priorities them accordingly. Table 2 shows a prioritized version of the Product Backlog.

Table 2: My prioritized backlog

Table 2: My prioritized Product Backlog

As the product owner, my concern is to make sure the team knows what I want done in what order. The time needed is not important at this point as the team fill in the time when they do their sprint planning. The team selects work starting at the top of the backlog and works their way down. The must break down each backlog item they select into tasks and enter the time they need to complete it.

In my specific case, I assume that I have a four week release that I will break down into four one-week sprints. This means each week will have specific deliverables for me to complete. Figure 2 below shows a high-level release plan I created to map out my deliverables.

Figure 2: My Four-week Release plan

Figure 2: My Four-week Release plan

A sprint begins on the first day with a Sprint Planning session and ends on the last day with a demo of the work increment produced and a retrospective. The Sprint planning session is when the team goes through the Product Backlog and commits to the backlog items they will deliver. The demo meeting is when the team shows what they produced to the Product Owner and stakeholders. The retrospective meeting is when the team reviews what went right or wrong during the sprint so they can adapt in the next sprint to do things better.

Here are typical problems teams encounter when starting with Scrum:

  • They overcommit and are unable to deliver everything they promised
  • They forget this is a team commitment, not an individual commitment (“€œHey, I delivered MY stuff on time.”€)
  • Their sprint plans get changed along the way by new “priorities”

This week, I plan on preparing some assets for the podcast. Before I discuss the assets themselves, let me talk about the podcast itself. The name is “€œSurdek Solutions presents Agile Talk”€ and I wanted to cover the following topics:

  • Introduce myself
  • Answer the question: Is Scrum only for development projects?
  • Give an example to prove my point
  • Talk about the Scrum Yourself challenge

Wait a minute… Doesn’€™t this blog article cover some of the podcast? Woohoo, looks like a new asset! Figure 3 below shows my sprint plan for this week.

Figure 3: My sprint plan for this week

Figure 3: My sprint plan for this week

Next week, my sprint plan would include the recording the podcast and reviewing the presentation. The following week, is recording the presentation and doing post-production… I will keep going until I run out of work in my backlog.

A few important things to consider:

  • Do not add to the sprint plan after creating it
  • Priorities in the Product Backlog can change from sprint to sprint
  • The team always selects backlog items from the top-down and stops when they have no time available in the sprint
  • Working on the most important things first means you can still deliver something valuable if you run out of time

I hope you guys got something interesting out of this. It was fun to share!