Don’t Sell me Agile, Solve my Problem

Last Updated on Tuesday, 25 February 2014 02:04 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!

Top 10 Agile Blog Posts of 2013

Last Updated on Monday, 3 February 2014 05:05 Written by Torrey Dye Wednesday, 1 January 2014 07:58

As 2013 is coming to an end and 2014 is quickly slipping into view, we are bombarded by lists of the greatest, best and top things from the past year. To honor this sacred tradition of New Year’s list building, we at LeadingAgile have put together The Top 10 Agile Blog Posts of 2013!

#10 What allows agile to succeed in an organization? by Mark Kilby

For over 10 years, agile methodologies continue to prove themselves in a wide variety of industries and applications, yet I still get the following question from clients: Will Agile work for us? I still feel that an organization will be successful with an agile transformation independent of industry, size of the organization, geographic distribution of staff and other common claims of settings in which Agile “supposedly cannot, or should not work.” However, my colleagues at LeadingAgile and I have found that it can work if the right conditions are in place. These conditions are… Read More

#9 Barriers to Agile Adoption by Derek Huether

We’ve all seen it happen. Though we try to show organizations the benefits of using a mature agile delivery framework, we still run into roadblocks. Though the status quo is killing their organization. Some barriers to further Agile adoption happen far too often among organizations that need it most. I recently had a client ask me to introduce the elephant in the room. I was asked to actually list some common barriers others have dealt with… Read More

#8 The Organizational Death Spiral by Jesse Fewell

I’ve seen a pattern at a number of companies recently. It’s a pattern that demonstrates the danger of doing too many things at once. I call it the organizational death spiral.

Let’s say we have several product delivery teams in our organization, and that senior leadership have identified a handful of strategic initiatives that that are our next immediate priorities. Furthermore, let’s also assume that the estimates for each project add up to where we should be able to get them all done during the next quarter. Then we go on our merry way building new products and services, just as management asked.

However, we know that challenges happen. For example, most companies simply are not organized into purely independent teams that can churn out products all by themselves. There’s almost always some kind of dependency on another team for those design specs, some technical team for that fancy component, or some compliance team for full end-to-end behavior. Inevitably, this means at least a few teams have to shift their local priorities around on a regular basis in order to get anything done… Read More

#7 Structure 1st: Why You Should Not Start With Practices by Andrew Fuqua

Starting your agile transformation with a focus on practices is not an entirely bad idea, but with the wrong culture and structure, agile practices will be superficial. People will go through the motions. People will do agile things like have stand-ups, demos and planning meetings. You’ll have stories. It will look Agile on the surface. But that’s all it will be — looks. There will be no substantive change, no stable teams, no control over Work-in-Process, no empowerment and no predictability. You’ll have shallow collaboration, fault-finding and blame, and an unstable velocity. You’ll have no real support for Agile or for improvement. You’ll get limited value out of your Agile adoption efforts. So if starting with practices isn’t best, where should we start… Read More

#6 In organizational change, culture comes last by Jesse Fewell

We have a specific cycle for achieving organizational transformation. In short, to make real substantive change, you need to attack the following dimensions:

1.     Organizational Structure

2.     Processes, Practices, Policies

3.     Cultural Beliefs

…in exactly that order. That’s right; when you go to change an organization for the better, you need to do the culture part last… Read More

#5 Cheat Sheet for Backlog Refinement by Derek Huether

The purpose of backlog refinement (grooming) is to make improvements to the product backlog. Though there is no official ceremony detailed in the Scrum Guide, the activity of refining the Backlog is detailed. Backlog Refinement is a collaborative effort involving… Read More

#4 Getting Teams to Deliver Predictably by Derek Huether

As recently as this week, I’ve been involved in conversations with customers about how we can help make their teams deliver more predictably. How can they meet commitments on all levels of the organization, including project, program and portfolio?

Well, it’s not easy. There is no silver bullet that is going to allow you to align the organization overnight. I do, however, have one recommendation: stop trying to maximize the utilization of your people… Read More

#3 Stop Writing Code You Can’t Yet Test by Dennis Stevens

