1 “Are you Agile?”

Agile-Set2 If you’ve been in software development for any time at all, you’ve probably gotten this question at conferences, in meetings with vendors, or even from your own team. Everyone seems to want to know if you’re on board with the Agile development process.

This workflow approach is now so well regarded that whole trainings are devoted not only to the overall Agile methodology, but to specific accreditation levels within the process. Yes, you too can become a Certified Scrum Master, if you’re willing to follow the movement.

While the devotion to Agile practices sometimes borders on religious fervor, some teams aren’t actually clear on everything Agile development entails. Quite often, I’ll hear developers insist that they’re Agile—but they’ve only implemented one or two of the core practices like Standups.

Before I tell you how to dive into the world of Agile, let’s clarify why you would want to adopt this approach in the first place.

2 Who Needs Agile Development

The appeal of Agile is, at its core, a magic wand… with a designer label. By waving it over their team, managers hope that suddenly, their projects will have a silver bullet solution to product development, collaboration, and on-time product delivery.

Let’s be honest. In an industry where the vast majority of projects miss their initial deadline and are crawling with bugs at launch, we’d all love a guaranteed solution to improve development.

Most teams, large and small, are looking to Agile because their present approach is frustrating as hell.

If they’re from the waterfall camp, they know how stifling the assembly-line approach can be for having a sense of the entire project or handling mounds of complexity with a deadline that’s months away. Teams who aren’t working with waterfall or Agile are usually working in their own personal brand of chaos, complete with unclear job responsibilities and a very disconcerting lack of direction.

If you’re reading this article, my guess is that you’re trying to rid your team of these chronic, debilitating problems:

Slipping due dates
Missed software requirements
Clients unhappy with the finished project
Requests for revisions immediately upon delivery
Grumbling team members
Huge backlog of “someday” add-ons
Version 1.0 never ships, gets folded into v. 2.0
The manager never knows when the project is going to wrap up

Sound familiar? While Agile can’t work miracles out of thin air, it is pretty fantastic in certain circumstances.

3 Who Doesn’t Like Agile?

Before you go whole-hog with adopting Agile, it’s good to know that Agile practices go against the grain with certain personality types, so carefully consider your team before you sell them on a changeover.

Cowboys and mavericks really chafe at the idea that they have to inform others about their progress and craftsmanship every day. They’d rather be out on the range, free from any distractions, until just before the deadline hits, and then commit their code all at once.

Heroes and crisis managers love to swoop in and save the day… but they forget that in order for them to shine, something needs to be broken. Because Agile development tries to identify and remove problems before they become crises, heroes get restless for an adrenalin rush and some recognition.

Brilliant hermits are coding wizards, but their people skills aren’t exactly warm and fuzzy. For them, the idea of having to interact with non-programmers who don’t speak their language is close to painful.

4 The Magic of Agile

Almost every other project planning philosophy depends on the idea that hyper-detailed planning will save the day. The thinking goes that if project members can just outline every single little task, put those on a calendar, and focus on their specific assignments, then everything will turn out splendidly.

Don’t we wish.

Agile removes that unfounded optimism and replaces it with a gritty realism that embraces and tests all of the surprises that hide within every project as it strives to bring people out of their silos into collaboration.

Better decision-making

Instead of making decisions based on theoretical screens and theoretical use cases, Agile practices create simple test scenarios early and often so everyone gets a sense of what what direction the software is going. With feedback from customers and other stakeholders at regular intervals, you can finesse the project as you go.

Honesty with unknowns

Creating custom software means you’re swimming in a sea of unknowns every day, primarily because you’re creating something entirely new. You’re not following a map, you’re mounting an expedition.   Agile practitioners completely accept the reality of unknowns and actually expect to discover “impossible” issues they didn’t anticipate. Instead of panicking and ditching the unfamiliar feature, they have tools—and confidence—to break down the problem and move ahead.

Transparency

When developers, programmers, management, and customers service reps are checking in at every stage of the project, you avoid misunderstandings and the need for massive course corrections at the last minute. There are plenty of opportunities for clear communication.

Risk management

When you decide to identify and attack risks early, there’s less chance of getting blindsided by a problem you didn’t anticipate. Seasoned Agile leaders and teams know how to smoke out risk and tackle it first rather than sticking to the easy, safe tasks we all tend to want to jump into.

Cost savings

Budgets really take a beating when roadblocks and last-minute overhauls run up programmers’ hours. Minimizing these cost vampires eases tensions on multiple levels, obviously.

