The Agile Architect

Getting Things Done the Agile Way

Our Agile Architect talks about how to get things "done done."

• By Mark J. Balbes, Ph.D.
• June 18, 2015

Part of my responsibilities at my job is to help other companies become more effective at what they do. While this usually starts out as a call for help with their technical practices, it can quickly expand into an organizational transformation. To be truly effective, the company needs to be organized around getting important things done.

In the agile world, we have a term "done done." This means that not only have you done the bulk of the work, but there's no more work to do. If it's software development, it means that the software is deployed or, in some cases, ready and waiting to be deployed.

For an organization, done done means having all departments, all people aligned to accomplish a larger goal. Pushing a release out the door doesn't just mean making the software available. It means having the marketing material ready to go. Changing the packaging to reflect the new features. Updating the sales toolkit and briefing the sales team. Engaging with customers. And so on.

So why don't things get done?

You are sitting at your desk. It's your first day at this job and it's new and exciting. You've been given an extremely important assignment. Knowing that you'll have to exploit the full capabilities of the corporation to accomplish this task, you dive in hungrily.

And then you feel an itch. It's on your leg and it's not too bad but you reach down and scratch it. Feeling better, you stop, turning back to your important work.

And then you feel another itch. So you scratch it for a while until it feels better. The first itch is back, so you give it a quick scratch. Then back to work.

Your eyes are feeling dry so you pull out some eye drops and give them a dousing.

But the first itch is back so you scratch it again. But its not really the first itch. It's a new itch just near the first one. So you scratch the new itch, and while you're there, you give another quick scratch to the first itch.

But then your nose starts itching. And its itching really bad. So you abandon scratching the first itch to start scratching your nose. You figure you have two hands so you try to scratch your nose and your leg at the same time but you can't quite reach. And now you have to make a choice. Do you scratch your leg or your nose? And, uh, wasn't there something else you were supposed to be doing?

Your name is Jim. You are sitting in the weekly status meeting with 19 of your peers. Your laptop is in front of you displaying the updates for the 147 projects that the department is currently tracking. As you look around, you realize it's your turn to report on your 23 projects. It's been a good week, so you smile, take a breath and launch into your report. "Well, we've made good progress on all fronts. We've moved the bar forward on all 23 projects. Eight of them are almost 50 percent complete, with another 14 close to hitting 25 percent completion. It's been tough for my eight staff members to keep making progress but they've been working hard and putting in some long hours. I'm especially proud of the progress we've made on Project Exemplar. Last week, we were a bit behind, only hitting an 89 percent completion rating. So we put in extra effort this week and got close to 94 percent complete." You pause while you wait for the applause to die down. "Of course, we'll have to back off a bit this week to make sure the rest of the projects get attention. We wouldn't want to drop any balls."

Your boss is smiling. He stands up, walks over to you and shakes your hand. He says, talking to you but addressing the group. "Good job Jim. This is exactly the kind of go-getter effort we need from everyone. We've got a lot to accomplish and we can't finish if we don't start. I've got several new initiatives I want to kick off this week and its obvious to me that you and your team are more than capable of taking them on."

Too often I've seen companies act like Jim's. Rather than focus on getting one thing done, finalized, out the door, gone, been-there-done-that, they prefer to juggle many, many projects each deprived of the attention necessary to move any of them to completion. Add to that the gridlock that happens when everyone is too busy to help anyone else and you have the perfect no-win scenario.

And while it's counter-intuitive, I attribute the frequency of this dysfunction with the human desire to get things done. In a company that has well-motivated, skilled individuals who are eager to accomplish great things, their own motivation leads to their dysfunction. Just like in the first story, each project, each initiative is an itch. Rather than spending an appropriate amount of time and effort on the project, a quick "scratch" satisfies the human desire to make progress. But once the project has been "scratched" just enough, there's another project that itches and we switch our focus to that one. And soon, all of our productivity is consumed with nothing actually getting done done.

