Developing a Training Library

One of the best pieces of advice I received about being an Agile coach is to develop and maintain your own training library. It’s come in handy any number of times, so I’m happy to pass it along.

If you’re working for a company, then they might have standard training materials that you work from, but not all companies have the most current, relevant materials, so be prepared to update/modify as needed. There is always the bonus that it is easier/better to deliver training when you’ve been responsible for organizing the content!

I’ve found that the process of creating my own training materials served multiple purposes: forced me to develop my own point of view and organizational flow around the most standard Agile concepts and helped me to have ready responses for the most common questions and scenarios.

Among the most frequent training topics requested are:

  • Agile 101 – a whole day introduction to Agile; includes the history and principles of Agile as well as an overview of any specific frameworks the client will be using, such as Scrum, SAFe, etc.
  • Software Development with Scrum – usually scheduled for about four hours and is most often delivered to teams; includes information about the Scrum framework, roles and responsibilities and planning/workflow of a sprint as well as overview of planning and estimating
  • Delivering with Kanban – usually 2-4 hours again most often for teams; addresses the what, when and why of Kanban; an explanation of Lean, value streams and flow and Kanban-specific metrics such as cycle time, etc.
  • Introduction to SAFe – this is usually a lunch-and-learn session so would be a high-level overview of SAFe concepts and structure. I usually customize it to focus on whatever area I think an organization is doing well or really needs to improve.

Another common set of training is role-based, so:

  • Agile Testing – covers topics such as differences from waterfall; what kind of testing happens when; how to partner with developers and BA, rather than working in silo mode, etc.
  • Product Owner Training – this is one of the most frequently delivered since this role is new in Scrum and represents a big leap from their previous work
  • Agile Project Management – most often a 1-2 hour discussion session with project managers on how to survive in a Agile world; emphasis is on the switch in the project manager’s focus from task/people management to empowering the team and  focusing on removing barriers
  • Requirements Management in Agile – usually for business analysts; covers the work intake process and Agile values such as prioritization and the business-development partnership. This is the one I most customize for each client since there is a wide range of structures and roles related to this process

Then there are the training sessions to address specific scenarios, especially if you notice a pattern of recurrence. In my experience these have included:

  • Agile Planning and Estimating – for teams who’ve struggled with estimation
  • Release Planning – for teams/projects that are trying to implement SAFe
  • Iteration Zero – lesson learned while working in government space!
  • Agile Architecture for Tech Leads, also includes specifics about a tech lead’s responsibilities during a sprint, during planning, etc.
  • Metrics for Management – provides an overview of the most common Agile metrics and emphasizes that metrics are a starting point for conversation
  • Dev Ops – this has become a buzzword with my clients, so I’ve put together a basic slide deck on what is Dev Ops, what needs to be done before you can do Dev Ops, etc.

This post isn’t meant to be exhaustive, but I hope it provides a good starting point for anyone who wants to be an Agile coach or ends up in that role.


Measuring Value, 1

Are we doing Agile? Being Agile? To what degree? I’ve asked myself this any number of times and I’m guessing that you have or that your clients have.

I’ve certainly felt like Goldilocks at various times in my personal Agile journey. This organization is not doing product ownership properly. This organization is losing value in the release process. And in one way or another, they were flawed in their execution of one or more Agile practices.

But they were Agile to some degree at least. And they were a vast improvement – in delivery, productivity, value and satisfaction – than my previous non-Agile work experiences.

How can I quantitatively and/or qualitatively measure the level of agility in a team, project or organization and thereby providing a shared frame of reference for discussions with clients?

I’ve continued to work on the organizational assessment framework I’ve outlined previously. My original plan was to deconstruct each of the 12 Agile principles and brainstorm possible metrics – descriptive, predictive and/or prescriptive – for each principle.

Here are my preliminary efforts, starting with principle #1:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Obviously the key concept here is value, since not all Agile projects are software development projects. So, can we quantify value? And can we generate value-related metrics?