One of the unexpected advantages in using Agile is that customers are sometimes thrilled with a stage of software development that seems rudimentary to programmers. By avoiding an overbuilt solution with snazzy features that will never or rarely be used, you’ve just lopped off precious time.

Frustration reductions

Programmers hate those moments when a finished product is unveiled after months of blood, sweat, and tears, only to have the customer say, “This is great, but can you add on this feature, too?” Regular interactions with customers help shape priorities earlier in the development process.

Regular team updates also reduce misunderstandings about the job’s parameters and confusion over responsibilities so team members don’t get territorial or dwell in misinformation.

Safer revisions

Because the software is built with input and transparency from several fronts, more programmers know what’s happening on the inside. If a change does need to be made, it can happen without creating a cascade of problems that will take an inordinate amount of time to identify and correct.

The process is also safer because, when Agile is done well, team members feel free to speak up when they see a major problem in the headlights. They also have many opportunities in the feedback process to talk about these issues.

Teambuilding

We would all love a roadmap to help us avoid trouble, , so it makes sense to look for a way to combat all of these problems that we’ve all created—and survived—at one time to another.

But the biggest secret in Agile management is not the ability to hit deadlines or better match customer expectations—it’s the team that’s created in the process. A collection of eager programmers can be transformed from talented individuals into partners who work with each others’ strengths and weaknesses as they teach themselves new practices.

5 Getting Started with Agile Project Development: Two best practices

Managers might disagree on the best methods to use with a team that’s just starting out with Agile, but I think one piece of wisdom is certain: don’t try to hit your team with all of the practices at once in some sort of Agile boot camp.

While your programmers might be completely gung-ho for the change, truly integrating Agile into your workflow takes time. After using Agile to lead my teams for years, I highly recommend these two practices to introduce your team to this new paradigm.

5.1 Agile Intro Practice #1: The Daily Stand-up (AKA Daily Scrum)

This is a very short meeting—15 minutes max—where team members are quickly summarizing where they are, where they’re going, and where they might need help that day.

It helps to meet at the same time each day (usually in the morning) and make it somewhere without chairs so people don’t plop down and get comfy. If issues arise that need additional attention, move the discussion out of this quick-hit meeting.

Who’s there?

A representative for all of the major participants and stakeholders should be present. This might include managers, customers, users, product managers, and the person who sold the project to the customer.

When you get all of these people touching base—quickly—it’s a small investment that heads off a lot of problems. When a programmer says, “I’m working on this feature today,” and the customer says, “Wait—I thought that was an optional feature,” you may have just saved a few headaches and a lot of lost hours.

In large companies, this bit of face time keeps things personal and connected. See ya, silos. In small companies, where everyone is wearing several hats, it reminds teams that everyone’s in this together.

Once people warm up to this meeting approach, it’s astonishing to see how quickly problems are solved organically.

What’s the agenda?

I’m happy to share my framework for Agile Stand-ups, but under one condition. You can’t instigate these meetings and then go brag to your programmer friends that you’re Agile. These meetings are exceptional tools, but they’re just the beginning.

Once everyone is assembled, go around the circle and have each person answer these questions:

What did you work on yesterday?
What did you work on today?
What are the blockers? Where are you stuck?
Is anything causing you need to change your estimate for your work?

As you can see, these questions hold the potential to bring a lot of issues out into the open. But it’s your job to make sure that everyone feels safe enough to ask important questions.

5.2 Agile Practice #2: Plan the Project in Short Iterations (AKA Sprints)

We all know the weight of the project that stretches on for months with no end in sight. And then when the deadline finally arrives, it seems like there wasn’t enough time to get it all done.

Iterations remedy this mind-numbing grind by breaking the work into shorter segments that all have a beginning, a middle, and an end. These shorter time blocks are usually 2-4 weeks in length and have a very specific outcome in mind. No, “making progress” doesn’t count.

The iteration always starts with a planning meeting, which includes the same people in your daily Stand-up (see above). The middle is made up of the work outlined in the planning meeting, and the end includes a working demo (yes, working!) of the software you’re creating.

It also helps to have a retrospective at the end of every iteration so the next one has some clear direction.

5.2.1 Sprint opening meeting: The beginning

Sit down with your team and the product owner for one essential question: “What would you like us to do next?” The answer chooses the priority that’s on deck. If she doesn’t answer or tries to defer, let her know that without some direction, features could be late or missing. Ask her to identify which features she does not want to be late or missing.

