Agile Development Concepts Applied Across the Organization
For 2.5 years now, we at Balihoo have applied, practiced, refined and tweaked agile development concepts to create a highly functioning and well oiled product development process. Yes, we still have issues - the real world and a constantly changing marketplace will do that to you. Our process is still evolving to this day and will continue to do so to support the changing face of our company, but in general it is stable and predictable which is a great feat as anyone in software will tell you.
Our chosen path for product development started with a flavor of Agile called Scrum. You see Agile is not a methodology as some might suggest - it is a mind-set. At its core it is about
- Individuals and interactions over processes and tools
- Customer collaboration over contract negotiation
- Responding to change over following a plan
I say we started with a flavor of Agile called Scrum. The thing is - every company and situation are different. People who fail with Agile are looking for a cookbook. Agile, Scrum, XP or any of the other buzzwords thrown around are not cookbooks, and if you try and treat them as such you will end up abandoning the concept as ‘great idea but won’t work here’. It takes effort, experimentation, and hard work to figure out what works best in any organization, but the payoffs can be great.
One of the key concepts used in Scrum that we have kept, is the concept of a morning stand up or more affectionately known as the morning scrum. At its core the morning scrum is really a communication tool with an underlying theme of self organization. It is focused on:
- shared commitment
- communicating daily status, progress and plans
- identifying obstacles so the team can take steps to remove them
- setting direction and focus
- building a team
On the surface, it might sound like any other meeting, but it is much more than that. (You can learn more about how a morning standup/scrum is organized in software development here) For example, it takes place every morning, everyone stands, its only 15 minutes, and its organized around 3 basic questions. They are:
- What did I accomplish yesterday?
- What do I plan to accomplish today?
- What roadblocks or issues are standing in my way ?
There is actually a 4th one that could be used at the manager scrum: What other teams will I impact by what I am doing?
As an organization we decided that it might be worth adopting this concept across all teams in the organization separately. Of course it would need to lose some of the software development nuances, but again - thinking about underlying concepts and purpose we thought it would be an excellent tool for other/all groups to increase the rate of communication without sacrificing time, drive issue ownership and resolution more quickly, and generally get the day going with a bang.
Now, a few weeks into this experiment we have all teams carrying out a planning exercises (mostly on a calendar month basis), track ’stories’ (goals) on a visual board and communicate status to their teammates with with a standup each morning. I know that some will say: ‘That wouldn’t work for us because of the work we do’…. We have account management, sales and even our creative development team trying and adapting the concept.
In addition the management team is also doing it as well, which comes with additional challenges due to the typical cross functional nature of the work, the sheer diversity of items worked on, and ensuring that we do not duplicate items that are already being managed by sub teams.
(Image: Balihoo Mgmt Team Scrum Tracking board)
Everyone is still trying to figure out how to make the concept best work for their teams, but early feedback is already positive. For example, At the management level, we have dropped our bi-weekly mgmt meetings now, and they only come on the calendar for special topics. We have had a number of people in the organization say that the morning scrums get everyone energized and focused for the day, and almost universally everyone agrees that the near real time, quick view of what’s going on around, helps keep important information flowing and helps drive issues to resolution much faster.
Only time will tell how things evolve and change, but for now we will continue to iterate and adapt the process to fit our demanding organizational needs. Many startups call themselves agile as a synonym to chaos, however with simple tools like the morning scrum, it can start to feel a little more organized and maintaining or even increasing the organizations agility.


Check out the web based version of ScrumWorks Pro - w/ a computer and a projector you can eliminate the stickies and teams can provide real-time progress even after you’ve had your morning scrum. We use it to show our burn down rate, track real-time progress and post sprint - it helps identify where we went wrong (like not gathering enough requirements at the onset and biting off more than we could chew.) Overall, agile development of any flavor is a great way to get everyone on board…great job!
Comment by Jana B — June 9, 2009 @ 6:39 am
Jana,
On the product dev side - we have tried various tools including scrumworks but, there have always been ‘gotchas’ around the strictness of the tool. They work well for execution, burndown calc etc, but not as well to manage the entire product dev process end to end. For example I found that we still had to maintain a backlog of sorts outside of the software tool due to the scoring algorithm we created and use to help prioritize features, and tie things back to the product roadmap. Overall, after dozens of tweaks and experiments, our experience has shown that simple tools work best.
As for our new experiment in taking the concept to teams outside of product development - current software tools will not work for the same reason - strict adherence to a development philosophy vs. true intent of communication and self organization. No since trying to fit a square peg in a round hold. Its about the mindset - not the tools:)
Thanks for your comment!
Comment by Kevin Donaldson — June 9, 2009 @ 10:26 am
What are the three questions you ask?
Comment by James Broney — June 11, 2009 @ 9:59 pm
We’ve also been adopting Agile techniques across the organization; though the other parts of the org have yet to do standups, but I definitely see your point about how the standup provides one of the most visible signs/reminders that the team is following and adopting agile principles.
In general, I think a big catalyst for non-engineering adoption of agile is the success of the dev team. Agile allows us to produce results quickly that meet ongoing customer needs. The rest of the business quickly takes note of the level of focus and the ability to get things done and decides that they should try to do the same; so naturally they start looking at the process.
Also, to your response to Jana, I completely agree on the adaption of the process and tools to particular circumstances. We had a similar problem with different levels of backlogs. We actually ended up using Atlassian’s JIRA issue tracking system to create a custom dual backlog system: http://www.attivio.com/blog/52/295-agile-in-practice-managing-requirements.html
I’d be curious to read more details about how particular teams adopt agile principles, especially sales.
Thanks for the great read!
Comment by Rik Tamm-Daniels — June 12, 2009 @ 10:14 am
Some have pointed out that the actual 3 questions are missing:)
They are:
- What did I accomplish yesterday
- What do I plan to accomplish today
- What roadblocks or issues are standing in my way
For Mgmt scrum - a 4th: What other teams will I impact by what I am doing
Comment by Kevin Donaldson — June 12, 2009 @ 12:11 pm
Rik,
Thanks for your comment, and pointing me to your blog post on a similar topic. I completely agree that success in development being a big catalyst for organizational adoption. The success of our product development in terms of pace, and output is a key factor in the curiosity/ interest in applying some of these tools across the business.
I will post more in the future as we grow and learn through this process.
Cheers,
Kevin
Comment by Kevin Donaldson — June 16, 2009 @ 11:58 am
Cool site, love the info.
Comment by Bill Bartmann — September 3, 2009 @ 4:06 pm