# Saturday, 26 June 2010

I had the misfortune and pleasure earlier this week to work in an Emergency Operations Center view from my home.  Fire is about 1 mile away.(EOC).  Early Sunday morning the Schultz wildfire broke out and moved extremely quickly towards several communities.  I was amongst 1,000 residents evacuated.  

On Monday, I was called into the EOC to help with information flow to the website and twitter.  Over the next three days I worked a little over 40 hours.  It was exhausting but it was amazing and I am proud to have been of service. 

View from friend's home.  Fire is about 1/2 mile away.



The EOC was a great example of agile even though the team responsible for the EOC didn’t plan with the agile movement in mind.  It reinforced to me that many of the principles in agile can be applied almost anywhere.




Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

The EOC exemplified the manifesto.  The amount of teamwork and information flow in the room was astounding.  Emergencies rarely follow a plan and as such responding to change is paramount to a great EOC.  This EOC was incredible at adapting versus the blind following of a plan.  Wildfire can be incredibly unpredictable.  Even though the EOC had comprehensive documentation and plans for handling emergencies it clearly valued interactions, collaboration and change over processes, documentation/plans and allowed for teams and individuals to improve upon tasks and adapt to needs quickly.


Our highest priority is to satisfy the customer….

The EOC has many customers, everyone from the public to the people on the ground responding.  The central theme of the EOC was to keep the accurate and timely flow of information at peak performance.  It accomplished this with co-location of personnel, frequent and short team meetings and a constant emphasis on informal communications and information sharing.

Welcome changing requirements, even late in development….

While the EOC has practiced, ran drills, created plans and procedures for execution of an EOC, the ability to adapt was embraced over absolute following of the training and plans.

Deliver working software frequently….

In this case the EOC is delivering information and logistics.  The EOC worked on a constant cycle of information gathering and dissemination.  The EOC every few hours had a short briefing where all of the table/section leaders gave a report to the team and in between there was constant information flow.

Business people and developers must work together daily….

EOCThe EOC was staffed with expertise in each section that focused mainly on their tasks.  Also in the room were sections for leaders who would be the face for the media and citizens.  Additionally, the call center staff were only yards away from the EOC staff.  This allowed for a constant stream of communication at all levels.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This was perhaps one of the most impressive executions I found in the EOC.  The EOC was staffed EOCwith seven sections, each section was staffed with at least a couple people and as much as six.  Each section was responsible for a general task such as Public Information, Logistics, Operations, Finance, etc.  Each section had a team leader that was responsible for that section.  The interaction between sections was high.  Flip charts, whiteboards abounded along with three projectors displaying relevant but different information.   

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The EOC was extremely concerned with identifying weaknesses and improving them ASAP.  For items that we knew would take longer to correct than the EOC’s existence, the issues and ideas for correction were captured electronically and have been given to staff to work on.

Parting Thoughts:

During the height of operations there were around fifty people in the room.  The energy in the room was high which aided everyone in pushing through long hours and helped keep the room charged.  The dull roar that existed in the room was hardly a distraction as each team was so intent on doing their job well.  Ideas such as co-location and transparent information flow were key to the EOC’s success much like agile proposes.  The organization of each team was self-governing and while overall leadership was provided this leadership did not get in the way of the sections.  The leadership guided and aided in keeping the teams marching forward.

My experience with the EOC was nothing short of amazing.  I feel extremely proud of how the operation center worked and found that many of the ideas and principles held by agile were key in the EOC’s strong success.

Agile | Process | Teams
Posted 06.26.2010  #    Comments [0]  | 
# Saturday, 20 February 2010

This week I dived into two books that are both 100 pages give or take.  Both are fairly easy to get through and are worthy of bookshelf space.  My purpose of reading these was to get a better understanding of two practices of applying Agile principles.  I am an agile rookie who wants to understand/learn about ideas and practices that I could add to my toolkit. 

Agile Software Development With Scrum

This was an easy read especially with it’s case study focus to illustrate the idea or practice.  I felt the “spirit” of agile in the principles and found the practices shown in scrum enlightening. 

I gained a deeper understanding of the how the scrum master facilitates and leads only.  I found it intriguing that the scrum master does not make decisions.   The master is there to coach the team and even though I understood this I didn’t connect the empowerment of the team with the master not making the decisions (A duh moment).  It makes sense that if you want to empower the team to make decisions then you have to give them the power to decide.  I could see the old school mentality in my original thought process. 

The sprint is sacred.  Nothing can/should eek it's way in. This is a big key in ensuring the team stays focused and on task (or should I say feature).  If necessary a sprint can be killed if important enough and restarted with new focus.

The team’s daily stand up are for each other and no one else; not the scrum master, product owner, etc.  A particular story caught my attention on this.  The developers when giving their report were looking at and talking to the scrum master directly.  The meeting degenerated into a project / task status update where the team viewed the scrum master as a classic project manager.  A real test of a good stand up is the team should be looking and talking to each other because they are responsible to each other.  The scrum master is there to observe and if they see something that could use some coaching they should remain silent and look to mentor sometime after but not during the stand up.

Project management is featured based not task based.   Real success is not based on the adherence to a project plan.  It’s based on the delivery of the right features with the right functionality that the customer needs.  That doesn’t mean project management or a plan is thrown out the window.

For anyone trained old school this could be a hard transition and the case studies do a good job of illustrating people who hang on to their old ways and how to remedy the situation.

Lean Software Development

  • Eliminate waste does not mean throw away all documentation.

  • Amplify learning does not mean keep on changing your mind.

  • Decide as late as possible does not mean procrastinate.

  • Deliver as fast as possible does not mean rush and do sloppy work.

  • Empower the team does not mean abandon leadership.

  • Build integrity in does not mean big, upfront design.

  • See the whole does not mean ignore the details.

    These are statements directly from the book.  I can’t think of a better way to summarize this book.  Lean strikes me as less prescriptive in it’s practices than Scrum although I could be wrong on that.  Like the agile manifesto, it gives me guiding principles but at a lower level that one can use to help create practices.

    Both books are an excellent read even if you aren’t interested in applying them.  I can’t see how you won’t come away with a least something to consider for yourself or your team.

    If you are interested in applying these practices both books stressed technical practices as a must. Lean Software Development had very good advice to get started:

    • Start with hygiene. First of all, make sure that you have basic professional software development practices in place: a version-controlled code repository, coding standards, build automation, comprehensive testing, etc.

    A major key to Scrum and/or Lean or any other agile practice is the need for good technical practices.  If you only use Scrum/Lean as yet another project management methodology you are in trouble.

    Above all, each team/environment must adapt for their situation.  These are guiding principles and practices that need real world applied to them.

    As a newbie to agile I am sure I have not understood everything right or deeply enough.  Please let me know what you think.  I like to learn from others!

  • Happy Learning!

    Agile | Books | Lean | Process | Scrum
    Posted 02.20.2010  #    Comments [0]  |