Most of the organizations we engage with have more work to do than they can possibly get done. So, developers are writing code as fast as they can to get done, trying to maximize their capacity. Typically, we see developers running way ahead of testing. Often, testing is still working on the prior release while development is running off on the next release – and testing just can’t ever catch up. This inventory of untested code shows up as long lists of defects, lots of code branches, untestable features and products that can’t be integrated or regression tested until just before the next release. This vicious cycle of long bug lists, painful regression testing and production defects colliding with the next release continues to grow. The goal is not to write code faster. The goal is to produce valuable, working, tested, remediated code faster… Read More

#2 Agile Health Metrics for Predictability by Andrew Fuqua

When deciding what to measure, the place to start is with a goal. First, ask yourself what outcomes are you seeking. These are your goals. Then consider what is needed to meet those goals. Finally, determine what metrics indicate whether you have what you need.

People we work with tend to care about predictability, early ROI, improved quality or lower cost. Predictability seems to be paramount. They want teams to get good at making and keeping promises, consistently delivering working, tested, remediated code at the end of each sprint… Read More

#1 Agile vs. Waterfall by Dennis Stevens

These words have become completely overloaded when discussing product development. Lots of conversations about helping organizations improve their product development processes go sideways based on individual perspectives about the meaning of Waterfall and Agile. At this point these words don’t provide a distinction that is helpful when we are trying to figure out how to build products in organizations. It’s a red-herring contradiction. When I hear someone say, “We need to do that Waterfall” or “That wouldn’t work in Agile” or “We can use Agile for that project,” then I want to stop and ask, “What does Agile mean to you?” or “What do you mean by Waterfall?”

I want to break down this debate into a clearer discussion around specific characteristics: Type of Effort, Upfront Planning, Sequencing and Feedback, and Composition of Teams. Then I want to talk about how understanding these characteristics helps us improve the ability to be predictable and achieve the fastest time to ROI… Read More

Cheat Sheet for Backlog Refinement

Last Updated on Saturday, 2 November 2013 04:02 Written by Derek Huether Saturday, 2 November 2013 04:02

What is it?

The purpose of backlog refinement (grooming) is to make improvements to the product backlog.  Though there is no official ceremony detailed in the Scrum Guide, the activity of refining the Backlog is.

Who does it?

Backlog Refinement is a collaborative effort involving:

• (Optional) facilitator – (like a ScrumMaster) keeps the session moving toward its intended goal
• (Optional) representative(s) from the Management Team – clarify the high level priorities
• (Mandatory) representative(s) from the Product Owner Team – clarify the details of the product backlog items
• (Mandatory) representatives from the Agile Delivery Team – define the work and effort necessary to fulfill the completion of agreed upon product backlog items.  It is recommended to have at least one developer and one tester when refining the backlog, to ensure alternate viewpoints of the system are present.

When is it?

Before development of a user story in the current sprint (iteration), generally sometime during the previous 1 or 2 sprints, the team sits down to discuss the upcoming work. Do not wait too late to add details, because the delay will slow the team down. Do not refine your stories too far in advance, because the details might get stale. Depending on the delivery rate of your teams, you should be meeting once or twice a week to review the backlog.

Before You Begin

We need to ensure:

• The product backlog is top-ordered to reflect the greatest needs of Management Team and the Product Owner Team
• Candidates for grooming include stories identified as not ready to complete within the next sprint or will require multiple days of research
• Epics, features or other items on the Management Team roadmap are reviewed periodically

The Backlog

The product backlog can address anything deemed valuable by the Product Owner Team. For the purpose of sprint planning, when using Scrum as the delivery framework, product backlog items must be small enough to be completed and accepted during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner team. 

Estimate

Backlog items must be completed in a single sprint or split into multiple user stories. While refining, give stories an initial estimate to see if they are small enough. If not, split them. The best way to split product backlog items is by value and not by process.

Acceptance Criteria

All stories require acceptance criteria. Without it, you can not define the boundaries of a user story and confirm when a story is done and working as intended. Ensure acceptance criteria is testable.   This is what your testers should be writing tests against.

Rewrite Written Stories

Ensure the user story format is consistent, INVEST criteria is being met, and is written from a business not technical perspective.  Know who the customer is. It may not be an end user. Rather, the story may be for something like a service, to be consumed by another team.

