Friday, February 27, 2015

Revisiting Normalized Story Points

It has been just over 18 months since I published my most popular blog post to-date: "Normalized Story Points". As of this writing, it has received over 5,400 page views, thanks primarily to the reference it has from Dean Leffingwell's blog post from ScaledAgileFramework.com entitled "More on Normalizing Story Point Estimating".

As an Agile Coach who takes continuous improvement seriously, I have learned much and grown much over the last year and a half. Here are a few of the things I've learned regarding Normalized Story Points.

Know Why You Want Them

I've become a HUGE fan of David Hussman's "Dude's Law". Before you do anything, you need to know WHY you're doing it, not just HOW to do it.

The purpose of Normalized Story Pointing is to enable high-level estimation of work for a SAFe Release Train comprised of closely aligned teams, any one of which may pull a Feature off the Program Backlog for implementation. Normalized Story Points should not be used for:
  1. Comparing teams against each other
  2. Forcing teams to use the same story point size (so that "1 Story Point" means exactly the same thing to everyone forever and ever amen)
  3. Defining "Story Point" to mean "Ideal Man-Day"
  4. Any punitive purpose
If you don't know why you're using Normalized Story Points, don't use them. If your intended use of Normalized Story Points violates the mindset established by the Agile Manifesto, don't use them (although, if this is the case then you probably won't realize it unless someone points it out to you).

Beware the Ideal Man-Day

The 4-step process for getting started with Normalized Story Points involves using time as a reference. This works well because you're using a very small story, one with very little complexity, which means the primary factor for determining "bigness" is lapsed time. That being said, I've found that teams that start with this approach have a very, very difficult time recovering from the mindset of "1 point == 1 ideal man-day". This is bad for reasons.

This also leads to teams always using days of availability to forecast velocity rather than taking a rolling average velocity or "yesterday's weather" as an indicator of what they're likely to deliver. Data trumps theory; the approach to get started is based on theory, while average velocity is data.

Individuals and Interactions over Processes and Tools

Processes and tools exist to enhance and enable interactions between individuals, not replace them. As I've explained in a previous post, the process of Agile estimation is beneficial primarily because of the conversation that it fosters. It's a well-formed game that drives a shared mental model of the work for the entire team.

I've found that teams that use Normalized Story Points may skimp on the conversation, especially if one team ends up with work that another team has already estimated (after all, we all share the same definition of story point, right?). This was never the intent behind Normalized Story Points, but that doesn't mean it doesn't happen.

Beware the Recipe Trap

David Hussman explained that he uses "Dude's Law" to help teams avoid what he calls the "Recipe Trap" - doing something because that's what the recipe says to do, without understanding what the intended benefits are. When it comes to Normalized Story Points, the recipe trap is very real and very dangerous. If you use it, be very careful about how you explain and implement it with your teams. If your teams can't all pull from a common backlog; if you're going to use them to run punitive metrics; if you want to streamline your process by reducing meaningful conversation; or if you're looking to use it because that's what SAFe says to do, I plead with you to reconsider.

TL;DR: Normalized Story Points can be a useful tool for your organization, but it's not a one-size-fits-all solution. 

Tuesday, February 17, 2015

Tell Me Why, not How

If you're familiar with the concept of User Stories then you've likely been exposed to the concept of a User Story "script". One of the most common scripts goes something like:
As a <who> I want <what> So that <why>
As a <who> I want <what> So that <why>

Looks simple enough, right? The problem is that most people who grew up in a non-Agile environment are not used to articulating the "why" in their requirements. They are used to capturing what it is that needs to built and how. Consequently, that's what usually end up making it into our stories, causing them to look like:
As a <who> I want <how> So that <what>
As a <who> I want <how> So that <what>

What's the difference? Let's look at an example.


Old Habits Die Hard

It's not uncommon to see a story that reads like, "As an administrator I want unique group IDs for tickets so that I can easily group tickets." On the surface it looks like a good user story. What's the "what"? The author would argue that it's "unique group IDs for tickets", but that's not the need. The need is to "easily group tickets". The author is trying to dictate how to meet that need in the user story. Those familiar with the INVEST model for user stories will recognize that this violates the "N" - Negotiable.

So we need to move the "what" into its place and establish a proper "why", which means we need to have a conversation. What valuable outcome is enabled by being able to group tickets together? Do you want static or dynamic grouping? Are the groups established by pre-established rules, or is the intent for users to group tickets however they like? Once we have our answers, we may end up with a better user story, something like, "As an administrator I want to easily group tickets so that I can sort and filter to easily find tickets of interest for a given task".


Why? Why?! WHY?!?

What have we gained by phrasing the story this way? A couple of things (at least). First, we have context for the story that will enable the team of professional problem-solvers to create the best solution for the problem within the bounds of the NFRs (Non-Functional Requirements) and FSRA (Future State Reference Architecture).

The second benefit is that we can better decompose the story. With the original wording, we would likely decompose the work into the layers of the system - creating a grouping cross-reference table structure first, then the business logic and virtual object code to associate tickets to groups, and finally the user interface layer for the administrator to actually use this functionality.

With the revised wording, we can leverage the advice from Agile Learning Labs at SmallerStories.com and split our story into smaller stories that are vertical slices through the entire system. This enables us to deliver value sooner and test our architecture as it's being built instead of all at the end.


Living in Reality

This is the most common anti-pattern that I've seen in the real world of user stories. What anti-patterns have you seen? What advice do you have for overcoming user story anti-patterns? Is this even really an anti-pattern?

Friday, December 12, 2014

The Socratic Coaching Approach

"The secret of change is to focus all of your energy, not on fighting the old, but on building the new." -- Socrates

I recently read "The Goal: A Process of Ongoing Improvement" by Eliyahu M. Goldratt. For those of you unfamiliar with this masterful work, it is the book that introduced the Theory of Constraints and was a primary predecessor of "The Phoenix Project" - in fact, "The Phoenix Project" not only makes mention of "The Goal", it is written in a similar style and format!

I learned a lot from "The Goal", but I was able to apply a couple of learnings immediately to my coaching: 1) The Goal itself; 2) the Socratic method. Granted, I'm very new to this and still have a lot to learn about the Socratic method, but that's not stopping me from giving it a try!

