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.

Monday, April 21, 2014

Not just Agile - ____ Agile!

Let's do whatever we want and call it a new flavor of Agile!
Every now and again, I meet a team that's doing things very differently than your traditional Agile team. They often label themselves with a prefix - they're not just Agile, they're "Extreme Agile" or "Hyper Agile". Personally, I think that the term Agile encompasses all that a team would ever aspire to be, though Agile teams may be at varying levels of maturity. Scrum, Kanban, SAFe, DevOps - whatever you want to call yourselves, your team should strive to get better and better at aligning with the Agile Manifesto and its Principles. This means your practices reflect Agility and your are continuously improving.

So how can you tell if you're Agile? I recommend asking three groups of people: your peers, your clients, and yourselves.

Your Peers
If you're an Agile team operating as part of a larger organization, there should be a balance between competition and collaboration between teams. Everyone wants their team to be the best, but not because the other teams are so bad. You should be working hard to improve your competition, a.k.a. the other teams in the company, so that they, in turn, will push you to be better.

Ask your peers how Agile you are and be prepared for some candid yet constructive feedback. Remember, you're all in this together. Cross-pollination and frequent feedback from your peers makes everyone better.

Your Clients
It doesn't matter what the nature of your team is, your code is being used by someone. Whether it's an end-customer, a business user in another division, another system within your technical organization, etc., there's somebody who uses what it is you're building. The Agile Manifesto and its Principles make it very clear what kind of relationship with and service to our customers we should be striving for. All you have to do is ask your clients whether they feel that relationship and service is there.

You should also look for ways to continuously improve how your interact with and serve your clients. What delights your customers today will soon become the status quo. If you're a good Agile team, you're meeting with your customers and getting feedback on a frequent basis, anyway. Take some time to go over how you're delivering, not just what you're delivering.

Yourselves
We are often our harshest critics. I encourage all Agile teams to have everyone on the team fill out some sort of self-assessment on a regular basis (a quick search will provide you some examples). By getting as many responses as possible, you avoid the extreme ups and downs that come from individuals. Look at the mean and median results, then discuss your perceived strengths and weaknesses as a team.

Sometimes we feel we're at the top of our class because we're excelling at what we understand Agile to be. It's important to stay involved with the greater Agile community so you can find out the latest and (potentially) greatest practices and techniques for driving Agility. Even more importantly, recognize that there's no such thing as perfection, only better, and instill a passion for continuous improvement within your team.

And Also...
I'm sure there are other ways to gauge a team's Agility. What other ways would you recommend for teams to assess how Agile they are? Is there a place for "Extreme" or "Hyper" Agile in our vernacular? Is it a positive thing to have pockets of disproportionately high Agile maturity in your organization? What are you doing to drive an overall increasing Agile maturity?

Monday, April 7, 2014

Discord in Agileland

I've seen a lot of blog posts and articles circulating about how horrible the state of Agile has become. The central theme to these is that the term "Agile" has moved away from the principles that they established to the practices that are commonly used by "Agile" teams and organizations. I'd like to gently suggest that we not throw the baby out with the bath water.

Look, I totally get it. I really do. A quick glance at my own blog's history will tell you that I'm a huge advocate of sticking to the Agile principles and paradigm. Adopting practices, techniques, frameworks, or methodologies without internalizing the Agile Manifesto and its Principles is an exercise in diminishing returns (if any). However, it's also very difficult to ascertain how well an organization has internalized Agile into its culture. Like the saying goes, "The proof is in the tasting of the pudding," meaning that Agile teams do, in fact, behave differently because of how they've internalized Agile.

Theological Agility
"You will respect the sacred parchment" -- 5 reasons Agile is like a cult
One of the better blog posts that I've read on the subject was written by Dave Thomas, one of the Agile Manifesto's original signatories. In "Agile is Dead (Long Live Agility)", he writes, "Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, coopted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand."

