Tuesday, March 25, 2014

Agile2014 Proposal Accepted

Today is a big day for me; today I accepted an invitation to speak at a conference for the first time! Todd Kromann and I will be co-facilitating a workshop I've put together on value-driven prioritization, based on the concepts of Hussman's "Dude's Law" and WSJF. I've copied my abstract below. If you're going to be at Agile2014, let me know! I'd love to meet you in Orlando this summer!

Practical Application of Dude's Law: Come Play the Value Estimation Game!

Abstract:
You know how you determine the "bigness" of your work and establishing commitments, but how do your customers ensure you're committing to the right thing?

Come experience relative estimation to determine value. We'll use David Hussman's "Dude's Law" (Value = Why? / How?) to prioritize the work.

We will share techniques for determining the "Why?" so that you can generate a Value Index. What many people will be surprised to learn is that they already have tools for sizing that can be used for determining value and prioritization.

Information for Review Team:
The break-out of the 75 minutes would include:
3 minutes: Introduction to Dude's Law and the Value-Driven Heuristic
10 minutes: Explain and model the first exercise (Team Estimation Game for relative sizing)
10 minutes: Have round-table teams execute first exercise with a set of 10 features
5 minutes: Explain and model the second exercise (Team Estimation Game for relative benefit - same mechanism, so it takes less time to explain and model)
10 minutes: Have the round-table teams execute second exercise with the same set of 10 features
10 minutes: Have each team determine the Value Index of each card by applying Dude's Law
15 minutes: Have teams share their outcomes, insights
12 minutes (or less, if previous sections have run over): Q&A *

* In the case that there are not enough questions to fill the remaining time, I will explain the flexibility of Dude's Law (you can use Planning Poker or whatever technique works best for you) and introduce them to concepts such as Weighted Shortest Job First and Value Dial weighting.

Prerequisite Knowledge:
The concept of Relative Sizing (Story Points, T-shirt sizing, etc.)

Learning Outcomes:
  • Experience and learn how to apply a practical, proven game for prioritizing your work based on value
  • Understand that using a heuristic for valuation is better than both gut-feel and over-engineering
  • Understand that, as with estimating size/cost, the real value comes from the conversation

Presentation History:
I've done the Team Estimation Game dozens of times before with as many teams and have done the exercise including benefit to determine a Value Index with at least one of those teams. I also have led Program Management teams through a very similar prioritization matrix model that leverages the concept of Weighted Shortest Job First.

Comment:
My presentation is a reflection of my own beliefs and experiences. None of the material I present should be interpreted as an endorsement by my employer. I have received express written permission from David Hussman to reference Dude's Law, and I am a Certified SAFe Program Consultant (SPC), which qualifies me to speak on their Weighted Shortest Job First (WSJF) Framework.

Monday, March 24, 2014

Understanding Agile Planning

One common myth about Agile is that those who practice Agile don't plan. I've found the opposite to be true: those who truly understand Agile are planning all the time. The difference is that the planning they do is much more lightweight. They also anticipate change, rather than pretend it doesn't exist, resulting in plans that are living documents instead of notarized relics. Their plans are always accurate, but with varying levels of precision. How do they do this? Using one of the simplest, most powerful planning tools out there: the backlog.

The Backlog
A backlog is really nothing more than a prioritized list. If you've ever made a To-Do List (or its popular cousin, the Honey-Do List) then you've made a backlog. If your backlog was short, you probably got a lot done and felt a great swell of accomplishment. If your backlog was exhaustive and poorly prioritized, you probably got overwhelmed and did little to "move the needle".

Levels of Planning
I'm tackling this from an enterprise view of Scrum, but the concepts are the same regardless of how many levels you use or the terminology you pick. In general, an enterprise using Scrum should have five levels of planning.

Levels of Planning

I'm not the first to notice these five levels, so I can't take credit for the concept. The idea is that you start with a Vision that serves as your "True North". Everything that you do should align with your Vision, and your Vision statement should be updated infrequently. At this level, you're looking at Themes or Strategies that execute the Vision at a very high level.

Everything in your Roadmap - lets call them Epics - should align to one or more Theme. You may call it something different, and the word Epic may mean something different to you. When I say Epic, I refer to a set of one or more Features that provide significant strategical value to your organization. Waterfall project charters usually consist of one or more Epics as I've defined them here. Your Roadmap may go out 3-5 years or more, but becomes more "squishy" the further out you go. Roadmaps should be revisited at least quarterly and updated whenever necessary.

Releases should align to the Roadmap and should consist of one or more Features. When I say "Release", I'm referring to a production release with significant functionality. If you're in a shop that employs Continuous Delivery, this would obviously not refer to the type of release that happens multiple times each day; perhaps the word "Release" doesn't even make sense in that context. Regardless of the term, this is the level that is easiest for end-users to understand. Everything above this level is too abstract, and everything below this level is too granular.

