How We Work

Thanks to Sven Fechner’s blog “Simplicity Is Bliss” I found a wonderful post from July, 2009, on Paul Graham’s blog discussing the difference between Managers’ schedules and Makers’ schedules.

It’s been a while since I’ve been a “maker,” but the impact of meetings came flooding back when presented in this context:

“When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.”

I’ve had teams request all meetings take place before noon and three meeting-free days per week (excluding daily stand-up, of course.) While effective for the team, the counter-cultural approach provides challenges for an agile leader, protecting the team from external, meeting scheduling forces. If you pursue a similar approach put some time (and energy) aside to manage the team’s meeting time.

As leaders what does manager time and maker time mean to fulfilling our own responsibilities? Read more to see how Mr. Graham incorporates the advantages of both worlds!

Pandemic Prep

Agile teams tend to co-locate in an effort to improve team effectiveness. These teams sometimes depend on location-specific “tools” like a physical task board and pair programming. With the potential for pandemic just over the horizon team members may need to/choose to work from home because of challenges outside the workplace:

  • no alternative childcare when a child or stay at home spouse is ill
  • a compromised immune system or a family member with one
  • becoming sick with Swine Flu themselves

Even with these challenges team members may be willing and able to work towards meeting commitments. As agile leaders we’re responsible for providing opportunities to meet those goals and provide our teammates opportunities for success.

Here are five actions you can take to prep your team for Swine Flu:

1. Move Your Task Board Online
Physical task boards are not available to team members staying clear of the office. Provide appropriate visibility into the team’s work using one of the many online solutions. Here are some options:

  • Rally offers a free “community edition” for up to ten users. An enterprise edition is also available.
  • VersionOne also offers a free “team edition” as well as an enterprise edition.
  • Pivotal Tracker is a free solution iteratively adding functionality and gaining popularity, especially in the Ruby/Rails space

2. Chat Online

Chat rooms are a great way to keep a distributed team connected. Discussions usually occurring in the team space move to the chat room for all to see. Some chat solutions even make chat history available for team members working modified schedules.

While IRC is the most used (free) approach there are alternatives. 37Signals offers Campfire, a chat solution with some nice bells and whistles.

3. Enable Distributed Pair Programming
While there is an Eclipse plug-in for pair programming another choice is VNC + Skype. The primary goal here is to meet the team’s pair programming commitment even while physically separated. Have a team member write up some getting started directions (on the team wiki?) and review the approach with the team.

4. Access the Mother Ship
Ensure all team members have access to development environments, portals and shared storage from home. Make up a checklist of assets and ask each team member to run through the asset checklist while remote.

If your organization depends on a VPN for access to corporate systems check with your IT department on the maximum number of connections. If necessary request more connections.

5. Forward Phones
Your phone system probably has call forwarding capability. Ask each team member to try it out. If you don’t have call forwarding make sure your team contact list is up to date (on the team wiki?) with mobile phone and/or home phone numbers.

Skype In provides an inbound call alternative for team members wanting to keep their mobile and home phones free for other uses.

The Test
Now to test it all out. Recommend a work from home day for the team, a user acceptance test of sorts! See if people are comfortable working from home, if they can access needed systems and understand how to communicate with each other when not face-to-face. Make sure they actually VPN in, pair program, forward phones, update the task board and chat! Open impediments for any shortcomings and retro the effort as soon as possible.

You may want to consider instituting a work from home day each week until all team members are somewhat comfortable with a distributed approach. Try working with a portion of the team in the office and a portion at home, the probable use case.

Next Steps
Stay prepared! Keep an eye on the swine flu maps and watch the local news. If you’re a Twitter user keep an eye on the #swineflu tag. Understand what challenges are headed your way. Fewer surprises means a better transition from co-location to a distributed team.

Good luck and stay healthy!

Pre-Planning & Fighting Fires

There’s a rich irony in the popular phrase “fighting fires,” used to describe the handling of negative, unplanned incidents. For real fire fighters an emergency response is far from unplanned.