This is the basic conversation I've been having for the past couple of weeks, usually in response to "How do I convince so-and-so to be more Agile?"

Me: What is the goal of any company?
Them (usually after some thinking and a few guesses): Make money?
Me: That's right! Now, as a development center, how do we help the company make money?
Them: We provide solutions/capabilities/cost savings/etc.
Me: Okay, and when do we provide them? When we finish requirements?
Them: No...
Me: When we finish Coding? Testing?
Them: No.
Me: Then when?
Them: When we deploy.
Me: Okay, so we deliver value when we deploy. How often do we deploy?
Them: Not often enough.
Me: I agree! So as soon as we deploy something and start working on something new, we are basically just accruing expense until the day we release again. Yet, in Agile, we often find ourselves sitting on "Production-ready" code without releasing it. What are some other consequences to releasing code in large, infrequent batches?
Them: It's more difficult for our customers to handle the change. They require weeks of User-Acceptance Testing and have to build Change Management plans around each release.
Me: Precisely! Also, what happens if we find a defect?
Them: Defects can be very expensive because we find them late, which means they are large and highly impactful. Plus the defect may be something that we developed a long time ago and have forgotten about.
Me: Right. So... what I'm hearing is that when we deploy less frequently then we delay delivery of value and increase risk, both of which are contradictory to our goal to make money, is that right?
Them: Yes, exactly!
Me: So why don't we just define Agile as a mindset of striving to deliver more valuable functionality with high quality at faster rates? Then "Being Agile" means doing whatever makes sense to reach that goal. Do you think they could get on board with that?
Them: Absolutely - they'd have to be foolish not to!

Notice that I didn't say Agile until the very end. The idea is to help them realize for themselves the obvious truths that Agile espouses in a way that solves their problems or aligns with their current paradigm. This results in a more natural mindset shift, as opposed to one that feels forced or alien in a classroom environment. I've seen a lot of success with this approach so far, and I'm hoping to get even better with experience.

How about you? Have you used the Socratic approach in your coaching? What ideas, successes, or failures would you share with someone just getting started with this approach?

