So What Are You Waiting For? GO BANANAS!
So What Are You Waiting For? GO BANANAS!
Join the DZone community and get the full member experience.Join For Free
Welcome to the seventh and final episode of The Agile Guerilla series. The focus of this series of articles is to to help you introduce change, specifically moving to agility, into your organization from the grassroots level.
In this episode we're going to take a look back at the road that we've travelled and then close with a challenge.
In our first episode, we defined guerilla warfare and looked at why using guerilla-like tactics can be an incredibly effective way to spur on an agile transformation from the bottom up.
Guerilla warfare typically describes a small group of combatants using mobile military tactics such as ambushes and raids to combat a larger, less mobile army. Their goal is to slowly erode their adversary's power, influence, and will. In our analogy, you - the aspiring agile developer - are the guerilla combatant, and your "waterfall/coding by coincidence/insert your decidedly unagile adjective here" team is that big, slow army.
In episode two, we zeroed in on the two fundamental tactics employed by the agile guerilla: demonstration and persuasion.
We highlighted several keys to demonstration:
- Learn the technique and then do it yourself FIRST!
- Show your team the new technique, don't just tell them about it!
- Contrast how well it works with the your current way of doing things.
- Look for opportunities where it may help and jump in!
- Do your homework!
Then we looked at persuasion, which is the idea that instead of cramming our ideas down others' throats, we're going to speak our recipient's language. Not only that, we're going to speak to their felt needs. We'll consider our teammates', manager's, and customers' perspectives and then tailor our message to that perspective.
Episode three's focus was on how to get started. We examined four different ways (drawn from one of my favorite books of all time, Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt) that we can turn inward and address our own flaws as a developer and as a person:
- Work for Outcome
- Quick Fixes Become Quicksand
- Criticize Ideas, Not People
- Damn the Torpedoes, Go Ahead
The main idea is that before you begin trying to change your organization, turn your focus inward and change yourself.
Episode four showed us four ways that we can improve our personal workflow and influence our team to manage its work more effectively:
- The List
- Getting Things Done
- Personal Kanban
- The Pomodoro Technique
Each of these techniques can boost your personal productivity, get you out the door and 5 o'clock, and set a good example for the rest of your team.
Episode five focused on Guerilla TDD, or how you can apply the agile practice of Test-Driven Development even without your team on board. Simply by having your teammates check-in stubbed out interfaces that you'll depend on and then mocking those out, you can very effectively test-drive the development of your own code. It may sound simplistic, but it worked for me!
Episode six examined another agile practice - Continuous Integration - and how the agile guerilla can get it going. Follow along as we pull down Hudson, set up your project's build, and then start it monitoring the source repository - ALL ON YOUR OWN MACHINE. Then, in true agile guerilla form, we demonstrate the "cool new tool" that automatically sends us an email every time someone checks-in bad code. They'll be eating out of your hand in a few days. ;-)
So now it's time to, as my buddy Jared would say, "throw down the gauntlet." It's time to either CHANGE your organization, or change YOUR ORGANIZATION. Staying put simply isn't an option. You probably already know my advice. I've given you the long Labor Day weekend (for those of us in the U.S.). Take an hour or so and read back through the series. Jot down some things that seem workable for you. Then hit the ground running come Tuesday (or Monday)! Go bananas!
Other Epsiodes in "The Agile Guerilla" series:
Opinions expressed by DZone contributors are their own.