Fire departments spend a great deal of time and energy preparing for the fire and rescue challenges inherent in the communities they protect. Risks are identified, action plans are documented and crews are trained. All of this information is culled into a pre-plan, quickly available to the dispatched crews.

A project needs a pre-plan, too. While I’m sure we all have documented project risks, each with remediation plans, those are just not enough.

Risks should also assume the worst, that the risk will be realized, becoming an issue. With this mindset documented risks should include a plan for resolution, or a pre-plan including details like expected actions, appropriate escalation and necessary resources. An added bonus of pre-planning is the opportunity to make thoughtful decisions far removed from the pressure of an emergency.

Creating the pre-plan is only the beginning. Make sure your team knows where to find those plans and how to put them into motion. If you have some aggressive SLAs take time to train against the pre-plan. Training is a great way to test your pre-plan’s effectiveness.

Why wait until a fire breaks out? Plan now!


My Catholic school English classes always emphasized diagramming sentences. What always made an impression on me was the dead-center location of the verb. Everything in the sentence is built around the action.

While recently dusting off Getting Things Done by David Allen (GTD)   the importance of “next action” and “action verbs” somehow brought me back to my grade school diagramming days and the centralized verb. I realized sentences with action verbs – powerful verbs – were much easier to diagram. It turns out strong verbs also lead to much clearer and actionable tasks! Merlin Mann does a great job of discussing it in his blog post “GTD: Project Verbs vs. Next-Action Verbs.”

That visit back to the “next action” of GTD and the diagramming drills required by our St. Joe’s nuns just happened to take place right before a team’s retro & planning meetings. It inspired me to look at tasks written by our agile scrum team in prior months.  That’s when it hit me between the eyes – we tend to use very weak verbs in our tasks, leading to weak “next actions!” I saw sentences containing weak verbs like handle, ensure and implement. (One task even included “etc.”, but I’ll leave that to another day.) Strong verbs were not as present as I’d expected.

This verb/next action theory seemed well suited to a team discussion. As I quickly discovered, teams, especially those with a low ratio of GTD’ers, may perceive the verb discussion as a semantic argument. Fortunately for us the discussion evolved into one about improving the detail in our tasks. If nothing else the current tasking exercise was more thoughtful (but I still think we can improve our verbs.)

Maybe I’ll diagram some tasks to make my point clearer next time.

Okay, maybe not.

Organizing to Lead

Success in an agile organization brings challenges to the organizational structure.  An agile team of up to 8 people can successfully self-manage and deliver more than enough functionality to win that big contract.  But once you win the big deal how do you organize 20 to 30 people successfully in self managed sub-teams?

A couple team members suggested similar team structures, all based on more traditional, large project org charts.  Recommended are vertical sub-teams responsible for product areas (architecture, baseline functionality, specialized/configured capability). There’s also horizontal competencies recognizing areas we tend to see as “specialized”, like Architecture, QC and User Experience.

Maybe it’s my experiences in similar org structures making me question this approach.  It reminds me of the “software factory” concept circa 1996.  We’re just missing a requirements gathering sub-team full of business analysts throwing functional design documents in the factory’s front door.

The “software factory” approach also takes advantage of defined program phases to modify staffing by phase.  Early in the program staffing is dominated by business analysts and architects.  As the program moves towards the development phase the majority of business analysts and architects are rolled off in favor of a development heavy skill set.  This approach continues throughout the life cycle until the only staffing left is maintenance team members.

Programs with a water tight Statement of Work (SOW), well defined change management processes and  semi-annual (or longer) delivery milestones can operate successfully in this scenario.

An agile approach does not contain a locked down SOW, program phases or an aversion to change.  Agile reacts well to change and user feedback, incorporating both into multiple, short (monthly) iterations.  As stakeholder and solution provider better understand the problem space and the evolving solution the possibility of near real time adaptations emerges.

Org Chart

Agile also requires the availability of multiple skill sets in practically every iteration. Analysis, architecture, development, testing and QC are needed on all teams throughout the multiple iterations making up the program life cycle.

