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" (, 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.


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.

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
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.

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!

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.

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.

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.

Wednesday, February 26, 2014

Introspective: Conversation Framework

We're all just faking it and hoping everything works out.
What's in a Number?
For at least half a year now, there has been a growing movement in the Agile Community for #NoEstimates - the concept that estimating the size of your work, regardless of method, is detrimental. The idea is intriguing and thought-provoking, which automatically gives it some degree of merit among those who are constantly striving to push the boundaries of Agile. The thoughts on the subject that most resonate with me on this subject come from Dan Mezick of Open Agile Adoption fame and Valerie Santillo, a blogger I met last year in D.C. and have kept in touch with since. What both of these thought leaders have said is that the conversation that leads to the estimate consensus is the most valuable aspect of the estimation process, and that great care should be taken to maintain that learning process.

The question then becomes: can you have a learning conversation and reach some sort of consensus as a team without an estimate to trigger that the consensus has been reached? My intent here is not to answer the question, but to illustrate how powerful this concept - using a conversation geared towards achieving consensus as a framework for learning - can be in practice.

Meetings, or Games?
Dan Mezick describes this consensus-driving conversation framework in the context of gamification. He posits that all meetings are games, and uses Jane McGonigal's definition of good games to show that meetings are ineffective because they are broken! A good game contains: a clear goal; clear rules; a way to get feedback; and opt-in participation. In a later post, Dan details How Games Deliver Happiness & Learning by putting gamification in terms of senses: a sense of control; a sense of progress; a sense of membership and community; and a sense of higher purpose and meaning.

Estimation as a Game
I propose that Story Point Estimation, particularly the Planning Poker approach or similar, meets the criteria for a good game as stated above. First, there is a clear goal: to agree on the "bigness" of each User Story. This is where my concern with the #NoEstimates movement comes into play, though I'm definitely open to their alternatives. Second, there are clear rules; the team has a Definition of Done for each Sprint, and each User Story has Acceptance Criteria to help the team understand what the User Story is (and isn't). Third, there is a way to get feedback through both conversation and revealing of Story Points. Conversation, in theory, would be good enough. However, experience has taught us that assumptions not stated in the initial conversation are revealed when discrepancies emerge as Points are shared. By having disparity in estimates, we are providing feedback that our assumptions differ. Fourth, the participation is opt-in - or, at least, it should be. Estimation should be done at a time and for a duration that the team agrees to. Nobody on the team should feel like they are being forced to participate. If there are, the Scrum Master or Agile Coach needs to step in, mine for conflict, and find out why the team member is disengaged so that the team can fix it.

Now let's look at it in terms of senses. First, there's the sense of control. The process of Planning Poker should, again in theory, prevent the process of estimation from being dominated by a loud minority. Every participant should feel some level of control over the direction of the conversation. Second, the sense of progress. As votes are cast and the numbers converge, we feel like we are nearing our goal for each Story. On a deeper level, we're growing closer as a team and gaining a more in-depth understanding of the system being built, which provides us a feeling of accomplishment and satisfaction. Third, the sense of membership and community, which should have been fostered prior to the activity and is reinforced throughout the conversation. Finally, the sense of higher purpose and meaning. This sense is driven by the nature of the work being discussed and estimated; a team that isn't opting-in may not feel this sense.

Every Meeting as a Game
What I've just walked you through are the conclusions I've started to form about how ALL conversations should be structured. It's the context with which I constructed the training material for the senior management that my fellow Coach and I were tasked with training on Agile. We started with the goal: how will each person change their behavior as a result of the paradigm shift we take them through? The mechanism we chose was the 5-Spoke Wheel Retrospective that we would end the training with. Starting with the end in mind, we created a framework for having the participants discuss the Principles of Agile and the Themes of Product Development Flow that would result in them debating with each other and examining the work they do on a daily, weekly, monthly, quarterly, and annual basis. As facilitators, we spoke for about a quarter of the time, opting for audience participation and group teaching instead.

I was shocked and amazed with not only how smoothly the class ran with so little structure, but with the amount of positive feedback we got afterwards! I then thought back to my early days with my first Scrum teams, how they would talk about how little time they spend in meetings now that they've gone Agile. When questioned about their Daily Scrum, Story Time (Backlog Grooming), Sprint Review & Demo, Sprint Retrospective, and Sprint Planning meetings, they would respond, "Oh, we don't really think of those as meetings; they're more active group conversations."

Framework for Success
Personally, I like Story Point Estimation and will continue to use it as a tool to help people bridge the gap from traditional (Waterfall) project structure and more Agile approaches. If they decide to do away with estimation altogether and can do it in such a way that the valuable conversation is not lost, I say go for it. I will also begin to encourage everyone to take a gamification approach to meetings with the goal that people not only look forward to them, they are insulted at the insinuation that their conversations are called "meetings". After all, meetings are dull, pointless, no-fun snooze-fests!

Wednesday, February 19, 2014

Introspective: Recognition and Servant Leadership

Every February, my company has a host of Year Beginning Meetings (YBM - our fiscal year runs February through January). Within IT, we have several YBM activities. First, we have our pillar celebrations (we are a matrixed organization). Then we have a half-day General Session and a day-long Tech Fair. A huge part of all of these activities is recognition. There are a variety of awards that are presented to teams and individuals at the pillar and division levels, usually chosen by the award's respective management team. I love the emphasis on recognition, but I went into my pillar's celebration today wondering how you balance recognition with servant leadership.

I wasn't expecting to get an award, but I was thinking about what it would mean if I, who spent the entire year as an Agile Coach and Servant Leader, was chosen for an award by management. Shouldn't the recognition be focused on the team I worked with? More importantly, what would happen if I were selected for an award and my team wasn't? I would feel like a complete failure! What would it say about me if my management team thought I was deserving of one of the relatively few individual awards, yet my team didn't do enough to merit an award? I honestly didn't know how I would feel about it.

