Managing the Impossible with an Agile Budget

Last Updated on Tuesday, 1 April 2014 08:13 Written by Isaac Hogue Tuesday, 1 April 2014 08:13

The Agile Budget

Release planning is without a doubt one of the most challenging responsibilities for agile teams… at least that’s what I’ve experienced both personally and while coaching enterprises through transformations.

Most teams are working to deliver solutions where the question of “what will I get” at the end of a release can not be left open ended. Furthermore, these teams don’t have an unlimited capacity. They are working within what appears to be a constrained iron triangle, cost, time and scope are all fixed. Mike Cottmeyer’s recent blog about the agile home builder, discusses this challenge from the perspective of establishing a categorized budget.

It is an approach that I’ve seen work on several occasions.  The process is pretty straight forward, not easy… but also not complex

Here’s a script that I like to use to help move teams from “this is impossible” to, “hey I think we can deliver!”

Getting Started

Before determining how much of the budget should be spent on features, its important for the team to understand the goal of the eventual release.  To help with this, I usually encourage the team to form of a mock press release, announcing their successful release to the world.  Typically this includes key areas or attributes of the release that have made the release impactful to the reader. These are now key success areas for the release

Establishing your Budget Categories

Each of these key success areas start to emerge as high-level categories within the context of a releases budget that can be used to help focus initial scope conversations. From here the key stakeholders can allocate their budget across each of the category areas.

Quick sidebar, the asset that is available for budgeting is usually the delivery system’s planning velocity.

Keep your Eye On the Ball (successful release, budget available)

Now that budget categories are set, the teams need to start working through their release plans and refining their needs for the “right” implementation based on the budget available.  There are many methods for going about this process; but, by far my goto method starts with high-level acceptance criteria for each category, or feature area, that can be clarified through a mix of example user journeys or system interactions. The funds available to each of the categories should be brought down and further applied to each of these so that the planning team remembers to keep its eye on the ball.  A successful release will need to both (1) deliver the functionality needed, and (2) live within the budget that is available.

This is key, without a focus on the budget available (cost) most teams will struggle to limit the scope of a release until its too late. Early budget constraints help to drive out scope that is not critical to the success of a release.

What do you think, what are your favorite ways to vary scope to successfully deliver on previous market commitments?  For more on this topic, take a look at an earlier blog about calculating the budget, in cost, for agile teams.

Redefining Heroics

Last Updated on Wednesday, 26 March 2014 09:36 Written by Tim Wise Tuesday, 18 March 2014 10:25

Recently, while working with one of our customers the topic of heroics came up… okay, this comes up all the time

It seems hard to argue with heroics, from the time we were young we’ve heard stories of heroes in our family tree or national history. The term is attributed with acts of valor and selflessness.

Upon closer examination, frequently we find that the heroics that are being described in many enterprises could be better attributed with undisciplined, or even un-intentional delivery….

How do you define a hero in your business?
How does your business define a hero?
How do you reward the heroes?

A bunch of companies define a hero as someone who swoops into a project to save the day. They work a ton of overtime and get the job done by slaying the vicious dragon. They are capable of quickly stitching up a troubled problem just enough to get it to market.

It’s time for this paradigm to change.

When transitioning to agile there is a high value placed on one of the 12 principles of agile development, the indefinite, sustainable pace. Given the traditional “hero”, we immediately have a conflict. So let’s change the definition of the hero.

Heroics Redefined

• What it is not:
  • working overtime
  • being the goto guy
  • taking over for others
  • saving a project at the last minute
  • the number of bugs you find
  • the total lines of code you write

• What it is:
  • Sharing in successes and failures with the team
  • Practicing commander’s intent by helping the team generate new ideas of how to achieve a goal with an unknown path.
  • Demonstrable selflessness in self promotion
  • Creating a new team option by developing a new Generalist skill
  • Reducing team cycle time

This blog was co-written by Isaac Hogue.

Top 10 Negative Personas of a Daily Standup Meeting

Last Updated on Wednesday, 16 April 2014 02:08 Written by Derek Huether Monday, 17 March 2014 08:49

