In part one of this series on Agile, we debunked the top three excuses for avoiding Agile development. Now, let’s look at the five foundational building blocks you need once you decide to employ Agile development methodologies at your company.
1) Embrace Change
What’s that saying? “Only wet babies want change,” and even then there’s quite a bit of screaming in protest.
Change isn’t easy and sure as heck isn’t quick. It’s stressful and frustrating. So how do we minimize the screaming? The most successful way is to present the goal of change in such a way that convinces everyone it’s the most brilliant thing your company has ever done.
When it comes to Agile, tell your people that they’ll finish what they started and they won’t have to deal with changing requirements and scope creep—that’ll get them excited. Actually delivering on that promise will then keep them engaged and motivated. Once you do this, get out of their way.
One of the principles of the Agile development methodology is to build projects around motivated people. Give them the environment and support they need, and trust them to get the job done correctly. Can you do that? Can you trust your folks to get things done correctly without being told how to do it? Yes? Then you have cleared change’s biggest hurdle.
Congratulations! Most companies never get this far.
2) Build a Culture Bubble
You need to create a bubble, or buffer, to surround those enthusiastic people with a bit of insulation from the way they used to operate. With everyone else still doing things “the way it’s always been done,” it’s too easy for the Agile teams to get interrupted by old processes.
That being said, insulate, don’t isolate. Give the team the tools they need, empower them to make decisions, but don’t leave them high and dry when it comes to getting help. Agile methodologies expose impediments, bottlenecks, and cumbersome processes very quickly. These folks won’t stay enthusiastic if there’s no support to make their jobs better, so use your leverage to streamline cumbersome processes.
In essence, you need to create a safe zone:
-
- Trust the team to do the job
- Be there for the team
- View failure as a learning experience, not failure to perform the job
- Allow the team to speak up, present new ideas, and have different opinions on how to design a solution
- Encourage the team to try new ways of getting to the finish line
Caution: side effects include heightened enthusiasm, workplace joy, and increased engagement.
3) Get the Right People on Your Team
This is where that culture bubble gets put to the test. When you create your team, don’t make this common mistake: throwing random people together and expecting things to work out. Get the right people on your team the first time. You don’t have to hand-pick the best and the brightest, but instead find people with the correct skills for the task.
Here’s what you’ll need:
-
- A backlog of items the business needs developed.
- Someone to look out for the team. “Servant leadership” is the key because this person keeps everyone enthusiastic about Agile. If you put the wrong person here, or expect this person to be a project manager, too, you’ll fail.
- A team member to serve as the link between IT and the business. This is the translator for both sides but not your typical Product Manager or Business Analyst. You need someone that can both speak geek and be fluent in business vernacular. This person should be empowered to make decisions about the product and have the ability to determine when delivered solutions meet the business’ needs.
- Development Team, which is critical to get right. This team determines the overarching design, breaks the project into components, and determines how much can be accomplished. They must quickly show progress without wasting time deliberating requirements up front, they must reiterate, and they must accomplish what was promised. The team should be comprised of people that can go from “concept to cash,” meaning they’ll get things done, done, done each and every iteration.
4) Get Rid of these Things
Here’s what you don’t need:
-
- Gantt charts and massive, upfront requirements documents
- Erroneous meetings and daily/weekly project status reports
- Command and control management, micromanagement of daily tasks, and fear of failure
It’s a simple as that.
5) Cozy up to Burn Down Charts
You can organize everything that’s being worked on in two simple burn down charts. Burn down charts have nothing to do with arson rates but everything to do with where you are and where you’re headed.
Sprint burn downs are updated every day with the number of hours left to complete the work committed within the Sprint. Release burn downs are updated at the end of every Sprint to show how much is left and at what point the team will reach the strategic goal/product release.
Isn’t that what you really need to know?
As you build a solid foundation around your Agile program, don’t forget that you’ll need to take it slow, be responsive, and allow your teams to experiment. Everyone will stumble, so it’s important to learn to get back up and maintain consistent momentum.
Ready? Go forth and conquer!