Learning Culture

Posted on by

Miya in the Park
Three of our team are participating in this year’s NYC CodeCamp. Luke Melia is presenting Supercharging the WPF Command Pattern with Dependency Injection. Wendy Friedlander and Oksana Udovitska are presenting The Gentle Art of Pair Programming and Testing in C# with RhinoMocks.

I’ve always wanted to build a learning culture. Before embracing agile principles, we had a hard time fulfilling this aspiration. In retrospect, our definition of the developer role and what constituted success in that role was too narrow. Intensive classes on specific topics don’t suit many learning styles and there was no direct connection between a broader scope of learning and project outcomes.

Scrum and XP require continual improvement. They encourage reflection, engage a broad range of social and intellectual intelligences and tie those abilities to project success. They place you in a larger ecology of peers and mentors.

People striving to make a contribution love learning.

Coming to Work Sick

Posted on by

San Francisco has just required that most business offer paid sick leave. According to Benefitnews.com 43% of all American workers have no paid sick leave benefit.

Dev Room

Our development team spends most of it’s time in a group room around pairing stations.

Per Alistair Cockburn, commons allow for highly efficient warm modes of communication. Unfortunately, commons spread disease like a daycare center. One cold can easily work through three or four team members. Plentiful supplies of tissue, wipes and hand sanitizer are standard operating procedure.

As is strong encouragement that sick team members stay home. Ironically enough, with a performing agile team this is a hard message to communicate because they simply don’t want to let their team down.

Modern technology to the rescue! Our office is in Manhattan and we have workers who live in New Jersey and Long Island. In a city that manages to be shut down at least once a year for tragic or trivial reasons, we are setup to telecommute. We equip our team with laptops, headsets, a secure tunnel, skype and vnc. We’ve found that the developers work so closely and interchangeably together when in the office, they know each other well enough to overcome many of the disadvantages of short-term separation and cold modes of communication.

It’s typical to have a team member e-mail “I’m not feeling well but I’ll sleep through the morning and try to pair up in the afternoon.”

How closely we work together facilitates the ease with which we can remote. This mitigates how easily colds spread because we work so closely together. A beautiful symmetry in offsetting, unintended consequences.

Love of Craft (Continued)

Posted on by

SD Times has a brief item on the Standish Group CHAOS Study update. In 2006, 65% of sampled software projects were canceled, significantly late and/or over-budget. Over ten years of thought and practice have improved our success rate by a meaningful but disappointing 19%.

Business execution shares more than equal credit for our state of play. Four of the first five Standish Group project success factors are engaged, empowered and pragmatic product management.

There will always be a background failure rate no matter how excellent technical execution becomes. Things change and opportunities involve risks. Some well-executed projects will always fail to pan out. Still, 65th percentile is a mean aspiration.

I haven’t met a talented developer or development manager who wasn’t obsessed with self-improvement. Yet a focus on self isn’t enough. Standing out in the crowd may benefit individuals but it diminishes our craft. The failure around us lowers the hopes of society for what we can achieve.

Principle 7 of The IEEE Computer Society Code of Ethics says we should:

7.07. Not unfairly intervene in the career of any colleague; however, concern for the employer, the client or public interest may compel software engineers, in good faith, to question the competence of a colleague.

Inferior work embarrasses me. Behavior that perpetuates inferior work infuriates me. But when should we step beyond criticism of code to criticize those who author it? First, in good faith we should search our motives for self-interest and vanity. Opportunism is bullshit. Bullshit devalues truth. Bullshit destroys trust.

Ultimately we have a responsibility to protect the interests of those who pay us and the larger community who benefit from our efforts. We have a responsibility to society and the reputation of our industry upon which our potential to contribute to society depends. It’s our duty to find a way of expressing criticism that stands some reasonable chance of benefiting those interests.

Easier said than done where a power imbalance exists. As Ken Schwaber says in Agile Project Management with Scrum, “A dead sheepdog is a useless sheepdog.”

With all that to balance, how do we sleep at night?

When Should a Chicken Dive in with the Pigs?

Posted on by

I started talking about the manager’s role in scrum as facilitating a series of conversations between the team and the larger company.

The first of these is the product owner and the team.

As a manager, I have to constantly remind myself I’m a chicken, not a pig. My main responsibility is to deal with issues escalated to me by my scrum master. I also coach around practices. This is often about challenging team members to find their way towards our expressed values and principles.

On occasion, I do intervene in the dev room. This is dangerous ground. Innovation springs from the ability of an organization to surprise itself. Such creativity finds its source in autonomy, accountability and necessity.

Software development doesn’t proceed down straightforward path. For each unexpected problem there is a wealth of possible solutions. Ingenuity can add wasteful complexity or differentiate and define a product. You want a team to keep momentum but you want them to think deeply.

I need my team to be open to the problems before them, purposeful and playful in devising solutions but determined to release. This takes more than good work for good wages and it’s profoundly more than good leadership from managers. Project success has to be the individual team member’s success. Tomorrow’s intellectual property is not code yet to be written, it’s the inventive potential of the coders.

If I step in therefore it should be to maintain personal investment and esprit de corps rather than to reverse any individual decision. I have a scrum master and I rely on him to maintain morale and productivity in sprint reviews and planning. Still, with my experience as a developer and unique observer role, I’ll intervene in conversations between the product owner and the team to:

  • dispel misinformation
  • surface contradictions
  • flag intractable disagreements

Misinformation is toxic to the product and individual accountability. A misinformed team builds the wrong product. A pattern of misinformation leads a team to lose trust. They will focus on not failing in their narrow scope of execution rather than a successful business outcome. Playing safe eliminates surprise and invention and ultimately leads to failure.

Contradictions create opportunity. A solution that addresses both a value and its antithesis such as high quality and low cost can differentiate a product.

Some disagreements cannot be solved by conversation. Time and more information may resolve the conflict. Sometimes disagreements simply need to be acknowledged. In the spirit of “any decision is better than no decision”, the product owner or scrum master needs to be encouraged to move in one or other direction despite dissensus in the team.

All of this assumes the project in question is healthy. Intervention into a troubled project is a different animal [see my earlier post on stopping the line].

The Manager and Scrum

Posted on by

Jeff Sutherland posted notes from an open space hosted by Jens Ostergaard on Nov 2006. The subject was the role of manager in a Scrum.

  1. provide strategic vision, business strategy, and resources,
  2. remove impediments surfaced by Scrum teams that the teams cannot remove themselves,
  3. ensure growth and career path of employees, and
  4. challenge teams to move beyond mediocrity

For me, introducing agile practices has been evolutionary not revolutionary – five years work, three title changes and counting. My role is to make sure the team’s accomplishments build towards something progressively more and more valuable for the company and the individual team members.

In my experience, this involves facilitating a conversation between the business and the team on at least three levels:

  • Product owner and product team,
  • Organization and employees, and
  • Leadership’s grand vision and the team’s accomplishments.
The Oxygen team and management

[the oxygen team and management]

I’ll go into this in more detail in later posts.