Tuesday, October 7, 2014

Agile vs. non-Agile Value Delivery

One of the key differences between Agile and non-Agile approaches is how scope is managed. Agile techniques use some form of continuous backlog management, while non-Agile approaches set the scope up-front and changes to that scope are painful. As a result, I'm often asked how this impacts budgeting. I respond that I prefer a budgeting approach that aligns with "Beyond Budgeting" thinking, but I recognize that such a shift likely won't occur at the same time the team wants to start using Agile. I advise them to secure budget the same way they have been (due primarily to lack of choice), but use the money in a more Agile way. Here are three scenarios that illustrate why.

The Perfect Planning Scenario

First, let's look at what happens if both Agile and non-Agile approaches were to deliver exactly the same value implemented exactly the same way and we knew up-front exactly how much it would cost. If we took an iterative delivery approach then we would see an "S-curve" in the delivery of value (in blue), as explained in the video "Agile Product Ownership in a Nutshell" by Henrik Kniberg (starting at the 8:27mark). This allows us to capitalize on what we're building faster, so we start making or saving money faster. Compare this with the non-Agile approach (in red), where we don't see any value until the end. The area between the blue line and the red line is additional realized value over time, even though we ended up in the exact same place at the exact same time.

Blue = Agile; Red = non-Agile

The Bad Estimate / Budget Cut Scenario

Now let's imagine (if you can) a scenario where we don't have sufficient time to deliver all of the value. Maybe it's because our estimates are off. Maybe because it's because our budget is cut. Whatever the case, we end up with 60% of the time and money necessary to deliver all of the planned value. If we take an Agile approach, we end up with the top 60% of the functionality, 100% completed. If we take a non-Agile approach, we end up with 100% of the functionality 60% completed. This means that we're either delivering nothing but documentation and partially-coded functionality, or we end up begging for the money required to finish delivering what we started out to deliver.

Blue=Agile; Red=non-Agile

The Imperfect Human Scenario

This scenario was difficult to name - I'm open to alternatives. Basically, this is the scenario where the humans responsible for doing all of the non-Agile prep work of requirements elicitation, design, and coding end up delivering something that not only took longer than anticipated but didn't provide the desired value. By taking an Agile approach, we do "Just Enough, Just in Time" everything, so we're always as smart as possible when we make decisions. We work in short iterations and get fast feedback so that our defects are cheaper and our direction is constantly being corrected. As a result, we end up delivering more value sooner.

Blue=Agile; Red=non-Agile

Making a Point

As per usual, my drawings are overly-simplified to make a point. Agile is not a silver bullet, but taking an Agile approach means you're more likely to deliver more value sooner and end up with a better end-product. Hopefully this approach propagates throughout the entire organization and the way you manage work-intake, scope approval, and value execution become leaner and more continuous from end-to-end. In the meantime, do what you can within the reality of the world you live in to make the most of the resources you have. I'd love to hear your perspectives and additional scenarios that illustrate the differences in Value over Time between Agile and non-Agile approaches.

Monday, September 8, 2014

"I Like that Old Time Rock 'n Roll"

I'm am constantly amazed with the power of first impressions. As much as we may try to avoid it, the initial impressions we get when we're first introduced to a person, place, or idea tend to stick with us for the rest of our lives. This sentiment is embodied in the classic Bob Segal hit, "Old Time Rock and Roll". The song starts with its thesis:

"Just take those old records off the shelf, I'll sit and listen to 'em by myself. Today's music ain't got the same soul; I like that old time Rock 'n Roll"


This same phenomenon happens in Agile as well. When people think of Agile Transformations being hindered by first impressions, they usually jump to those who "didn't do it right", who failed and were left with a bitter taste in their mouth. I would argue that, in the long-term, the more hazardous first impression comes from those who have greater-than-anticipated success with the first thing they try. From that point on Agile is defined solely by what they did the first time.

Let's say your first approach was Scrum - and I mean by-the-Scrum-Guide Scrum. It works so well for you that you scoff at Kanban, DevOps, or anything else that violates your 5 ceremony, 3 role, pure and holy Agile approach. Nevermind that you are supposed to be looking for ways to improve every Sprint. Nevermind that the best way to improve team performance is adjustments to the process, not the people. "I'm sorry, you don't use time boxes?" "How do you plan without using User Stories?" "Clearly you don't know what Agile means."