Here are some metrics* that possibly could represent how well we’re doing in being true to the first principle, depending on the nature of the specific project and organization:

  • % of stories in backlog that are fully developed (with acceptance criteria), reviewed by team and customer, sized and prioritized – this is my most-used metric especially for relatively new Agile teams because it is an effective gauge to determine the status of the project backlog
  • % of stories (in the backlog) that are assigned to business features (epics) – potentially indicates that requirements are being deconstructed cohesively from features representing business value
  • % of stories (in the backlog) that include business value estimates, not just effort estimates – potentially indicates good partnership with customers or at least focus on customer point of view
  • Cadence of software delivery to production – the lag time between delivery at the end of iteration and deployment to production
  • Frequency / comprehensiveness of automated builds as path towards continuous integration
  • Schedule Performance Index or Agile earned value analysis – concepts transferred from traditional projects but adapted to iterations as described
  • Release Milestone Analysis (planned versus achieved); basically indicates whether the teams are meeting their sprint/release commitments
  • % of stories that roll up to program slices (versions/themes/releases) via project/product roadmap – indicates that the organization has established that implementing Agile must goes beyond just teams
  • % of features that have anticipated and delivered ROI measured
  • % of demos where customers (internal and/or external depending upon project context) attend and where their feedback is captured and acted on

* Please note that many of these metrics were provided and/or recommended by some incredible Agile coaches I’ve met and worked with over the past year. The Agile coaching community has been generous in sharing information and this list is the result of many peoples’ contributions.

I intend to continue this process through the rest of the principles, one principle each week posted on Thursday.

Top 10 Agile Blogs

Below are ten of my favorite Agile blogs — they’re not in any particular order, but are just numbered for ease.

1. Mike Cottmeyer’s blog at Leading Agile

I have used several of Mike’s posts as starting points for discussions with clients in scaling Agile; they are especially helpful in providing language to develop a shared understanding.

The blog includes posts from all of Leading Agile’s experts, so I’ve found this categories page to be a useful bookmark when I’m trying to remember a particular post I’ve previously read.

2. Succeeding With Agile — Mike Cohn’s blog

Mike’s blog is a must-read especially if you’re working with Scrum. Just about every post reveals Mike’s expertise and extensive real-world experience.

3. All About Agile by Kelly Waters

An excellent resource for up-to-date Agile information. I have previously referenced Kelly’s posts on Scrum implementation for more than one client.

4. Lean Essays by Mary Poppendieck

From one of most remarkable thinkers and writers about Lean principles and other Agile methodologies. Not the most frequently updated blog, but contains a wealth of knowledge!

5. Fun Retrospectives

This site contains about a 100 activities that can be incorporated into not only retrospectives, as the name implies, but also in other ceremonies or any related meetings. Browse through the provided activities for inspiration to develop your own activities or select one for immediate use.

6. Agile Management Blog from Version One

Given the range of authors posting here, you’re bound to find something to help with an existing issue you’re facing or inspiration for further learning. The categories listing on the right is quite helpful!

7. The Agile Blog from Rally Dev

A number of thought-provoking posters are accessible through Rally Dev’s blog. Despite the URL, many of the blog posts are quite useful whether or not you are using their software in your projects.

8. Coaching Agile Teams — by Lyssa Adkins

From the author of my favorite book, this blog isn’t the most frequently updated, but is a must read for coaches. There are some really amazing posts in the archives, so set aside some time to browse and be inspired!

9. Thoughts on Agile Coaching by Rachel Davies

The author of “Agile Coaching”, Rachel’s strong opinions on Scrum, Agile and Coaching are always intriguing. I don’t always agree with her conclusions but appreciate the challenging perspective and her wealth of experience in Agile coaching.

10. Payton Consulting

Not sure if this series of articles counts as a blog, but since I’ve found the information to be quite valuable, I’m including it in. I highly recommend bookmarking this site; I especially loved the series on user story development.

One of the best places to discover new (to you) Agile blogs is the 100 of the best Agile blogs by Luis Gonçalves

WAIT. Why Am I Talking?

I discovered a new acronym in the most unlikely place earlier today: in the fax room of my apartment complex where I was waiting for confirmation that my multi-page fax had gone through.

Written in red marker on a small dry erase board was: WAIT. I initially thought it was a reminder to be patient in dealing with recalcitrant machinery, but then noticed the acronym spelled out below:

WAIT: Why Am I Talking?

A quick Google confirmed that this phrase has been around for a while, but it is new to me. And it was a very timely prompt as I’m starting a new project next week since it summarized so much of what I aim for as an Agile Coach.

At least once a day, I have to remind myself about the differences between action and activity and that indulging in activity, especially reactive activity, is counter-productive. Instead I remind myself to listen, watch and wait.

Wait to see if my initial observations hold up over time.

Wait to see if the problem/crisis/issue I anticipate will actually surface and if it does, wait to see if it gets resolved by the team.

And then wait some more for the right set of circumstances to apply any of the actions I had considered. Even then sometimes I end up not taking action at all.