Sprints should have goals that align with the Release plan. The Scrum teams do this by committing to User Stories that contribute to the completion of the next Releases Feature(s). My recommendation for Sprint Duration is two weeks. I've tried 3-week, 4-week, and month-long Sprints and I didn't care for any of them. Two weeks seems to be the sweet spot. Changes to the Sprint plan should be kept to a minimum, especially if the team is a less-mature Agile team. Again, the mechanics of this change for Kanban, DevOps, or similar teams.

At the lowest level, the team aligns in their Daily Scrum on how they will work together to accomplish the Sprint's goals. They may be aligning in the context of tasks, which may or may not be planned out at the beginning of the Sprint, but they are not likely to be discussing their daily work in terms more abstract than User Stories. After all, they know how their Stories are tied to Features, how those Features are tied to Epics, and how those Epics are tied to Themes; there's no reason to revisit the higher levels every day.

The Planning Engine
The mechanism for moving work intake to something that's actionable is actually quite similar across all levels. The cadence, level-of-detail, and people involved may differ, but the process is essentially the same.

  1. Discuss the item
  2. Estimate the item
  3. Prioritize the item
  4. Implement or Decompose the item
    • If Decomposing, the sub-items are fed to the next level down and the process repeats at step #1.
At the team level, this is done in the Backlog Grooming sessions (or, as I like to call them, "Story Time"). The same concept can and should be used at the other levels of Planning, simply modified to be appropriate for said level. For example, you may have more executive people meeting quarterly to groom the Epic backlog; you may have representatives from each Scrum team in a product area get together monthly to groom the Feature backlog; and you may meet as a Scrum team each Sprint to groom the Product (User Story) backlog. Use whatever cadence and team members that makes sense for your organization and circumstances.

A SAFe Approach
If you're familiar with the Scaled Agile Framework (SAFe), then you know that what I just described is accounted for in their Big Picture. If you wanted more advice on how to implement this planning engine then I recommend you view the abstracts found on their website. I've found their advice to be very useful and pragmatic.

You can implement the five levels of planning with a backlog-driven planning engine without SAFe. Indeed, there are many non-SAFe Agile companies that have established an Agile planning process before the advent of SAFe. I'm simply suggesting that, if you're new to this and don't know where to start or if you're in the middle of this and struggling with what you have, check out what SAFe has to offer. Take what works for you and toss the rest.

A Rose by Any Other Name...
As I stated at the beginning, mine is only one perspective on Agile Planning, and the terms I use may be different (or defined differently) than what you use in your organization. I would love to get your perspective on how Agile Planning can be done. After all, I'm always on the lookout for better, more Agile ways to do things!

Friday, March 21, 2014

Agile Documentation

And this, class, is what we call BLASPHEMIES!!!
One of the most common myths I get to dispel as an Agile Coach is that Agile teams don't document. After all, they value Working Software, not Comprehensive Documentation. I have to remind them that the Manifesto states "over" instead of "not", and that true Agilists still see the value in documentation inasmuch as it enhances the working software being developed. These conversations have helped me refine my message over time to the four questions I believe should be asked before documentation is produced.

Who are you documenting for?
Set permissions to 'write-only'
Who is going to read this document that you're going to write? Dean Leffingwell once told me that Agile means avoiding "write-only" documentation. If it's not going to be read, why write it?

Understanding your audience also impacts how you write your documentation. Speak to the level and with the verbiage which which your consumer is most comfortable. This is similar logic to why we include the user in the standard User Story format.

How will you communicate your documentation?
Documentation is not one-size-fits-all. There are hundreds of ways to document, from wikis to man files to interactive wizards. What format are you going to use to publish your documentation?

Another interpretation of this is where will you put the documentation for your consumers to pull? Most documentation is living, not static, so mediums like email are usually very bad. Do you have a team site, knowledge repository, or some other digital location that your consumers can bookmark to find the latest and greatest? Is the location easy to find and "on the main path", or do they have to dig for it? Make your life easy by making your documentation easy to consume.

What will be done with your documentation?
This is more a corollary for the first two questions. For example, you may think you know who you're documenting for, but what if all they do is file the information away and never look at it? Your audience may not be who you think it is - indeed, your audience may not exist at all.

As for the second question, building a README file to document your smartphone game won't be useful, regardless of how well you know your customer or how accessible you make said file - an in-game tutorial will be much better received.

Bottom line: don't start documenting until you know what your consumers' intended purpose is for the documentation.

Can it be automated?
The first three questions speak more to the elimination or simplification of the documentation you produce. By the time you get to this question, you've determined that the documentation is necessary for your end-user, future maintenance team, or whomever to do what they need with your software. So can this documentation be automated?