Grab a stack of 3×5 notecards and write out all of the possible tasks associated with that priority—one to a card. Using those cards, the team can work through the most critical tasks, ask questions, then get more input on the requirements and expectations of the project.

Give time estimates to every task. Some will be easy to ballpark, and others will be a shot in the dark. Just give it your an educated guess and adjust as needed—that’s what the Agile approach is all about!

Identify tasks that will probably take longer than five hours and split them up, giving each new task its own card.

Bonus: If your team can’t agree on how much time a job will take, here are a few techniques I’ve used to move the consensus from “No idea!” to “Let’s try this.” These games also help give everyone a little space if an alpha on the team keeps pushing their ideas on everyone.

Blind man’s bluff In one glance, this is a way to see if estimates are in the same range or vastly different. Have each team member write their estimate one of the 3×5 cards and then put it on their forehead. Since everyone at the table can see the numbers and they know their own, the differences or similarities can be the start of a great discussion.

Roshambo This version of rock-paper-scissors has each team paper make a fist, then throw down the number of fingers that represent the hours they think their project requires on the count of three. For example, if you think the project will take two hours, pop two fingers out of your fist.

6 Set work schedule

As you map out the iteration, make sure you calculated the amount of time available from the team. Yes, there are 40 hours in a week, but don’t forget that you’ll need some of those hours for meetings, other projects, dental appointments, etc. Don’t overextend the team.

Be prepared that the project manager might hit you with the anxious question,” What if you’re done early? Are you going to just sit around?” Reassure them that the team will just start a new iteration whenever the first one is complete—as long as everything is truly in order.

Before you leave the meeting, make sure you have buy-in from the entire team. A contract or a formal statement is hardly necessary, but a solid, clear commitment from the whole team is.

I usually make a statement at the end of these that sounds something like this:

We as a team jointly agree that it’s reasonable to accomplish this [set of goals] within this [amount of time]. At the end of this time, we will demonstrate what we’ve accomplished using working software that we will ask the other stakeholders to sign off on.

I’ve seen team members so committed to the deadline that they’re willing to come in early or stay late for days. And while that’s commendable, it’s not sustainable. The whole point of Agile methods is to remove drama and create a smooth system for reliably producing software.

6.1 Off to work: The middle

With priorities and tasks set, it’s time to dig in.

While there are Agile-y processes that you can use at this point, don’t worry about that right now. Changing the beginning of the process through the new planning meeting and having real-time demos at the end (see below) will dramatically improve your ability to see into the project—and have better results.

Make sure you’re having consistent Stand-up meetings to keep team members accountable. Having that consistent, safe place to hear from all of the stakeholders and allow important questions is essential.

Some teams take longer to adapt to standups if they’re only accustomed to interacting with other programmers. That’s fine. These meetings are so quick that they can’t really complain.

6.2 Make it work: The end

This is the point where the rubber hits the road. Instead of mushy deadlines announced in a contrite meeting, Agile iterations end with a real-life, hands-on demonstration of what’s been created in the given time.

The demo Each member of the team presents the part of the software that they built, making sure that there is very specific accountability. If the feature looks stupid, then they look stupid. If that happens, chances are they’ll make a better effort next time.

Leave time for all stakeholders to ask questions and give feedback. You never know which comment is going to lead to a big breakthrough or significant pivot, so be ready to hear them all.

The wrap-up After you’ve collected all of the feedback, gather the team together and discuss what went right, what went wrong, and what you wish had gone more smoothly. Sort through the issues so you can take the wisdom to the next iteration.

Make sure you exit this retrospective meeting with at least three actionable improvements you can make. Without a clear path, you’ll just keep stumbling into the same mistakes, leaving everyone frustrated with the new process and chronic team problems.

7 Is Agile Worth It?

Clearly, I’m an Agile fan.

After using Agile with several teams in different companies, I can say that it’s made a huge difference in how work gets done and how the team as a whole feels after the work is done.

Yes, it’s fantastic to hit deadlines more often and with far fewer complications than I had when I was winging it. Teams also feel a whole lot more satisfied about their work and its significance to the company through a high-communication process like Agile. It’s priceless when you give a developer the chance to see the customer actually use what they built, which rarely happens in a waterfall environment.

But the outcome that keeps me coming back to Agile practices is how the team learns to depend on each other. In this supportive, collaborative environment, my employees teach each other new things. They identify, uptake and execute process improvements all on their own, without any nudging from me.

In short, Agile helps create positive peer pressure that lets great people create excellent software.