ScrumOverviewResized

Why did we use Agile (Scrum) to manage our business

We happened to be a software company and experts at Agile software development practices (at least the R&D portion of the company was).  The beauty of the Agile approach, Scrum in particular, is that it addressed the following universal management challenges:

  • Ability to establish high level business objectives
  • Ability to identify work to be done
  • Ability to set priorities for the team
  • Ability to break down work into track-able chunks
  • Transparency in the execution of work
  • Ability to hold the team accountable for the achievement of work
  • A way to see evidence of incremental work
  • A way to observe team member engagement
  • Ability to constantly improve the team’s performance

Our special challenge

We did not only want to leverage best practices in software management (Agile and Scrum initially) to run our business team.  We wanted our business team to never see each other for the purposes of getting work done… only for social, team building reasons.  So we needed to execute Scrum in a way that all of the management needs mentioned above were achieved but, in an environment where the team members were NEVER in the same room.  To do this we needed a platform and minimum team member behaviors to ensure the ability to see evidence of work, team member engagement and ensure quality of deliverables and outcomes.

The Platform for the Remote Work Team

We became fully committed to fully distributed teams in 2004.  At the time, collaboration tools were scarce.  We standardized on the following tool set:

  • Free conference lines to be used for synchronous meetings (15 minute Daily Stand ups and Planning/Retrospective meetings)
  • AIM instant messaging (remember that?) for quick answers or responses to issues
  • We used a wiki for almost every thing else

Because we were a technical company and most of our business team had technical backgrounds, the wiki was initially sufficient for building checklists to track work and managing content to view deliverables and even having votes to make decisions.  However, we knew that we had a bigger vision of enabling any company to work this way so, we built a platform to simplify the execution of the basic workflow needed by any business team:

Brainstorm ideas -> make decision -> plan -> execute plan

So, we built the Checklist Anywhere platform which has a topic app to brainstorm ideas, an election app to get anonymous input for decisions, and a checklist app to very simply establish the work items, assign the items to team members and then provide transparency in the completion of work items where all are kept informed through notifications and feeds.  Additionally, we added a powerful search approach to enable finding of deliverables and conversations.

Some required Minimum Behaviors expected of Team Members

There are unique challenges in managing a team where no one is in the same room.  The objective of these rules were to ensure that we could depend on each other to be responsive as well as ensure that incremental work was visible to all with a need to know so that we could spot quality issues early into the process.  These rules included the following:

  • Daily check-in – in software development this meant that tested code should be checked into the configuration management system.  In business for us it meant that work should be done on the platform vs in off-line documents like Word.  For example, if we were developing a proposal, the development would be done in Topics online vs. word documents.  This way all could see all work in progress but also could comment on the work in progress to enable early course corrections.  This was very difficult to establish and required much “online yelling” to establish the culture of working online.
  • Respond quickly to voice mail (within the hour).  Be available on chat most of the day
  • ONLY use email for external communication.  We did this because we did not want to have to hunt around for communication about topics.  Eliminating internal email was a major boost to knowledge management.

Other behaviors needed were addressed in the rules of Scrum.

Pros and Cons

To make a long story short (I know it’s too late) here are some bullets:

Pros

  • The team was able to make really fast decisions
  • We saved thousands of dollars in office space cost
  • We not only always knew what was a priority but also had a history of why we made decisions based on persistent online discussions within topics
  • New team members were able to be brought up to speed faster because we could point them to the appropriate topics and checklists to see the history of work.
  • We saved a bunch on software licenses because of the reduced need for everyone to have Microsoft Office.  We only needed desktop software to support client requirements for deliverables when doing consulting with clients
  • Recruiting was made much easier because no one had to move to work with us (talking just about the business team)

Cons

  • Management could not depend on visual cues to recognize lack of team member engagement.  It took a while to realize the online signs of lack of employee engagement (like not following the daily check-in rule)
  • The separation between work and personal life became blurred because of always being connected.  Team members responded to notifications at all hours of the night which from a business sense might be good but could get intense on personal level.  That being said, this seems to be the direction of the modern social and business culture… constantly plugged in

Conclusion

We believe that distributed work is the future of work.  We also believe that having an Agile (see http://agilemanifesto.org/) culture in business is also the future due to the current speed of change.  So, whether Scrum, Kanban or some variation that holds true to the values of Agile, we believe that using agile with cloud collaboration for distributed team not only works, but is superior to traditional, face to face management approaches.