Image Credit: Pictofigo

Enabling Distributed Agile Teams

Last Updated on Tuesday, 1 October 2013 01:51 Written by Tim Wise Tuesday, 1 October 2013 01:51

Recently, I was invited to talk about enabling distributed agile teams for the Atlanta Scrum Users Group.  It’s a fantastic group… about 70-80 people made it to the show.

Before getting into the details, I have to admit that I do have a point of view on distributed teams.  I’m biased.  I had to put myself into a certain “middle of the road” point of view where I was neither for nor against distributed teams.  I am so glad I can do that (it’s a talent), because I was able to let this session change my own viewpoint.  I attempted to drive toward a shared understanding among the group as to how we could better understand the challenges of distributed teams and how to accept them — not working for or against them. Here’s the entire presentation:

I began the session with a brief definition of distributed teams.  I defined them as: Distributed teams are teams that have something preventing them from collaborating in person and face to face.  

After the definition, I discussed common complications of distributed teams with the audience.  I drove toward macro level complications like language, trust, and working in different timezones. Then we discussed additional complications that the group came up with.  The interesting part is that I had to drive the group back to the macro level.  It’s easy to jump to solutions.  ”I used this structure and it worked.”  It’s also easy to jump too far down the rabbit hole.  I wasn’t interested in that.  I wanted to know the high level complications.  We came up with a few more examples of pain points, like corporate enablement (do they have the access to files that they need), culture, etc.

Next, I facilitated a 20 minute game session where two games were played.  Before playing, we split up the crowd into teams that equally represented people who work in distributed teams every time, those who never work in distributed teams, and everyone in between. Each team contained a sampling that represented the whole spectrum.

The first game we played is called the Negation Game.  The idea is to have four different scenarios to represent common distributed team structures.

• Team augmented with an offshore resource
• We are the augmented team members in the US for a resources-based team in a London project
• Each team member is a distributed resource
• The individual has a paired twin resource that is distributed

During the game, I gave a scenario to each of the teams.  They were charged with asking the question, “How can we make the resource’s life miserable and less productive?”  After a brief session of answering that question, the team members prioritized their results.  I then visited each scenario and negated the top two prioritized items.  This led to what could be potential “working agreements” like “The team will not schedule meetings when the distributed team is asleep.” I am paraphrasing because I didn’t take a picture of the output of the teams… boo… next time.  Click here for the complete list of game images.  Here’s one for context.

Negation Game – Foreign Team where we are the Augmented Offshore Resources

In the second game, King for a Day, I had two teams imagine they were CIO’s considering outsourcing.  One team took why they would like to outsource and the other took why they wouldn’t.  They discussed for about 5-10 minutes.  They prioritized their results.  When I traveled to these two boards I had a realization and ran with it.

The team that had the “Wouldn’t consider outsourcing” scenario had come up with the traditional “complications” that we had partially discussed.  They came up with a few more in the game and some common issues with distributed teams like “they need more documentation up front.”

The other team came up with Business Needs like “Global workforce for hiring”, “lowering costs”, etc.

The place we ended up was fascinating.  I could relate the complications back to a business driver.  Basically, if our complications were worth less than the business driver, we should rightly be distributed.  It was powerful.  It also quickly disarmed the “business is outsourcing all of our jobs because it’s cheaper” notion.  That’s often not the case, anyway.  However, the business intent became apparent even in our fake business scenario.  Good stuff!  Maybe this would be a good way to have teams with outsourcing needs accept it more readily.  Again, I’m not an advocate — just pragmatic for the business.

Here are the game pics for King for a Day:

King for a Day Game – CIO wants Outsourcing

King for a Day Game – CIO does not want Outsourcing

After the games we discussed several enablers we could implement like the communication kata.  I went over a few tools that I know that are collaborative whiteboards, mindmaps, etc.  That seemed to hold the attention of the crowd.

This talk focused on enabling distributed teams, and I am of the opinion that although structure is important, most structures can be successful in certain contexts.  It’s a tool in your toolbox — you don’t always use them — but it’s nice to know that you have them if you need them.