I’m presenting a paper, Great Scrums Need Great Product Owners, at the Hawaii International Conference on System Sciences.

The presentation is part of the Agile mini-track co-chaired by Jeff Sutherland and Hubert Smits. I co-authored the paper with the senior member of my product team, Ilio Krumins-Beens.

We survey literature to describe pragmatic and collegial relationships which satisfy the definition of collaboration and honor roles while barely tapping or actually working against the potential of a project and its participants. These limited forms of collaboration are common not just in our industry but within agile projects.

A common interpretation of the call for a single Product Owner is that the development team itself should play little part in shaping the vision and value priorities of a product backlog, focusing instead on efficient delivery of those priorities.

One of our major sources are the What’s Worth Fighting for series by Andy Hargreaves and Michael Fullan on collaboration in education.

The disempowering climate faced by teachers is a direct parallel to that faced by software developers disengaged from the business vision and value priorities of their work.

“… [W]e have collectively 45 years of teaching experience and nobody has ever asked us our opinion about anything where it would actually be put into action. And yet I’ve got to have more experience with junior [children] than a lot of the people who are telling me what I should be doing with them. And I think that is very frustrating… I think I could help bring a lot to it and nobody ever asks, no one ever asks what we think. They just go ahead and proclaim and we have to follow.”

Its tragic how talented, experienced people are not allowed to bring their full selves to their work.

We contrast this with unbounded collaboration between a product owner and team. In unbounded collaboration an individual’s contribution is not constrained by their role or status.

It is a collaboration built upon high-performance, mutual respect and deep trust. The product owner walks a tight rope, engaging the team in an evolving product and business plan while guiding the project toward her vision and high-level goals. The team is passionate about the product they are building and feel personally accountable to the product’s success.

We argue that this kind of collaboration is at the heart of agile values and is a characteristic of the knowledge-creating companies upon which lean principles are based.

I’ll write more about unbounded collaboration, it’s opposites, practices we’ve used and what we’ve learned.

Posted: December 19th, 2007 under scrum.
Comments: 1

A metaphor for the Scrum Master is a vigilant sheepdog protecting their flock.

At the Fall Scrum Gathering, I met practitioners facing different challenges in their agile practice.

Some faced profound impediments that their organizations were unable or unwilling to address. The effect on the project and team was dire and the Scrum Master had exhausted all avenues to raise alarm.

It’s human nature, unfortunately, to associate an unpleasant message with the messenger. A vocal Scrum Master can be seen as the problem.

In those fraught circumstances a Scrum Master has to balance the interests of the team, the company and themselves. Can the project deliver in spite of the obstacles? Should the Scrum Master accept the dysfunction or not? At what cost?

As Ken Schwaber says in Agile Project Management with Scrum, “A dead sheepdog is a useless sheepdog.” Still, a useless sheepdog is also a useless sheepdog.

As JP Boodhoo says, “develop with passion.” As my friend Luke Melia says, “live with passion.”

Posted: December 15th, 2007 under scrum.
Comments: 3

I was recently asked the following question:

“I’ve been dropped into a situation best described as “story card hell.” How do I reduce complexity of the software project planning without losing features?”

The project was to replace an existing system. The behavior was largely known. As a result, the initial planning generated enough cards to feel like, “way too much detail up front.”

My answer:

Don’t lose the work you’ve done but don’t place more value in it than it has.

Step back to think of the application as a phased set of releases. Talk with the team and product owner about a way of delivering the system in meaningful pieces that customers could (and hopefully will) use. Get creative with defining those steps as long as they lead you down a path towards your ultimate goal.

Once you have that road map. Do an exercise with the team to group your existing stories into those releases. There will be a natural tendency to add and change stories. That’s fine but don’t get too distracted by it. The main point is to get a sense of the relative size of the releases and move the bulk of the stories out of your immediate planning concern.

Now focus on the first release. Spend more time on those stories but still not with the scrutiny of an iteration plan. Make/allow the team to live with ambiguity. Set up an agreed upon rule of thumb for how much bigger a “theme” is from a real “story” and let the team know it’s okay to discuss these things at the “theme” level.

Then prioritize your release backlog. Have the team chunk the remaining vague stories/themes into future iterations for that release. This is your release plan. Expect it to change. Again, you’re getting a rough sense of how many iterations in the first release and moving later stories out of your immediate concern.

Now you can focus in detail on the stories for the next one or two iterations without getting drowned in details. Don’t be surprised if future stories become irrelevant or drastically change as you get to the iteration within which they fall. It’s okay.

