When I started realizing that I actually really like the Agile Scrum Methodology, I started looking around the web for more information, stories and blogs on the subject. Reading about how others do things and what challenges they face is always helpful, whether you can learn from their mistakes or simply get some encouragement that you are not alone in your struggles to try to get it right in the agile world.
One really interesting article I read recently on OpenViewLABS is actually not about scrum in software development, it’s about using scrum elsewhere, basically applying the principles of scrum to any part of an organisation: Scrum One, Scrum All: Why Agile Isn’t Just for Technical Teams. The idea to use scrum outside of technology development really struck a cord with me, particularly since doing the functional discovery work, where we applied scrum without actually building software…
The article suggests to use the basic principles of scrum to create a framework for any kind of complex project or task. Just like in technology development, scrum can increase transparency, accountability, organization and flexibility, team members understand the big picture and how their tasks fit in, time boxing the various tasks helps provide structure and organisation, while still allowing for flexibility to change if needed down the line…
In our functional discovery team we decided to take a similar approach. Initially we just dove right into the various features assigned to us for analysis, which resulted in one thing and one thing only: chaos!
Realizing we were getting nowhere, we adapted, we are agile after all! After completing our initial feature, we took a step back and re-prioritized our other features. We broke each of them down into smaller tasks or phases and we built a high level release plan on when to do what, so we could actually track if we were making the progress needed to complete everything by our deadline. Since we didn’t have specific user stories to complete, we took a slightly different approach, only creating place holder tasks for each phase we wanted to complete for our feature: Define (what’s the problem), Analyze (what could be improved) and Solution (how to improve).
This kind of approach really is not specific to software development at all, it’s a principle that is ingrained in any kind of improvement methodology, whether it is agile scrum, six sigma or lean, the basic steps – having to know your current situation, figuring out what the root cause of the problem is and investigating how to fix – it are applicable everywhere.
…food for thought.