Agile Teams Need to Guard Against Self-Mismanagement

April 27, 2012

Scrum is an excellent framework that provides a team with the requisite structure to address the complexities and challenges of software development while remaining completely open in terms of defining what the product is and how it will be implemented. A key tenet with agile and Scrum is that the team is in control of their work, and a framework like Scrum provides the necessary guidance for teams to coordinate and manage their work without being directed by someone else.

As simple as a framework like Scrum sounds, execution is harder than it appears. One danger is that people start adapting Scrum to meet their current ways of working instead of changing the way that they work. For Scrum to be of value it is important to look beyond the mechanics of the framework and embrace the Lean and agile thinking and approach to work.

Improve the Flow, Don’t Interrupt It

April 24, 2012

Agile development teams exist for the most part in non-agile organizations, and all too often there are too few who understand the implications of this and how well-intended actions actually work against the mindset and techniques of agile development. This can lead to a watering-down of agile (Waterfall/Scrum hybrids come to mind) and a reduction in the benefits obtained as a result.

From a management perspective, agile development should not just about autonomous teams doing their “thing” independently. Those autonomous still need management support – but in a different way. Autonomous teams should be focusing on improving the flow of value to the customer and you as a manager should be supporting those who have direct responsibility for that delivery.

Agile development seeks to eliminate or reduce overhead while using tools and techniques that improve – or at least maintain – professional discipline to drive long-term productivity gains. Agile teams need to work be “in the flow” as much as possible to improve productivity, taking input from customers and internal stakeholders and converting that input into a valuable outcome for the least amount of effort expended. As a manager you must guard against doing two things: interrupting the flow and impeding the flow.

A Quick Example on How Going Slower is Faster

April 20, 2012

If you’ve ever been challenged to explain why you should consider adopting agile development, one good reason is that agile development – executed properly – focuses on all aspects of software development, from delivering value to technical excellence. This includes performing work that too often gets short-changed under intense schedule pressure: refactoring.

(This is an admittedly simple example, but it illustrates how focusing on feature delivery at the expense of looking at the big picture can hurt you in the long run.)

Let’s say that you are in a race. Both you and a competitor are vying to dominate a market with similar applications, and you are both starting from scratch. You are an agile development shop and your competitor isn’t; for them, cranking out the features is everything.

The picture below shows that your competitor establishes an early lead…

Don’t Hit the (Software) Wall!

April 17, 2012

Since the Boston Marathon was run yesterday, I thought this would be an appropriate metaphor.

Imagine running a 26.2 mile race… It’s a long race, but you’re prepared. You’ve run 20 miles every Sunday along with hill workouts and a variety of other distances during the rest of each week to be in the best shape possible. You start the race a little faster than you anticipated based on your split, but you shrug it off. You feel comfortable, so you keep going. You even ignore the early water stations. It’s a crisp, fall day, so heat is not a factor. Everything is in place for a great run.

Almost. The events described above were real. They happened do me. And I should have done things differently. I should have backed off my early pace when I got my split. I should have been taking in water. But when you are young and stupid (I was 20 years old at the time)…

I hit the wall. I started feeling odd at 18 miles, and by mile 20 I was done. The loss of energy and fatigue was sudden, and I had NOTHING left. I walked the remaining 6 miles, trying to find the strength to run every now and then, but I couldn’t. I finished in the middle of the pack, disappointed that I had run myself into the ground. I knew better, but in the moment of the race I thrust common sense aside and went for it.

Despite knowing better, organizations routinely run into the software wall all the time. We’re guilty of approaching work in the same way that has proven not work more often than it does, but expecting a different result.

Being Agile is Being Efficient and Disciplined

April 13, 2012

Is agile development chaotic and undisciplined, as some would assert? It shouldn’t be. However, using frameworks and practices don’t make you agile in and of themselves. They support agility, provided that you have the right mindset and approach to your work as you make use of them.

I’ll examine the following (briefly) in this post:
  • Scrum
  • Test-Driven Development
  • Pair Programming
A huge change with agile development is that teams are self-directed. Scrum is a great framework for teams to use to manage their work, provided that teams genuinely collaborate and actively manage their work. This means more than adopting the practices, vocabulary, and artifacts of Scrum. “Doing Scrum” without an agile mindset is also known as Cargo Cult Scrum, which is the mistaken notion that ritualistic actions and artifacts will provide magical benefits. Trust me, magic is not going to happen all by itself!

Software Development Workflow Shouldn't Mirror its Phases

April 11, 2012

(My apologies for posting a day late, but I’m in one of those cycles where I’m generating content just-in-time instead of having a good backlog ready. I paid for it this week, as I ended up very sick Monday evening and wasn’t able to make a Tuesday post.)

In the future, we won’t need to program computers. They will program themselves to perform whatever tasks we ask them to perform. Until that day arrives, we’re faced with doing things ourselves. So for now, we need to generate value by flowing through the standard development phases as quickly and easily as possible. With agile development we target delivering potentially shippable software at the end of every sprint, but NOT by working in a linear fashion:

It’s tempting to reduce work to its constituent parts and have specialists complete each phase in strict, gated phases where we sign off on the work before beginning on the next phase. We have evidence to support this approach, including studies that show how the relative cost to find and fix defects increases substantially at every phase.

Adapt and Improve Your Way Into Being a Competitive Force

April 6, 2012

As part of my Maine Agile User Group talk this week, I referenced a quote from management guru Peter Drucker that you don’t typically see or hear:

“Productivity means the balance between all factors of production that will give the greatest output for the smallest effort. This is quite a different thing from productivity per worker or per hour of work…”

This quote comes from his book, The Practice of Management, originally published in 1954. Unfortunately, another one of his quotes, “what gets measured gets managed,” is used and abused all too regularly.

As you can glean from the second sentence of Drucker’s productivity quote above, he was cautioning us about emphasizing the wrong things – and as the Principle of Suboptimization tells us – optimizing each part independently will not lead to an overall system optimization. In fact, it can worsen it. We need to be very careful about what we’re measuring and what behaviors we are driving with those measurements.

We’ve Been Approaching Things in the Wrong Way

April 3, 2012

Agile development is all about using multi-disciplinary teams to continuously deliver working software in the form of business features at the end of every sprint or iteration. This means prioritized features, not horizontal architectural layers. By that I mean that we don't build out all of the layers up front in one shot, speculating on what we might need to have in place to support future business features. We design and build what is required for the features that we are working on today.

Likewise, the merits of the empowerment model espoused by agile development have been known for some time in the business world, albeit largely ignored. Most organizations today strive for central control and compliance, whereas an effective empowerment-oriented management model assumes that those on the front line can not only call their own shots effectively, but are better able to respond more rapidly to changing competitive conditions.

The right management model requires that front-line teams have autonomy and critical information available to them to make effective decisions. There is a need to invert the organizational pyramid – or at least tip it on its side – so that business units who are focused on profitably serving and satisfying customers’ needs are being informed and supported by a leaner organization that is not imposing onerous reporting and control mechanisms on the rest of the organization.