Documentation for future development and maintenance is often quite simple to automate. You can use certain comment formatting to generate Javadoc or Sandcastle documentation for Java and .NET applications, respectively. You can use tools to generate your class and sequence diagrams as part of each build. There are several forms of technical documentation that can almost always be automated.

User-facing automation is trickier, but not impossible. For instance, you could generate LaTeX templates that are plugged in with data that's auto-fed to it and output documentation in the format that works best for your users. Get creative with it and see what you can come up with.

Questions?
Those are the questions I've developed over time; what are yours? How do you determine what to document and how? Do you find yourself documenting more or less using Agile than Waterfall? How has the nature of documentation changed? I'd love to learn from your experiences.

Wednesday, March 19, 2014

Introspective: Trying new things

This week my Introspective turned my thoughts towards trying new things. In that spirit, I've published this week's Introspective on LinkedIn. Let me know if you like it better, worse, or are indifferent.

Wednesday, March 12, 2014

Introspective: Systems and Serendipity

I recently met with a fellow alumnus of my Alma Mater, BYU (go Cougars!), who had sought out my advice. As I walked him through my brief career to-date, I commented on how serendipitous it sounded when the key events of the past six years were rattled off in quick succession. It's difficult to explain the hard work I put in; the difficult decisions I had to make; and the misfortunes that selective memory has edited from the easy retrieval section of my mind.

What I was able to tell him was that I have not landed where I thought I would have six years ago. My biggest take-away from my experiences is that goals are mostly useless; more specifically, the longer out the goal is the more useless it is. What got me where I am today is a system of looking for opportunities that would put me in a better position for luck to find me. I noted how fortunate I was to have recently read Scott Adams' book "How to Fail at Almost Everything and Still Win Big", where he talks about this exact concept; otherwise, it would have been much more difficult for me to articulate my journey without using the word "luck" a lot.

"Avoid employing unlucky people. Throw half of the pile of CVs in the bin without reading them."

What I've taken away from that experience is that I need to do a better job of documenting my journey. Without something I can reflect on, it is very difficult to explain to those unfamiliar with my journey that my success is not just a "fortuitous happenstance", a.k.a. serendipity, a.k.a. dumb luck. I feel the same way about luck as Peter Dinklage does, which he explained after making the remark that he felt "really lucky":

Although I hate that word—“lucky.” It cheapens a lot of hard work. Living in Brooklyn in an apartment without any heat and paying for dinner at the bodega with dimes—I don’t think I felt myself lucky back then. Doing plays for 50 bucks and trying to be true to myself as an artist and turning down commercials where they wanted a leprechaun. Saying I was lucky negates the hard work I put in and spits on that guy who’s freezing his ass off back in Brooklyn. So I won’t say I’m lucky. I’m fortunate enough to find or attract very talented people. For some reason I found them, and they found me.

"I hate that word -- lucky. It cheapens a lot of hard work."

By looking for opportunities and making choices that put me in a better position to find luck, I happened to be in the right place at the right time when opportunities presented themselves. I want to be able to tell my story better so that others can better understand and learn from it. This blog will be my primary vehicle for that, along with Twitter and LinkedIn, but I may end up looking at other options as well.

Thursday, March 6, 2014

Introspective: Agile Metrics and Work In Progress

One of the things I've been doing lately is helping people understand what metrics you can use with Agile teams (there are tons!) and, more importantly, how to use them. Whenever I explain a metric to someone, I always include what behaviors the metric may drive and how to avoid misuse of the metric. When metrics are used inappropriately they drive bad behaviors and result in teams gaming the metrics. Even when used properly, leaders and teams must understand that almost all metrics have a shelf life - they cannot be used forever and continue to produce the same level of improvement.

One example is team spillover. Many see spillover as a cardinal sin and will not tolerate it. The guidance I give is you want to limit spillover, but occasional spillover should be expected as the team adapts (new tech, more robust Definition of Done, innovative practices, etc.) and shouldn't signal concern unless it happens repeatedly. Eventually the team will become so good at course correcting that spillover may not even be monitored. The team may move to a purely Kanban system where the focus is on flow and SLAs instead of time-boxed commitments. Regardless, spillover should never be used to evaluate team members. Including spillover on an eval is a guaranteed way to get sandbagging.

Why is this on my mind today? Because today is Thursday, and my Introspectives are due on Wednesday. My tardiness is due to a combination of too much WIP and plain forgetfulness. This past week has been very busy for me due to my division's Year Beginning meetings, the process of transferring to a new team, and my usual day-to-day work. I am focusing on limiting my WIP so that I can better manage what's on my plate. Next week's Introspective should come on Wednesday, but I can't guarantee that I won't miss my self-imposed deadline the rest of the year.