I find it telling that the first line in the Agile Manifesto states that "we are uncovering better ways of developing software by doing it and helping others do it" (AgileManifesto.org, emphasis added). They didn't say that they had uncovered the best way of developing software, they were in the never-ending process of uncovering better ways. They didn't come up with the Manifesto by getting doctorate degrees and jumping into a think tank, they came up with it based on their experiences in doing it and helping others.

I find it highly narcissistic for anyone to have claimed the best way to do anything. Given how long mankind has been on the earth and the fact that nothing has yet been proven beyond improvement, saying that you've "figured it out" means you're either selling something, deluding yourself, or both. Those who really get Agile know that it's about the journey, not the destination. If you keep reliving the glory days of your first Scrum team then you'll never give proper attention to challenging the status quo and innovating the next big idea for delivering software in a better way.

I know, I know, it's hard to give up those first impressions, the glory days, the golden years when everything was perfect and your selective memory hadn't kicked in yet. But you have to if you want long-term success. It's risky business, but somebody's got to do it.

Wednesday, September 3, 2014

Is Agile Skub?

On a long wall at work, there's a glass board (probably 40 feet or so wide) on which our CIO will ask questions and anyone passing by can answer using dry erase markers. The question most recently posed is something to the effect of "What are you doing to be more Agile?".

I found it interesting that somebody wrote "Pro Skub" on one end of the board and "Anti Skub" at the other end. What is Skub, you ask? It's a reference to a Perry Bible Fellowship comic, penned by Nicholas Gurewitch.


This raises an interesting question for me: is Agile nothing more than a meaningless buzzword that arouses passion on the fringes that comes across as absurd to everyone else? To at least one person in my organization, it would seem the answer is "Yes!"

To me, this is an indicator of the "Trough of Disillusionment" on they Hype Curve. It reminded me of an article titled "The End of Agile: Death by Over-Simplification". To me, the points made by this article and others that it references indicate an over-emphasis on practices or principles in silos. In other words, teams will focus on one specific principle, practice, or approach under the banner of Agile and claim that it will solve all of their problems. Of course it doesn't, and when it doesn't it leads to disillusionment and cynicism.

It is so crucially important that we take a step back and look at the whole Agile Manifesto, with all of its Principles, along with complementary principles and approaches (such as Lean and Flow). Practices, approaches, and methodologies are all tools, and none of them sacred, in an attempt to align more with the Lean|Agile paradigm that will drive successful teams.

Thursday, August 7, 2014

WSJF - What to do in a tie?

Todd Kromann and I facilitated a workshop at Agile2014 on the subjects of Dude's Law and Weighted Shortest Job First (WSJF). We helped the group understand how to apply relative estimation not only to Cost of Implementation (size, expense, complexity, etc.) but also Cost of Delay (urgency, risk, dependency, compliance, etc.). We used the modified Fibonacci sequence most often used for Story Points to quantify both of these numbers, which was done by table teams. Each feature's Value Index, used to prioritize, was determined by its Cost of Delay number divided by its Cost of Implementation number. (You can get a soft copy of the handout we used here).

At the end of the workshop we had, as we usually do, a team whose features included a tie. This sometimes happens because they have the exact same Cost of Delay and Cost of Implementation numbers. More often, this happens because the numbers used in the equation are different, but the division comes out the same. One of the questions that invariable arises is: which feature should be prioritized first?

In theory, it doesn't matter - the ratio of urgency to expense is the same. Once both are implemented the ROI is equal. The decision of which to do first should be determined by the organization. In reality, I believe that the smaller feature should be implemented first. I've drawn up an example to illustrate.


In this scenario, we have two features, A and B. Feature B is 20 times more expensive than A, but also 20 times as valuable. Let's look at what would happen if we implemented Feature A first.


As you can see, we get a little value very quickly and significantly more after a delay. If we say that the y-axis represents millions of dollars and the x-axis represents quarters of the year, then we get $2MM/quarter after our first three months with no increase until five years later, when our quarterly revenue jumps to $42MM. By the end of our 22nd quarter, we will have earned $82MM.