My answer was based on what we’ve tried to do at Oxygen with coaching on release planning from Hubert Smits.

Here’s the full thread off LinkedIn.

Posted: October 31st, 2007 under scrum.
Comments: none

We have seven developers growing to eight. The team is funded from two P&L’s so from the outside we’re considered two teams. We work on two projects at a time, one from each P&L.

We used to run one backlog with developers pulling stories from either project. In the sweet spot where both projects ran smoothly this was great. But that proved short-lived. Churn in one project slowed the other and context switching took a toll on the team.

So we split the work into two backlogs. Everyone sits in the same room but developers are “assigned” to one project. As a side note, I actually planned on having two rooms but the team said “no”.

This change has created more focus. Developers know what they’re working on, churn in one project has less effect on the other. The Scrum is easier to run, plan and track and progress appears more regular.

The change is a qualified success. Four may be too small for sustainable pairing. If anyone goes on vacation or is sick, the pairing practice starts to break altogether.

So to retain the focus of two small teams but gain the benefits one slightly larger one, we’ve loosened the assignments. Developers are asked to work on a specific project but they can switch if they feel the hate. The leads can switch people as well.

Management is often about embracing contradiction. We need to find our way to both variety and focus. It’s all a work in progress.

Posted: September 28th, 2007 under scrum.
Comments: 1

My team built an XP practice before introducing Scrum. The desire for change arose within the developers and was about sharing, becoming better at our craft and making our productivity and quality more consistent.

Scrum became necessary when our biggest problems were no longer within the team but in how we took on work from the business.

I started thinking about that at the last XTC-NYC when Mike Roberts wondered aloud if Scrum software development can work when a team doesn’t practice at least some aspects of XP. In a similar vein, Scott Bellware has a post about XP deserving more credit for Scrum’s success.

At XP-Spin, Jeff Sutherland said the success you build on is delivering working code at the end of each iteration. To even begin you need work described in achievable stories with acceptance criteria and daily builds.

Mike and Scott are definitely right when I look at my team.

Our present challenge is aligning our development with a clear and achievable business objective. Scrum is the tool for that. One of the things about Scrum is that you can use it for almost any kind of work requiring cross-functional teams.

But that challenge only exists because we were highly productive at creating quality software. The team’s XP practice with its low formality and high discipline gets the credit for that.

Posted: September 21st, 2007 under scrum.
Comments: none

I laughed out loud when I saw Ken Schwaber titled a passage of his book, The Enterprise and Scrum, “Just Do It”.

Ken describes how a customer can sacrifice quality and sustainable pace in the short term but pay it back at a premium, “$4 to remediate every $1 drop in quality.”

Clearly there are pressing bugs, misses and serendipitous opportunities. There are times to inject work into a sprint backlog. There are even times to “stop the line” and reset a sprint.

But when you manage a self-directed team, “just do it” — and I’ve heard that very phrase — is bullshit.

Just characterizes another person’s work as easy. It is the people performing work that need to estimate it. They are on the hook to execute and are incented to think critically in detail about what they are taking on. The worker grasps the actual effort better than the executive.

Do characterizes the work as physical action. Software development is problem solving and abstract modeling, i.e. knowledge work. “I’m typing as fast as I can?!” Even industrial lean practice relies on workers engaging beyond the boundaries of the immediate task to improve the product and the process of manufacture.

It characterizes the work as a single, clearly defined task. Again, the person doing the work determines whether they clearly understand assignment. Otherwise, you’re not admitting to any ambiguity of language, hidden complexity, or potential misunderstandings.

Just do it is a one way directive that splits responsibility from authority, i.e. YOU just do it. It signals a leader is not willing to do their part to remove obstacles for their team.

Just do it hides inefficiency under a veneer of necessity. Is it a surprise that “just do it” finds companionship with “just the way things are done” and “just the nature of the business”?

All this to say “just do it” in knowledge work is bullshit. The value lies not in the truth or falsity of the statement but the effect it has on the hearer. It dismisses workers’ concerns and excuses management from accountability.

Moving from bulls to birds, if self-directed teams are the goose that lays golden eggs, “just do it” is a pellet blast in the ole’ egg layer.

Posted: September 16th, 2007 under scrum.
Comments: 4

It’s a privilege to be granted authority in another person’s company.

It’s easy to criticize. It’s hard to raise capital and make payroll.

I have never been an entrepreneur. My passion is to build teams. To be of service. To make things better.

I’m that second generation that feeds off founding vision and hopes to sustain an organization.