This waiting process has been a hard practice to develop, because I’m by nature a problem solver (former project manager alert!). My job was to anticipate and fix problems, even prevent them from happening when possible. Now my goal is to help others develop their own problem solving muscles, and that requires me to not jump in.

I think sometimes people are a bit surprised that they don’t hear my voice across a bullpen more often, or see a flurry of group emails from me regularly, because their perception of coaching is activity based. And I do initiate and participate in group conversations on occasion and yes, I do send out periodic emails.

But mostly I’ve found it’s more effective to coach via facilitation during retrospectives or other framework ceremonies. And most of my one-to-one coaching happens during impromptu conversations, either at my desk or theirs.

Some days I am delivering training all day and I can see the value of my coaching, but other days when I am listening and waiting, it’s hard to remember that this is equally valuable part of coaching. I have to consistently remind myself that coaching is as much a “being” state as a “doing” activity.

Now, I’ve found a new piece of mental shorthand to stay focused on the longer-term goals. Inspiration – and blog post ideas – comes from the most unexpected places!

But Agile Doesn’t Work For Us!

I’ve lost track of the number of times I’ve heard some variation of “Agile doesn’t work for us.” It’s usually followed by some statement explaining how their organization is so complex and their challenges are so unique that being Agile isn’t a viable option.

Most of their statements reveal symptoms of Agile failure, but the people detailing the symptoms rarely have any insight into the root cause.

Usually I listen and sympathize — while taking mental notes — but here is what I wish I had said in these instances:

In general, the primary reason for Agile failure, i.e. why you are not achieving the benefits of Agility, is because you’re following the form, not the function of Agile practices.

And yes, this is a generalization and yes, there are instances where this doesn’t apply, but I find it to be applicable most often. Honestly for an experienced Agilist it doesn’t long to diagnose this root cause, often merely through observation.

For example, it is remarkable how much insight, about the project and the organization, can be generated by observing any of the Scrum framework ceremonies. Even the 15 minute daily stand-up can be quite illuminating.

I’ve seen more than one project where the teams are following the form for the stand-up “correctly” but where the focus is on providing status reports to management and/or the clients.

One indicator I often use in my observations is noticing with whom the team member is making eye contact as he or she is speaking — the project manager, the ScrumMaster or a fellow team member. As an aside, when I am coaching, I often try to stay out direct line-of-sight so that team members aren’t tempted to focus on me 🙂

Another indicator is the topic of the updates — is it about the hours, the tasks, the user stories or about challenges experienced. Usually I’ve found that repeated mentions of burning down hours or the movement of task status indicates an environment where stand-ups are used as a status report tool. Teams where conversation focuses on completion of user stories or resolving problems tend to be more self-organized or value-focused.

Other stand-up indicators that can be helpful to observe include:

  • the expressions of the people who are not speaking — are they engaged? actively listening? or just waiting for their turn to speak?
  • any sidebar conversations? among the participants or observers?
  • what happens immediately after the stand-up? any paired or group follow-up discussions?
  • how may observers are there?

No one indicator is diagnostic, but combine the results of all of these observations during even just one stand-up (although ideally you’d want to observe at least three), and a great deal of insight can be generated. And of course, you’d want to validate these observations through further dialogue maybe through retrospectives or during coaching moments. But initial observations — as with first impressions — are surprisingly revealing.

So, look and listen to your next stand-up carefully to get new perspective on whether you’re meeting the form or the function of Agile practices.

Cumulative Flow Diagrams

A Cumulative Flow Diagram is my favorite information radiator, especially at the team level. I love just how many discussion points they can generate and the level of insight they can provide. They clearly indicate current status of a sprint as well as trends over time, so I often include CFDs in executive briefing presentations as well.

As an Agile coach, who may or may not be in tune with a team’s day-to-day activities, I find these diagrams to be more useful than the burndown charts in understanding a team’s work process. I’ve often used the sprint’s CFD to jump-start a retrospective with excellent feedback.

Since we are talking about visual information displays, below are two CFDs for one of my former teams. The relatively experienced Scrum team was working on web-based software development projects in two-week sprints.

Please note that as with any information radiators or metrics, they should serve as a starting point for discussions, not as an absolute measurement especially without context! So I’m including these just to illustrate the kind of observations obtainable from a cumulative flow diagram, not to diagnose specific causes or for team assessment.

A quick guide for the diagrams:

  • the horizontal axis displays time, in business days and the vertical axis displays story points
  • the colors indicate state of the user story where Orange = To Be Started; Yellow = Development; Blue = Completed (inc. testing) and Green = accepted