Now let's see what it would look like if we did Feature B first.


Using the same axis values as before, we're basically going five years without any revenue. However, after five years of development, our revenue jumps to $40MM/quarter, with a $2MM/quarter bump immediately after. Just like before, we will have earned $82MM by the end of our 22nd quarter and will be earning $42MM/quarter thereafter.

So which one's better?

Do you really want to go five years without bringing in any revenue? Of course not! You'd much rather start capitalizing on your work after only one quarter's worth of work. Not only do you now have some money in to fund yourself, you're learning from the market based on how they use what you've released. This new-found knowledge will improve the quality of subsequent releases.

The reality is that, although the former option is better than the latter, neither are great. What you should do is, while you implement Feature A, break down Feature B into smaller components. It is highly unlikely that all of these components will have a 2:1 ratio of CoD:CoI. You'll identify which sub-Features provide the highest relative ROI and implement them as soon as you finish with Feature A. There may be sub-Features that you never get around to implementing because the value doesn't justify the expense. You can instead move on to a new Feature and begin decomposing and prioritizing its pieces. By the end of your 22nd quarter, you'll end up bringing in much more than the $82MM/quarter number that the two options above afforded.

That's my take on what to do in the event of a WSJF tie. What would you do?

Monday, August 4, 2014

Personal WIP

As my faithful subscribers (all both of you) may have noticed, I haven't posted anything in a while. Despite my commitment at the beginning of the year to blog at least weekly, I found myself recently with too much Personal WIP (Work In Progress). Let me catch you up on what's been going on.

New Baby!


We recently welcomed our third child into the world! His older brother and sister are both very excited, as you can see. He's been a joy, one that's kept us quite busy! He came in at 10 and a half pounds, which means that I spent more and more time helping at home to alleviate the burden on my already overburdened wife. This was a no-brainer - as my WIP increased, the priority went to my family.

Agile2014


Last week I had two firsts: I attended my first Agile Alliance conference and presented at my first Agile conference! I made sure that I had family and friends in place to assist my wife with our 2-week-old and flew to Orlando to co-present with fellow Agile Coach, Todd Kromann. We didn't use any slides, just a hand-written handout (available here), some index cards, markers, and tape. We played a game and had a great discussion. We even had the Dude himself, David Hussman, show up and commend us on our use of his Intellectual Property. We had a blast! Of course, in order for it to go as smoothly as it did, I had to spend some time before the baby came tweaking the handout and rehearsing the workshop.

Walmart Agile Summit

Prior to Agile2014, I participated in a 3-day Walmart Agile Summit in June. While I wasn't as involved as I'd have liked (again, that pesky WIP), I was on the core team and got to present a dry-run of my Dude's Law workshop. I got to meet Al Shalloway and Don Reinertsen, and I got to see Pat Reed and Rich Sheridan again. It was a fantastic experience made possible through the hard work and dedication of many people. I may not have had a lot of bandwidth, but I wanted to make sure I dedicated at least some of my WIP went to the Summit.

Walmart Agile Transformation

Of course, as the Agile Summit might have indicated, we're taking the Agile effort at Walmart quite seriously. I'm not going to disclose a lot of information or details - this isn't going to be a case study - but Todd and I were the first 2 Agile Coaches in Walmart's Bentonville office, and we wanted to make sure the Agile Transformation was done by invitation, not edict. We've had fantastic support from senior leadership, and the success of our Agile teams has accelerated the grassroots momentum that's been building. The Agile Summit served as gasoline to the proverbial fire, and interest in Agile began to rise sharply, even before the first day of the Summit. My time at work has been exciting, challenging, and incredibly rewarding. As much as I wanted to keep sharing my thoughts with the blogosphere, I owe my professional efforts first and foremost to my fellow Associates.

So that's what I've been up to. I can't promise I'll resume blogging on a weekly basis, but I am cautiously optimistic that I'll be posting more regularly that I have the past few months!

Tuesday, May 27, 2014

Understanding Agile Planning part 2: Decomposition Guidelines

