People who discover agile, sometimes get this kind of 1st impression:
Agile, that’s just for hippies and beatniks! We’re running a serious business here!
Sure, these agile guys are doing lots of strange things, but does that mean they ‘re just hugging trees and talking about trust all the time?
No it doesn’t, all the ‘strange’ agile practices have valid reasons for doing them.
Let me clarify by explaining some of the more well-known practices of agile management.
Daily stand-up
Impression: 15 minutes of jabbering about details and drinking coffee.
Reality: A timeboxed meeting requires great discipline from all attendees. The daily standup is not different. As a group we try to synchronize. What is done, what is left to do, how will we approach this work and are we blocked somehow? Instead of holding a 2 hour weekly status meeting, daily stand-ups are much more responsive. The maximum time we’re heading off course is one day. If you’re into command and control management, you’ll love this. Wether you’re doing this for the right purpose, that’s another discussion.
Retrospectives
Impression: A chance for the team to complain about management.
Reality: Continuous improvement is a concept that exists for a long time and in many forms. From Deming’s PDCA cycle to Kaizen events in Japanese car manufacturing, inspect and adapt forms a driver for organizational growth. When your software development team is working in iterations, it is vital to their growth that they can take time to look at their work process. Retrospectives are part of many iterative approaches on different scales, you might already know them as lessons learned meetings.
Again, just like the daily standup, we’re just doing this more often, in less time. By focusing on improvement, these sessions can be creative and energizing instead of awkward and painful. The goal is not to blame, it is to find new opportunities to work better in the future.
Planning poker
Impression: Childish game that provides food for discussion about scope.
Reality: Studies have proven that estimates which are made by the people ending up doing the job, are more accurate. The benefit of estimating in group is that your personal understanding gets enriched by each persons view of the task at hand.
A study by K. Molokken-Ostvold and N.C. Haugen found that estimates obtained through the Planning Poker process were less optimistic and more accurate than estimates obtained through mechanical combination of individual estimates for the same tasks.
By stepping away from estimating in time, and using measurements to project into the future, differences between planning and delivery will level each other out.
Pair programming
Impression: A way to double the cost on your project.
Reality: If you’re honest, you will admit that you get more work done when you’re doing it with a colleague. You don’t waste any time checking e-mail, surfing the web or just daydreaming. Since software development is a creative process, having an extra brain on the problem, improves the quality and design of your solution. Defect rates and technical debt will be lower.
So when you think about it, their’s actually a nice return on investment. Especially when you have a long-term vision and care about the quality and maintainability of your product.
Task board with post-its
Impression: Back to the stone age.
Reality: One of the hardest tasks of a manager is to get everybody to understand and agree on the standard work process. Especially in knowledge work. Most of the time you don’t have physical things to move around, which creates a lack of visibility and makes it harder to notice obstructions in the workflow.
You could manage this electronically, by maintaining a project plan and assigning tasks to the people involved. But again you lack the visibility of work moving around from one team member to another making it difficult to see the whole. So until digital touch screen task boards are affordable, why not keep it simple and visualize your workflow on a white board with some post its? You can even keep the project plan if you want, but the short-term work can be visualized on the wall, so that everybody sees the standard process and spots issues when they arise.
Does this all sound logically? To me it does.
Love this entry. What a great read for today. Hippies #ftw!
Thanks for the support, Agile Scout!
Catchy title and great blog posting, thanks. Looking forward to part 2 with pirates. 🙂
Many greetings from an agilist in Sweden!
Pingback: Hippies Love Agile Software Development | Agile Scout