CFD example 1

Cumulative Flow Diagram_1

  • The team completed all of their sprint commitment, but on story had not been accepted by the product owner within the sprint. If memory serves me right, the product owner was unavailable the last day of the sprint and accepted the story next morning, but …
  • The team was able to start delivering quite early in the sprint. This could either indicate that there was a story carried over from the previous sprint or that team was able to swarm and complete stories very quickly.
  • The blue is rather limited, indicating that there was not a large waiting time for the product owner to accept stories that the team had completed, so good partnership!
  • Obviously, the team had either taken more work mid-sprint or had work injected as illustrated by the increase in the overall height
  • The orange bloc indicates that the team was swarming on a few stories, rather than each person starting to work on a different story.

Cumulative Flow Diagram _ another example

  • In this sprint, the team had started working on most of the stories by day two, indicating lower degree of swarming, though the cause is opaque at this level.
  • Compared to the first CFD, this one indicates that the team spent more concentrated time in development stage, perhaps because the stories were more complex
  • The first story was still completed between days 4 and 5 which is good for a Scrum team since we don’t want to have all work completed and accepted in the last rush
  • The team did take on more work but was able to get all work completed and accepted within the sprint.
  • There is slightly larger blue bloc indicating some time gap between a story’s development completion and the product owner’s acceptance; could just be the time available in the PO’s schedule to test the story and get any concerns addressed.

I’ve seen even experienced Agilists express some unfamiliarity with Cumulative Flow Diagrams, so hope this post can provide some encouragement.

As far how to create them, these particular CFDs were automatically generated in Rally, and Version One and most other ALM tools can do the same. I know ScrumMasters who have used Excel to generate CFDs, but I will leave that to the Excel whizzes, of whom I am most definitively not one!

Iteration Zero: No Longer Just an Option

I have rarely scheduled an Iteration Zero for my private sector projects, but wouldn’t do a federal project without one.

There are the known unknowns of working in the federal space – the byzantine processes required to get approval for behind the scenes tools such as open-source code clean-up applications, for example – but there are also too many unknown unknowns that can trip up any project, so mitigate some of that risk with an Iteration Zero.

Iteration Zero basically refers to the preparatory activities that take place prior to the first iteration and is usually time-boxed to the standard iteration for that project.

The specific activities required in Iteration Zero will vary considerably but there are three basic issues that I like to address in order to establish a shared understanding with the customer:

  1. Do you know where you are going? And why?

The foundation to any project is shared agreement on the problem to be solved and the approach to be used. Your project backlog will provide the answer to this question.

So at the end of iteration Zero, there needs to be a feature level project backlog with enough user stories prepared for the first release. Also, ensure that you are all clear on the scope of the first release, which will be clarified in release planning.

I’ve already written about creating a backlog here and here, and anticipate writing quite a bit more on this topic!

  1. Do you know how you want to get there?

This is the technical counterpart to the backlog, so there needs to be a clearly developed and articulated technical vision. At minimum, you will need visualizations of high-level application architecture, data flow and how the components will interact along with identified technical risks and constraints.

This will also include establishing the necessary configuration management processes, such as procedures for and access to version control, change control and build management activities. I would strongly recommend making the case for implementing automatic builds in Iteration Zero, whenever possible. Implement just enough CM practices to provide the groundwork for Agile teams.

  1. Are you ready to start the full software development cycle in iteration 1?

This means having in place the necessary infrastructure, tools, and environments so that the development teams can have truly hit the ground running. Specifically,

  • Ensure all necessary tools have been approved and are in place. Think downstream and anticipate 3-6 months ahead of development teams.
  • Set up all necessary environments and access privileges (explicit notation of any differences from production environments)
  • Understand release process including any contractual deliverables. For example, your contract might require design documents even for an Agile project, so work toward shared understanding of what a design document can or cannot be.

As a project manager I’ve previously worked with used to say, “Agile requires you to have your sh– together on day 1. You don’t get to BS around.” Or you will drain value from the first few iterations and will be playing catch-up afterwards.

In addition to these core processes, Iteration Zero helps build the culture of collaboration and conversation required for successful Agile projects. As a happy byproduct, it helps assuage the fears of those who worry about the presumed “lack of planning” in Agile. So, a win all around!

By the way, one interesting factoid I picked up is the source of the term Iteration Zero. Apparently it evolved from something called a ZFR – Zero Feature Release. Makes sense, though I just assumed it was logically constructed as the predecessor to Iteration 1.