What The Real World Can Gain From Agile
August 11th, 2009
Agile/XP methodologies make my job easier and me more productive. There is nothing exclusive about writing software that makes it the only viable profession to apply agile techniques. In the modern business world, the ability to respond to change and communicate effectively is crucial to success. I talk to people outside of software all the time and I hear the same issues over again: problems not getting solved, wrong work being done, meetings ran by power hungry authoritative types talking at you with no real game plan, disjointed teams communicating poorly and outdated work processes can't get changed. Because of the way software development has evolved over time, we have learned that how you work is just as important as what you are working on and most importantly we actively take steps to improve. So why aren't more small businesses, non-profits and creative firms having scrums every morning, working in iterations, playing the planning game, utilizing information radiators and honing their processes with retrospectives? The short answer is that they probably are implementing some aspects of Agile, don't know it yet and could be doing it better.
Baby Steps
If you ever worked or participated in a software team transitioning to Agile, then you know that there is resistance. In a tradition working environment, I could only imagine that were would be even more push back. So if you are reading this and trying to get your non-software team to adopt Agile techniques, move forward slowly and incrementally (just like agile). Here are a few easy things to start trying (one at a time):- Get Information Radiator: team chat rooms or wikis
- Daily Scrum: transparency keeps everybody honest and connected
- Monthly Retrospectives: low investment cost and high reward
Long Term Goals
Ultimately you would like to be working on a highly functional team, where its harder to be disconnected than in the loop, change occurs easily for the best and no team member can succeed without the whole team succeeding.In the end, I think that an iterative work structure would be an optimal situation for many jobs, even ones that aren't producing concrete pieces work with requirements or a definitive end. Thinking, planning and working in 2 - 4 week iterations provide for actual goals to be identified and accomplished. Iterations reduce risk by completing any project in manageable chunks small enough to complete quickly and validate that it's done right. At the end of these iterations, time is provided and a logical break in the cycle allows for an honest dialogue to occur about how you're working and what could be improved. Including the stakeholders in retrospectives is useful and sort of like couples counseling. It helps facilitate feedback on the work done to date, how you can improve the perceived value and meet the needs of the client/stakeholder. Here are a few tips for working in iterations:
- Identify the stakeholders: your boss, client, ceo, investors, board of directors?
- Communicate with them (at least) every iteration to determine what they need
- What would provide them the most value right away?
- Try playing different planning games
- Iterations don't have to be concrete or discrete, they can be virtual, so don't get hung up on that.
- Demo/show your stakeholder or at least your team what you accomplished.
- In your retrospective produce actionable/achievable improvement centric goals.
I am a huge proponent of pair programming and feel like there is room for it in the non-software world. Not to say all the work has to be done in pairs. But frequent pairing would cut down on team members working themselves into corners, where they can't move laterally or vertically because they are the only person who can preform a function. Pairing also leads to better and more communication, which produces empathy and richer interactions between team members.
The overall tenets of Agile are still the same as in the software world; take what you need and leave what you don't. The key is to:
- Don't let your practices slow you down
- Be agile and not afraid to change
- Focus on results, communication and constant improvement
Leave a Reply