But what really happens is that with each new initiative added, the rest get starved for attention. There is only so much productivity available. By trying to juggle too many initiatives with no clear priority, each individual is left to decide for themselves what is important to work on at any given moment. Also, the overhead associated with so many projects becomes overwhelming. How many of us have had a day where we've careened from one meeting to the next with no time to actually follow up on any outcomes from these meetings? This leads to the symptom where you find yourself doing your "real work" during off-hours because the gridlock during the work day and the constant context switching between projects creates an inability to expend a reasonable amount of collective effort to move any one project to completion.

In the agile world, we laugh (at least inside) when people say "Done but ... "

• Done but ... I just have to update the software library.
• Done but ... I just have to add a login page.
• Done but ... I just need to run some tests.

This is how projects get late. When managing an agile project, we absorb the effort for all of the "Done but ... "s into our stories. The story isn't done until it's done done. The feature isn't done until it's done done. The release isn't done until it's done done.

In agile, we talk about building things that are good enough, meaning that we've built just enough to meet the requirements but haven't built anything not needed. By constantly asking the critical questions -- "Do we really need this?" -- we are able to continuously deliver the highest business value to our customers and users.

But when considering whether our work is good enough, too many times we don't consider the maintenance tail associated with our work. Let me give you some examples.

Suppose you're updating your Web site. As part of this, you've increased your logging so you can capture some basic analytics for the marketing department. However, because the log files are now much larger, the disk drive fills up faster and now every few days someone has to go in and clean up the drive. While this may seem like a small amount of effort every few days, this is a maintenance tail that will only get worse over time as your Web site becomes more successful.

Here's another example. You have an app that displays recent news about your company. Every week the marketing department publishes an internal newsletter with updates. Someone in the IT department has the job each week of copying the text from the newsletter, reformatting it and publishing it out to the app. It only takes a couple of hours a week.

In both of the previous examples, the task itself seems small, rote and easy to accomplish. Yet in many companies, at least that I've worked with, these types of tasks have accumulated over time to take up a significant amount of what would otherwise be productive time. In both cases, the teams building the software stopped too early. They got done the "important" part of the functionality but they didn't address the maintenance tail to minimize it or, preferably, to completely remove it.

The aforementioned examples show the cost of a continuous, ongoing maintenance tail. A different example of "not good enough" is when the organization has some kind of cyclic event, for example, an annual show or holiday, that takes a lot of work to prepare for. Often there's a mad scramble to build or modify what's needed in time for this hard deadline, patching things together as needed since, well, you won't need it once the event is over. But that's not really true since there will be another event, just not right away. Instead of the mad scramble, creating a reusable solution can make the event into a non-event in terms of effort. Now this may seem unreasonable, given all the other work that has to get done, but agile methods will allow you to build just enough for this event, then modify and update the software for next time, all the while building toward a better, more comprehensive solution for future events.

In order to get things done done:

• Focus on just a few initiatives and align departments and coworkers to them.
• Deliver often.
• Measure progress as delivered value, not percent complete.
• Only once you've delivered enough value, consider moving to another initiative.
• Minimize the maintenance tail as much as possible.

The obvious issue in your mind is, "I work for a large organization. We can't have everybody working on just one or two projects." This is a common problem. You have a large organization that's broken into functional departments, for example, sales, marketing, development, UX .... Each department is juggling a lot of different projects and setting its own internal priorities based on the people available, the work to be done and the perceived priority. When one department's priorities aren't aligned with the others, it creates gridlock. No one can move forward because they can't get what they need from the other departments.

Instead of a functional organizational structure, consider organizing around products. If you can create cross-functional teams dedicated to a single effort, the gridlock melts away. The whole team can focus on what is needed for the top priority.

Focusing on the one or two highest priority tasks is nothing new. But it is a core part of the agile mindset. The first principle of the agile manifesto is "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Delivery is the key. It doesn't matter what percent complete you are on a project. Until you deliver something, you earn no value from your work. And the only way to deliver is to focus the team on getting one thing "done done."