Agile teams should be holding a daily standup meeting.  Don’t think of it as a daily planning meeting. Think of it as a daily opportunity to have a shared understanding of what is getting done and what lies ahead.  During a daily standup meeting, participants sometimes exhibit negative personas that will detract from the meeting.  As an empowered team, it is your job to self-manage and encourage good behavior. Some of these behaviors are so common, we don’t even realize people are doing them. So, I’m giving them some names. Next time you hold a daily standup, see if anyone exhibits any of these 10 behaviors. If you think of some behaviors  that should be added to the list, I would love to see them.

Daily Standup Meeting Negative Personas

10. Pat Decker the Obsessive Phone Checker

This person does not always pay attention and is constantly look at her (or his) phone. Did a BFF just like something? Did someone on Twitter just favorite that pic of the team board? In addition to checking her phone, she likes to share what she sees with others during the standup. “Pssst, Bob, check out this Vine video or pic on Instagram”. She’s not so loud that she’s overly disruptive but now Bob missed what someone else said during the standup.

9. Stephen Craig who is Always Too Vague 

This person can get stuck on the same task for days but doesn’t want anyone to know. When speaking to the team, they are crazy vague. Stephen will offer very few details until the team pushes for a deadline. He (or she) will use language like “Yesterday I was working on task 123 and today I will be working on it some more”. No other information is volunteered. When asked if they need any help, they clarify they have no blockers or risks.

8. Bobbie Bainer the Team Complainer

When the attention is on Bobbie, get ready for the positive energy to be sucked right out of the room. Bobbie complains, complains, and complains some more. Management, teammates, or the technology is all fare game. Everything and everyone sucks and no one knows just how bad they have it. Don’t bring up religion or politics unless you want Bobbie to go right into a 20 minute tirade.

7. Jess Jewler who loves the Water Cooler

Jess comes to the daily standup to talk, but not about what needs to be done today. Instead, he or she will talk about just about everything else. The next 15 minutes is dedicated to the water cooler. Did you see the last episode of House of Cards or The Walking Dead?  Are you going to watch the Ravens play this weekend?  My son plays Minecraft and constructed this totally awesome building with redstone. Anything is fair game, as long as it’s not about work.

6. Billy Platitude with the Bad Attitude

Billy is a leftover from a bygone era. He was the best of the best mainframe developers and all he needs is a DLD and he’ll give you what you need… in a few months. You want any changes between now and then? Forget it!  He thinks all things agile are stupid and just plays along begrudgingly. You may catch him make cynical “funny” comments at standup to point out how right he is about how stupid agile is.

5. Will Funky the Non-Committal Junkie

Will does not want to be painted into a corner. Typically, he uses language like try, maybe, pretty sure, I’ll get back to you, we’ll see, would like to think, soon, almost. You’ll also see Will be the last person to comment on something and will usually go with the crowd.

4. Tom Mater the Specialty Updater

Tom only gives vague commitments, usually understandable only by those in his discipline. The overall team gains little value from the statements. If you ask him for details, he’ll either tell you to look it up in a tool or he’ll be very technical in his response. Half of the team doesn’t understand what the hell he’s talking about.

3. Drue Gru who thinks he’s Better Than You (and the team)

Drue has been around for a long time. He’s better than you and he knows it.  If you need him, you know where to find him. He either arrives to the standup meeting late or he doesn’t come at all.  He has little to say because you wouldn’t understand what he’s talking about. He already knows everything so what is he to gain by slumming with you and the team for 15 minutes? Let him know when something important happens. *sarcasm*

2. Pearl Revolver the Problem Solver

Pearl means well but she lacks a sense of time. She wants to have in-depth problem solving discussions on obstacles identified during the standup meeting. She’s very curious what issues others are having because she’s going to want to talk it out and fix it right then and there. Even if there is a reserved 15 minutes after the standup, Pearl figures there is no better time than the present to tackle a challenge.

1. Ian Krumpter the Interrupter

Do you listen or do you wait to talk?  Stop and think about that. There is a difference. Ian waits to talk. People can be binary in that way. If you’re talking, you’re less likely to be listening. He wants to prove just how awesome he is so you’ll see him interrupt even if the topic doesn’t really apply to him.

