Top 10 Agile Blog Posts of 2013

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