People have exploited the agile brand to push their own agendas, that's for sure. All too often these days you meet someone trying to sell a practice or approach who can't name more than a couple of the Agile Principles (if any). I have personally trained people on Agile who had "heard so much about it", yet had never heard of such a thing as the Agile Manifesto.

So yes, we do need to work on getting back to our roots. However, that does not make all practices and approaches evil. This way of thinking is way too theological for an approach that must be practically applicable.

Making a living off of changing people's lives is not a crime against Agile. Furthermore, there are some practices that have existed for long enough that I would consider a team to be un-Agile or a low-maturity Agile team if they weren't doing them.

By their Fruits
By their fruits ye shall know them - Agile Teams have Agile practices, produce quality value, and are happy!
In his blog post "The Corruption of Agile", Andrew Binstock writes about the evils of building a brand off of Agile. He states that teams can be doing Agile practices without being Agile, and they can be Agile without doing Agile practices. My confusion is: how do you know a team is Agile if they aren't acting Agile? Practices such as TDD and Continuous Integration enable the team to deliver the values stated in the Agile Manifesto and its principles. If a team's not doing them, what are they doing to get there? Do they inspect and adapt on a regular basis? Are they striving to deliver something to their customers every 2 weeks to 2 months (with a preference for the shorter timescale)? How do you know they are Agile if their practices aren't Agile?

Agile practices can be a good gauge for a team's Agility. I do not advocate their use as the only metric of Agility, but they provide a good starting point for assessing a team. If a team is using Scrum and has implemented TDD and Continuous Integration, it's going to take a fair amount of convincing for me to believe they aren't "Agile", for how did they get to that point if they weren't continuously improving? Perhaps they were Agile at one time and had grown stale, but there is certainly evidence that they were at least Agile at one point in time.

Keep an Open Mind
Do we need to focus on our roots, the foundation of Agile culture that will breed lasting success in our teams? Absolutely! Our people should be consistently reminded of what it means to be Agile to ensure they are adapting towards greater Agility instead of away from it. Are people who introduce practices, approaches, and techniques that enable and empower a team to become more Agile inherently evil? Absolutely not! A team that understands what Agility is can tell when someone's trying to pull one over on them versus a person who genuinely has their best interests at heart.

I love going to conferences and learning about the latest and greatest in the Agile world. I love being a part of a community that is so obsessed with making people's lives better. I love the healthy debate and pragmatism that comes with experience. And I loathe those who are clearly pushing their own agenda without a reality check or an understanding of what Agile is really all about. I think it's time we took a more measured approach to our criticism, understanding that not all Agile consultants are wolves in sheep's clothing; indeed, more of them than you think are just trying to make the world a better place.

Friday, April 4, 2014

Favorite Agile Principle

There's been a lot of buzz lately in the Agile community about how far we've gotten from our roots. Most of the talk is around the evils of associating specific approaches with Agile; some have gone so far as to say if you advocate a practice as standard for Agile then you've lost your compass. I have some ideas brewing around those ideas. In the mean time, I thought I'd throw out a positive post to encourage people to get back to their Agile roots. My question is simple: What's your favorite Agile Principle?

Mine is easy: "Simplicity -- the art of maximizing the amount of work not done -- is essential". This principle is elegant and so applicable to my life. I am constantly over-complicating my life, so I've made this principle my mantra to keep me in check.

I understand that all of the Principles are important, so don't get hung up on the question. I'm not asking which one is best or most "Agile", I just want to know which is your favorite.

If you need a refresher, they can be found here:
  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity--the art of maximizing the amount of work not done--is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Wednesday, April 2, 2014

Introspective: Where are the Introspectives?

I mentioned a couple of weeks ago that I was going to try out LinkedIn's publishing tool. I've really enjoyed using it, so I've decided to keep this blog to more technical subjects and use LinkedIn for more general advice and introspection. I'll continue to blog here for the foreseeable future, especially on Agile topics that are too technical for a broad, diverse audience. If you'd like to follow my posts on LinkedIn, you can find them on my LinkedIn author page.

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.