Don’t Sell me Agile, Solve my Problem

Last Updated on Wednesday, 16 April 2014 02:18 Written by Tim Wise Tuesday, 25 February 2014 08:08

A while back I was invited to the AITP Atlanta Chapter for a CIO roundtable discussion that involved questions on agile. The event was a great success and I came away with a bunch of great insights into what topics are on the minds of today’s CIO. One statement that night has really stuck with me.  A wise, retired CIO told me, “Don’t sell me your solution, solve my problem.”

That statement further solidified my belief that I am not “implementing agile” (hang with me), but rather I am solving a problem or a set of problems that commonly occur in enterprise environments.

We don’t sell vials of snake oil. Here’s why that may be the perception.

Let’s consider the state of affairs for a moment. When I get the opportunity to have a discussion with a new organization, the person I am talking to needs me to solve a problem. They might not know anything about agile, scrum, kanban, or any other process. Alternatively, they may have experienced a poor implementation and have an immediate bias to any of the “agile” words (i.e. sprints, daily scrums).

If I am selling them something, I genuinely want to solve the problem, not implement agile. That allows me to be a pragmatic partner with knowledge of agile systems that can benefit my customer. It breaks down zealotry and keeps me honest.

In the end, I am directly and intentionally not talking about agile, scrum, kanban, or lean or anything else that is under the agile umbrella. I simply want to know, what is the most impactful issue that their enterprise is facing right now in their unique context.  Can I solve it?  No, but we (myself and the enterprise) can. It must to be a partnership though to be an effective sustained transformation.

Here’s the catch. Most, but not all, issues will fall into one of several categories.

• Time To ROI
• Predictability
• Quality
• Adaptability
• Economics

Though categorically these problems are recurring across many business enterprises, the underlying causes can be a complex, interwoven gobbledygook of methods, procedures, and people.

That’s why it’s important to listen and offer up expertise when you understand the problems. It’s an engaged dialog that I am targeting to create a shared understanding of their problem so we can work to create a vision of our solution.  I’m not there just to lend an ear.  That’s why I need all this experience stuff.

Speaking of experience, I have found commonality among the solutions for each of the categories listed above.

Let’s take Predictability.  In order to become predictable, most organizations will need to learn how to systematically decrease batch size, reduce WIP at the enterprise and team levels, and stabilize teams. Inherently, this will increase quality and decrease Time To ROI.  To further improve those, I will need to run experiments on their unique context.

How do they begin to get predictable?  That’s what they need help doing. It’s what scaling agility is really all about. Getting more value out of the system to decrease time to ROI and predictably make and meet corporate goals.  Informed, predictable returns on investment.

At my core, I believe a predictable system is one that we can run experiments on and get most other problems solved.  That’s my key to unlocking the shared potential of both parties.

Starting Your Agile Process Engine

Last Updated on Tuesday, 11 February 2014 07:18 Written by Derek Huether Tuesday, 11 February 2014 07:18

I read an interesting exchange on Google+ about Agile process transformation successes and failures. Here is one of the comments. Tell me if it sounds familiar.

My previous employers had big problems with Agile. Attempted to use it multiple times and had a nice failure rate of 100%. As far as I know, they are trying again. I’m rather curious. Would be interesting to know how it turns out this time.

It’s hard to say this but I believe it’s ok if they’ve failed a few times, if they understand why and what needs to change this time around to be successful. Usually, they first need to become better planners and more predictable. The recommendation usually catches people off guard.  I’ve interacted with Agile zealots who believe that doesn’t sound like Agile. Personally, I don’t care if it sounds like Agile or not, if we’re able to get teams to deliver consistently over time when others can not.

If you like it or not, I can pretty much guarantee that company mentioned above will fail again, if they don’t have the proper organizational structure, governance, and clearly defined criteria for progress and success.  In other words, their agile process engine is going to stall.

Priming the Agile Process Engine