I recently wrote a post explaining the process of Agile Planning. When done correctly, your work is decomposed to just the right level, just in time. If you haven't read this yet, please take a few minutes to familiarize yourself. I'll wait.

Good. Now that you understand the context, I want to address a concern that's been brought up recently: how do I know when to decompose my work? The short answer is always, but that's a little too ambiguous for most people. I'm going to share my guidelines here, and I'd ask that you share your advice in the comments.

Five Thresholds of Decomposition
Of course, as we decompose our work from high-level strategy (i.e. themes) to the low level work that team members execute on (i.e. stories or tasks), we rarely find that it fits neatly into 5 iterations of decomposition. Interestingly enough, that doesn't really matter. What does matter is the threshold that you establish for each level.

I'll start with User Stories, as that's the size that most people are already familiar with. Most teams have an upper-limit for how many Story Points a User Story can be in order for them to commit to it. Most of the time this is 8 points, though I've seen as high as 13 and as low as 3. Regardless, it's easy to see how the team has established a threshold for their User Stories. Whether you classify work larger than the team's threshold as a different type of work (Feature, Epic, etc.) or just call it a big User Story, the fact remains that it does not fit within the threshold for that level of planning. It must be decomposed.

Let's say that anything larger than 13 points is a Feature - but to what threshold? I would recommend something that can be done within 3 Sprints or less. Features are the lowest level of value as seen from the end-user's perspective, and end-to-end value should be production-ready with no more than 3 Sprints of development, depending on the product.

If your team's average velocity is 42, then your upper threshold for Features would be 126. That number's a little too precise for me, so let's call it 100. As Features become high priority, they should be broken into User Stories and prioritized for the coming Sprints' Planning ceremonies. Until that time, however, there is no need to decompose lower than the 100 point threshold.

Let's call Epics anything that take a quarter or less to deliver. This would be 13 weeks, so let's be conservative and call that six Sprints. We're now looking at 252 points, which can be rounded to 200, 250, or 400, depending on the scale you prefer. We now know that the work we're considering doing within the next quarter or two should be broken down into Epics that are within that threshold. While Epics may logically be broken down to under 100 points, we shouldn't feel compelled to split Epics that are already under our Epic threshold until they're a month or two out.

Anything larger than an Epic could be considered a Theme, with no upper-limit. You may decide that even Themes need an upper limit, but I generally don't include that in my recommendations.

Guidelines
This blog is more what you'd call guidelines than actual rules.
As I stated previously, these are simply guidelines. You may take a totally different approach. I find that some areas may define a Feature as something that takes two teams 4 weeks to do, knocking the threshold up to over 300. Others may decide that 100 is their Epic threshold. However you decide to define them, using thresholds as part of your working agreements make it very easy to tell when work needs to be decomposed and when it's better to wait so as to avoid rework or unnecessary work.

Wednesday, May 14, 2014

Hope and Direction



(Note: Originally posted without the Agile context at https://www.linkedin.com/today/post/article/20140515013228-19267203-hope-and-direction)
My primary responsibility is to help teams unlock their full potential. That means introducing change, and change is usually difficult. As I describe the possibilities of what a team can accomplish, they become incredulous that they'll ever get to that point, and therefore are hesitant to start.
They hear about this amazing team that continuously deploys to production by leveraging cross-functional team members who are experts at automation, test-driven development, SOA design patterns, and a dozen other practices.
I reassure them by explaining that I'm giving them direction, something to work towards. I encourage them to take that direction and make it their own. I then give them hope that they can begin changing - indeed must begin changing - before that vision is realized. I have them ask themselves what small change they can enact now to begin on their journey.
I've learned that teams with hope but not direction become too scattered in their efforts, and their enthusiasm and passion becomes too dispersed to be sustained. Perhaps the team has both hope and direction, but that direction is too short-sighted, resulting in the team achieving a new status quo before fully realizing their potential.
Inversely, teams with direction and no hope quickly become discouraged and cynical, viewing such a perfect end-state as unrealistic, unattainable, and not worth pursuing. They give up before starting. The worst part is that they feel they've been peddled snake oil, and they become jaded to future change initiatives. They become the defenders of the status quo.