This has been a good week.

• We achieved our first business objective on our standard bearing product initiative, Ript™.
• My CEO is championing agile values in my division’s executive team – accountability to specific commitments within a time box.
• Managers in a peer group recognize the potential of self-directed, cross-functional teams and are interested in introducing the first scrum outside my department.

I am a cautious optimist. Success is far from inevitable. Actually, all this represents is an opportunity to start the really hard work.

Still some moments, especially ones years in the making, need to be savored.

Posted: September 14th, 2007 under scrum.
Comments: none

I’m half-Japanese but my wife introduced me to Anpanman by Takashi (嵩) Yanase (柳瀬).

I can’t give any better description than the Japanese Media Communication website:

“Anpanman will go anywhere to help anyone in trouble, to drive away villains, and to save people from starvation by allowing them to eat his face.”

“Anpanman is the hero of the new age, glowing with friendship, endeavor and justice.”

Posted: September 10th, 2007 under scrum.
Comments: 1

I’ve posted about why I need to encourage agile practices outside my department.

If Scrum is isolated within one team, its very success can be used to counter further adoption. “Agile works for you but what we do is different. You do X we do Y.”

This resistance is a direct result of what Andy Hargreaves calls balkanization — groups insulated from each other, with hard boundaries, loyalties and a political complexion.

Creating a culture where groups work together to improve the organization is core to lean and agile. So the best ways to counter balkanization are the very principles under challenge.

I’m tackling this top-down by lobbying senior executives to bring in an agile/lean coach, bottom-up by removing impediments for my team, and, perhaps most significantly, sideways by initiating a Scrum in another department.

I have tentative approval from another department’s senior managers. Now, I have to meet with line managers and identify a backlog of work. Then solicit volunteers for a team.

I’ve taken Ken Schwaber‘s words to heart and asked them to Scrum their hardest challenge or the work they think least suited to agile.

So many things can go wrong. Of course, nothing that isn’t already going wrong. That’s the point.

Scrum will highlight those problems and make solving them obvious and necessary if no easier.

More to come…

Posted: September 9th, 2007 under scrum.
Comments: none

I’ll be presenting two talks at the November Scrum Gathering.

One of them is dear to my heart. I’ll be using this blog over the next few months to work up my ideas and document conversations I have around this topic.

The Ethics of Scrum and Agile Software Development.

Here’s what I proposed:

Presentation Description

Are Scrum and XP inherently ethical?

In the face of contradictory beliefs over what we do and how we do it, we software developers, agile or not, experience pressure to compromise our work and our due care for others. Meanwhile, as our products become more beneficial, more pervasive and inter-connected our potential to harm grows.

Attempts by the ACM and IEEE to engage us in a dialog on norms of conduct has resulted in a controversial code of ethics that borrows heavily from established engineering disciplines – mandating specifications to ensure effective software.

We, agile software developers are making an under-appreciated contribution to ethical practice in our field.

Whether our work is a profession or craft, we need to engage the larger community in a conversation about how our day to day actions affect our employers, our peers, and our society. This presentation will attempt to frame professional ethics in the context of agile values and practices.

Why is this topic of interest to Scrum Gathering attendees?

The discussion over norms of ethical conduct happens outside the earshot of most working developers. The day to day experience of Scrum practitioners is at a distance from those who concern themselves with software ethics.

As a Scrum community, we have a responsibility to help shape the expectations placed upon us by others. We cannot delegate our integrity. Nor can we defer concerns over negligence, recklessness, or intent to harm the human beings who use the systems we create. We openly discuss our projects, our working conditions, and our advancement but to protect those very interests we often deal with issues of conscience privately.

Yet the passion behind Scrum is, in part, an idealistic one – a hope that by dealing openly and responsively with our stakeholders we will build something of real value. We need to harness this idealism to encourage each other make better decisions in the interests of stakeholders who do not pay us and do not always have a seat at the project table.

Given the downstream effect ethical lapses large and small have on society, we need to engage in this discussion or have the wrong solutions imposed upon us by employers, institutions, and regulatory agencies.

Presentation Objectives

1. Is it important for us to establish a shared commitment to ethical conduct?
2. What obligations a software developer should feel beyond fulfilling the requirements of their employer?
3. How the Agile Manifesto and Scrum/XP practices suggest a partial set of norms of ethical conduct.
4. How agile organizations have started to provide their own statements of principles to extend agile values and encompass conduct towards our peers and society.

Posted: August 30th, 2007 under scrum.
Comments: none