Beginning an agile process transformation is like trying to start an old vehicle on a cold day.  To add complexity, that vehicle has a carburetor and manual choke knob.  If you’re old enough to remember carburetors and chokes, you’re either going to smile or wince thinking about starting a “cold” engine. The important thing to remember is if you don’t do the proper sequence of events, given the current environment, you’re going to stall.  It could take an experienced driver only a few seconds of asking you questions to figure out what you did wrong and tell you what you need to do. Still, being told what you need to do is just treating a symptom. You, as the proverbial inexperienced driver, will need to learn new skills given the environment.  It takes time, persistence, and finesse.

Carburetors and Manual Chokes

When it comes to running gas powered engines, the only things old vehicles have in common with new ones is they all need a spark and fuel delivery. Getting a new one started is much easier, thanks to a complicated series of electronics, while starting an old one is dependent on what the temperature is and how well tuned the ignition might be.

If you’ve never started a car built before 1990, you need to realize that just turning the key won’t get the engine running. All it will do, especially if it’s cold, is crank away until the battery is dead as a door nail. Instead, you need to set the choke to allow the engine to suck in lots of raw gas so some of the vapor will ignite.

If your old car had a choke knob, you pulled it out to close the “butterfly” valve on the carburetor (this limits air intake, thus allowing a far greater fuel-to-air ratio).

I know this may be way too mechanically nostalgic or geeky for some but bear with me.

Now it’s time to start her up. With your foot pushing the gas pedal down about half of the way, crank the engine until it fires. It will usually start running, but rather rough. As you give it some gas you can slowly push in the choke knob until the engine smoothes out. 

If you do it wrong, you’re going to flood the engine and you’re going to stall.  The same goes for an Agile process transformation.

The Agile Process Transformation

When you decide you’re going to transform your organization, don’t just jump into the driver seat, crank on the starter, and put your foot to the floor. It’s not that simple.  For a car, you should be thinking about how long it’s been sitting or how cold it is outside.  What is the current environment and state of affairs?  For a transformation, you want to do some form of Agile adoption assessment.  Understanding the current environment allows an experienced coach to know what the next crucial steps will be to ensure you don’t stall.  Next, you’re going to want the proper organizational structure and governance in place.  That’s right, you need to know the rules of the road.  Lastly, you’ll need a system of measurements (metrics) in place to provide feedback and know when your transformation engine is warm enough or if your fuel to air ratio is still off.  Are you giving it too much gas?  Are you going to stall?  Do you have both hands on the steering wheel at all times?

As an experience driver, you’d listen very closely to the sound of the engine as she tries to turn over. You’re prepared to either pump the gas pedal or adjust the choke knob. If you smell gas, you know it’s time to curse and let the engine sit a while because you just flooded the engine.  More often then not, the experienced driver can react quickly because they’ve been through this before. It’s easier for an experienced driver to do it, then describe how to do it. Enterprise Agile coaches are experienced drivers.

Agile Process Test Drive

When I was in high school, I took Drivers Ed.  I sat in a classroom, reading book about cars and driving.  Regardless of how much classroom training I got, it was really just teaching me the basics. Once I jumped into a simulator, I realized how complicated things could be.  Here’s the kicker.  The simulator was a controlled environment.  Everything I learned up to that point got shelved, as soon as I got behind the wheel of a real car.  There were so many variables!  Not only did I have to figure out how to start the thing, I had to figure out how to accelerate and shift gears.  I had to learn how to avoid that old person in the left lane who’s had the right blinker on for the last mile.  And yes, in my youth, I crashed the car more than once.

Working with Agile teams is no different for the coach or the client.  It doesn’t matter how many certification classes you take, it doesn’t matter how many workshops or conferences you go to, nothing can compare to being on the ground with a team and having a client who is insisting on results.

Some Free Advice

When you were a kid, trying to start that 1979 AMC Pacer for the first time in 45 degree weather, you listened to your Dad or whoever when they warned you about the manual choke and what to be mindful of when you were ready to turn that key.

Tips

1. If you think you’re ready for an Agile process transformation, get an Agile adoption assessment.
2. Be prepared to change your organizational structure.
3. Get ready to harden up your ALM governance.
4. Identify metrics that are going to provide you feedback as to conditions on the ground.
5. Don’t text and drive!