I’ve been reading 37Signals book Getting Real. They’re a self described Agile shop focusing on a very light methodology. I’ve admired their ability to consistently improve existing products and roll out new ideas.  In their book they describe how, as a small company, they’ve achieved success from product focus through staffing, process and promotion.

In the organization section of the book they argue for unity.  Silo-ing perceived skill sets (developers, user experience, architects, quality control) leads to a loss of “big picture” focus. I’d add silo-ing refocuses the emotional attachment from the big picture to the assigned silo.

So why not create multiple, self-contained sub-teams with the necessary blend of skill sets? Allow the sub-teams to work throughout the solution, selecting stories based on priority, not vertical slice.  Spread the user experience knowledge around the sub-team; allow the architect to mentor developers; ensure all sub-team members are well rounded. Get the emotional buy-in of the team members. Let them see the opportunity for success, both personally and programatically. Most importantly this approach allows each team to develop potentially releasable software.

Ensuring sub-teams continue to pursue the same big picture requires each horizontal slice , or skill set grouping, meet regularly.  In Scrum we refer to this as a Scrum of Scrums (SoS).  Approaches and ideas are shared and coordinated approaches are drafted for acceptance by the teams.

Imagine that, a big company development program with an entrepreneurial spirit.  Maybe we can actually achieve it!

A Team of Volunteers

Recent organizational changes and increasing administrative/bureaucratic demands mixed with an unexpected resignation have me thinking about team member retention.  We’ve considered how to on board new team members but have we really thought through how to retain the team members we’ve invested so much in?

Even in a challenging economic environment skilled developers and architects are in demand.  A recent search of returned 116 requests for J2EE developers in the greater Philadelphia area. J2EE Architect got 34 hits.  Solid developers and architects have a wide range of opportunities just waiting for them.

So, are our team members really “employees” or are they “volunteers”?  Volunteers are those who give their time to an effort they believe in.  Your response might be, “Our people get paid and receive benefits so they’re not volunteers.” Volunteers in any organization are reimbursed for their efforts, whether it’s getting a warm and fuzzy for helping others, building skill sets or using interesting tools not otherwise available. (Can you tell I’m a volunteer firefighter?) It just so happens the volunteers on our project teams are reimbursed with salary and benefits, use of interesting tools, skillset building and sometimes even a warm and fuzzy.

What actions can we take to retain our “volunteers”?  The same actions great causes, campaigns and community organizations take to ensure a healthy, active volunteer base:

  • Make sure everyone knows, understands and buys into the mission.  What are you really trying to accomplish? Understanding the effort’s impact on the intended stakeholders is what turns a group of related tasks into a mission.
  • Reinforce positive actions and outcomes by highlighting their place in the big picture.
  • Provide a sense of belonging through team culture and communication.  Structure helps your volunteers (and you) figure out where they can contribute most successfully.
  • Provide opportunities to see the big picture.  Volunteers don’t stick around if they get pigeonholed into a specific role.  Firefighters maintain apparatus, fight fires AND perform vehicle rescues.
  • Help your people grow in the organization.  Every great volunteer organization is grooming new leaders, engineers, architects and fundraisers. We should be doing the same with our team members.  Let them learn through trial and error … especially error.
  • Have that tough conversation.  Volunteers want to know if they’re contributing.  They also know that if you’ve stopped providing feedback you’ve stopped caring.
  • Never stop recruiting a volunteer!  Once you have valuable volunteers make sure you keep them.
  • Say “Thank You” every chance you get.  Earning the appreciation of the organization and recognition for accomplishments is what really fuels all of us towards our mission.

Please don’t think I’m implying a need to coddle our team members.  Volunteer organizations are very good at weeding out those joiners not qualified to pursue the mission. The professional organization should do the same. Hold people to standards, enforce process and clearly communicate the team member’s capability to add value in pursuit of the mission.

Now I guess it’s time I go out there and follow my own advice.  Hey, team!  Let’s hold hands and sing Kumbaya!


Get every new post delivered to your Inbox.