As it turns out, my team didn't win any awards. I'm going to brush past that for now, because I feel that they were truly deserving. As it also turns out, I won an individual award. It was an award that I sincerely did not expect to win - I was on my laptop with the company's internal social network pulled up and providing updates from the meeting when they called my name. It was also the only award I could have received in the absence of a team award that wouldn't make me feel like a failure.

Pillar Associates' Choice Award - the most meaningful award to me.

I won my Pillar's Associates' Choice Award. That means that, of the 250 people in the pillar that actually voted, I received more votes than anyone else. I don't know how many people voted for me, but the important thing is that it was chosen by the people. This wasn't something that management got together and decided to award me with. This award was selected by the people I was serving. I could not be more flattered and touched by any other award presented today.

What makes this particularly poignant is that I am in the process of transferring to another team in another pillar, and most people in my pillar that know me knew about my transfer prior to voting. They were willing to vote for me even though they knew I was on the way out. My six-year anniversary is in May, and I have spent my entire career to-date with the same team. Bittersweet does not quite capture the mixture of feelings that I'm experiencing, but it's as close as I can get.

I know I'm supposed to come up with something actionable out of this rambling, sentimental, nostalgic introspective, so I'd better get to it. I want to never forget this feeling, the feeling that I have succeeded as a Servant Leader in touching the lives of those whom I've served. As I move from area to area, helping them safely adopt Agile, I will strive to approach each one as if they were the family of associates that I first served. After all, they are all people, and they all deserve it.

Wednesday, February 12, 2014

Introspective: Agile is an Arsenal, Not a Silver Bullet

I recently gave a presentation to my local PMI Chapter entitled, "Agile is an Arsenal, Not a Silver Bullet". You can view the visual cues I used at The point of the presentation was that Agile means the manifesto and principles, so when someone says, "We're going AGILE!" your first question should be, "What do you mean by that?" There are so many approaches and practices available that using the term "Agile" is not adequate. Further, it is possible to employ Agile techniques improperly to actually make the organization less Agile. You could also apply "surface level Agile", which is basically a facade for the status quo.

When I talk about "going Agile", I make it clear that I mean "Being Agile". I want people to understand the principles and paradigm that the original Agile Manifesto Signatories had in mind. I want them to understand why popular Agile techniques are so popular so that they don't misuse them.

One of the gentlemen who attended my presentation came up to talk to me afterward. He said he had some Agile horror stories that he intentionally didn't bring up as a professional courtesy. I promptly chastised him, saying that the horror stories would have illustrated my point! He took me out to lunch yesterday to talk me through one of them. Sure enough, they were stories of salesmen who came into an organization that was already on an Agile trend and shoved them into the mold he was familiar with. It was not an incremental change - heck, it wasn't even an improvement! It was nothing more than an off-the-shelf methodology with all the right buzz words. This experience left a bad taste in his mouth for Agile.

I've often said that the biggest hindrance to an Agile adoption is that people will think you're trying to sell them a Silver Bullet. When they do, they will usually react one of two ways: 1) they will jump in without fully understanding and have their unrealistic expectations shattered; or 2) they'll be smart enough to know there's no such thing and turn on Agile with precision cynicism. Invariably, when I explain to people what Agile really means and the importance of "Being Agile", people get it and buy in. They make it their own and take charge in their personal and organizational transformation. They build their arsenal and never settle for what they have.

Wednesday, February 5, 2014

Introspective: Dealing with Disruption

This post is going to be short, folks. I live in NW Arkansas, and we're in the middle of our 3rd-straight snow day. The odds are in favor of no school at all this week, and my RWD pick-up doesn't do too well on snowy roads. Consequently, I've been working from home alongside my wife and two children, ages 6 and 2. These have not been productive days for me, as I'm constantly interrupted by the realities of home life. Even locking myself in a room doesn't work for long because they eventually find me and harass the locked door until it opens.

I wonder if this is what some people feel like at work - people who are on multiple projects at the same time with a micro-manager. How do they ever get anything done? How much more could they get done if they were left to get their work done on only one thing at a time? And how much happier would they be while doing it?

Wednesday, January 29, 2014

Introspective: Follow-up to Kaizen Questions

I recently wrote a blog post about Asking Kaizen Questions. I saw an example of what may be considered Kaizen Questions on our KAT Board the other day. Let me explain.

We have a large glass board furnished with neon dry erase markers on one of our hallway walls. I don't know what it's official name is, but I call it the KAT Board because it is periodically erased and seeded with one or more questions from our CIO, Karenann Terrell (or KAT for short). Here's the question she posed earlier this month:

"What do you hope to accomplish in 2014?" -- KAT
Once the question is posed, everyone is encouraged to grab markers and write their responses. The other day I walked by and saw this:

"Excellence always. If not excellence, what? If not excellence now, when?"
I saw that and thought, "What excellent examples of Kaizen questions!" They provided a challenge to the status quo and some sense of urgency. I liked it, but I thought it was missing something. I'll come back to that.

Over the past week, I've seen varying levels of engagement at the personal, team, and domain levels, particularly with regard to Agile. As thrilling and exciting as it is to see someone pick Agile up and own it, it is equally frustrating to see someone wait for the organization to transform around them before they decide to act. To take it a step further, it is necessary for each person within a company to own the company's success. If they don't feel that they have a voice or don't see the importance of using that voice, they will eventually outlive their usefulness. Companies with engaged and empowered associates will pass up those whose employees are just there to take orders and get a paycheck.

So I went back to the board and added another question to help deepen both the sense of urgency and personal accountability.

"If not us, who?"