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.

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.