Tag Archives: Agile Management

Managing self-organizing teams in an Agile Software Development practice is about encouraging and allowing developers to embody values of collaboration, creativity, quality, integrity, and individual initiative in an environment that provides sustainable pace and opportunities for personal development.

Learned Helplessness

Posted on by

Dave Pollard has an interesting post, From Simplistic Thinking to Embracing Complexity.

On attempts at knowledge creation that don’t engage employees and customers…

such systems presume ‘learned helplessness’ of customers and employees: The customer, the citizen, is often viewed as a mere, passive consumer of your organization’s products and so-called wisdom. The employee, likewise, is assumed to be ignorant, stupid and disinterested in the success of the organization beyond his/her own job. Most people don’t take kindly to having their intelligence insulted. And failure to engage customers and employees in co-producing the product is a tragic waste of great opportunity.

Learned helplessness. Yup, that about sums up what it’s like to work for a product owner who refuses to let the team invest in the vision of a product. Complexity and invention don’t lend themselves to command and control.

There are individuals like Dean Kamen with a singular genius for invention. Still he emphasizes the value of collaboration – of sensitivity to others and society. His F.I.R.S.T. foundation celebrates the whole individual engaged with others in a technical challenge and the ethic of Gracious Professionalism.

It’s a way of doing things that encourages high-quality work, emphasizes the value of others, and respects individuals and the community.

Agile software development values collective ownership. However, there is shared code and there is shared risk and shared reward. When a FIRST LEGO League Team wins, I’m sure it’s not a single 14 year old product owner who accepts the prize.

For a development team to contribute beyond the bounds of technical execution, i.e. “his/her own job”, product owners need to approach them

…through conversations, stories, and presenting the ‘problem’ to them so they can help you appreciate it better and then address it. – Dave Pollard

Embracing complexity is about engaging the whole person not just the coder. With the person comes life experience, passion, and imagination. As product owner, use your authority to break through indecision but avoid the desire to tell the team how to solve your problems. Describe what you are trying to accomplish and why it is important. Get the team in touch with the customer and let them help you.

The result will be more than the formulation of a single mind. It will be more what the customer needs and, perhaps, it will be unlike anything else out there.

Context Switching

Posted on by

My team is currently working on two very different programs by pulling work off both backlogs into a single sprint. We did this for pragmatic reasons having to do with our size and the wishes of both the product owners and the team. This was working well when the two programs were clearly defined projects. However, we’re going through a rough patch with one program driving maintenance work and the other rallying towards release. We’re paying a price for context switching with lower point commitments overall per sprint.

Inspect and adapt.

The Washington Post published an article by Lori Aratani, Teens Can Multitask, But What Are Costs?

When subjects were focused on sorting, the hippocampus — the part of the brain responsible for storing and recalling information — was engaged. But when they were multitasking, that part of the brain was quiet and the part of the brain used to master repetitive skills — the striatum — was active.

The Journal of Experimental Psychology published a paper by Joshua S. Rubinstein, David E. Meyer, and Jeffrey E. Evans on Executive Control of Cognitive Processes in Task Switching. As an APA release summarizes:

…subjects lost time when they had to switch from one task to another, and time costs increased with the complexity of the tasks, so it took significantly longer to switch between more complex tasks. Time costs also were greater when subjects switched to tasks that were relatively unfamiliar.

Neither the article or paper distinguish results by gender. The First Sex says that according to gender specific studies women are better multi-taskers than men.

I bring up the gender differences because I work at a women-owned company. One of the benefits is seeing the world from my CEO’s point of view. Sometimes not identifying differences between men and women denies women opportunities, or worse, perpetuates harmful stereotypes. As a society, we are late to acknowledge that women present with heart disease differently than men. This has perpetuated a myth that heart disease is a male illness.

“(A)ccording to the American Heart Association (AHA), more women than men die from heart disease in the U.S., and 1 in 3 women is living with it today” – TIME Magazine

If women are truly better multitaskers, maybe they have some inherent advantages in certain kinds of jobs (like mine 🙂 ).

Both the men and women developers in my team have acknowledged that the context switching penalty has gotten worse recently. So whatever the difference in this case, some kind of scrum master response is required.

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.

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.