It’s my final day on the Big Island after HICCS-42.

Unfortunately, I was a ghost at the conference. I spent most of the week tightly tethered to my East Coast work day. Much sleep deprivation, anxiety and coffee consumption.

I did see the Agile/Lean presentations chaired by Jeff Sutherland and Gabrielle Benefield and participated in the Ethics sessions in which I presented my paper. These were the main reasons I took this very expensive non-vacation and so I’m grateful for how things worked out.

Sounds like there may be an Ethics minitrack again next year. Apparently, this is a relatively unique thing in IT conferences academic or professional and an indication of why HICSS is such an unusual event.

The conversation around my paper may have sparked research interest. My “ask” of the largely academic audience was:

• Learn more about agile
• Research dilemmas in an agile context
• Educate us about the larger concerns
• Create safe venues for discussing our dilemmas
• Write about things beyond business value and efficacy

We need all hands on deck. We need to learn from other, more established disciplines. We need better data gathered with greater rigor and without the coda of a sales pitch.

How can we build software with consideration for benefit and harm as well as business value in the interests of society and our users as well as our employers and stakeholders?

How do we evolve from head count to the engineers/craftspeople we need to become?

Posted: January 9th, 2009 under software development.
Comments: none

Just posted a reply on the Scrum Developers Yahoo Group. Keeping up with that list would be more effort than becoming a certified scrum master.

What I am interested in is to find out how graphical and interaction designers can be eased into Scrum development.

In my previous team, our UX director, Bob Calvano, mixed in with the team: proposing UI elements in mockups but also pairing with developers to collaborate on implementations. The team and UX director shared decisions but the UX director retained authority over them.

The team and product owner learned to defer to him on thorny questions of emotion, aesthetic and interaction particularly where the product owner had no clear sense of how the decision impacted tangible customer value.

The team had to learn how to deliver constructive feedback on UX. They had to learn how to express personal opinion in that context.

The UX director needed incredible patience taking in well and poorly delivered feedback. He had to understand his own process well enough to use day to day input to enable his own creativity rather than shut it down.

We evolved this relationship in a small team in an environment of high trust and we took months getting there. He came from a more traditional agency approach but he did have a personality suited to collaboration.

He eventually left our team to become an Interaction Design Director at one of the top agencies. He did so because the high profile of the work and pay were irresistible, so this experience didn’t hurt his career progression or his ability to work other ways. Though I know for a fact he misses that team and is returning to a smaller environment where he can recapture that collaborative experience.

thoughts from people who have read Jeff Patton’s book and what they think about how his ideas fit with Scrum.

Haven’t read the book yet. Talked to Jeff about his ideas at Agile 2007 (He was my adviser on my presentation on product ownership) and at the Fall Scrum Gathering.

High praise for his thinking on user experience as a precursor in product development (why) not simply as part of execution (what).

We tend to focus on story writing as the first tangible step agile plays in product conception. There are whole worlds of collaboration in terms of understanding who the software is for and how it solves problems for human beings that should come first.

Jeff Sutherland says the vast majority of teams run Scrums without real backlogs. How many of those few product owners that have backlogs derive systems and features from a user-centered perspective?

Hoping Jeff Patton will give us practices to tackle that problem.

Posted: April 26th, 2008 under scrum, software development.
Comments: none

Kallokain wrote a rebuttal to my post questioning the value of productivity metrics to justify agile.

In a recent article Ken Judy takes the stand that agile software development should not be adopted on the grounds of higher productivity. The reason for that, Judy claims, is that there are better ways to justify adopting agile than with hard numbers.

I can sympatize, because I have worked in my share of software development projects where the measurements did more harm than good. Nevertheless, I believe Judy is wrong in this instance. Most organizations measure the wrong thing. That does not imply that measuring is bad in itself. (read the post)

Just to be clear, my objection is not that agile should not be justified by hard numbers but that I haven’t seen a metric for productivity gain specifically that both stood systematic scrutiny and was economically feasible for the average business to collect.

In my experience, measures that are tied to some non-revenue related abstract concept of “productivity” such as lines of code, story points, etc. are more problematic than helpful.

My point about velocity is that it is a measure that should be a feedback system back to the teams and becomes problematic if it is considered some sort of intrinsically meaningful measure that can be reported to senior executives (as in “We completed 20 story points last iteration, 25 this iteration. We’re five story points more efficient!”)

I agree that the ultimate measure of success in business is profit. I understand that any business decision should somehow influence revenue gains or hard dollar cost savings.

The problem with justifying an agile adoption based on revenue gains is there are so many other considerations that attempts to credit any single factor become dubious.

Cost savings need to be real not theoretical. Who did you lay off? How much budget did you give back based on agile adoption? Jeff Sutherland has a paper that does show significant cost savings using Scrum. The subject company was a CMMI-5 organization and there commitment and rigor to measurement was higher than most companies would support and is cost justified based on the government regulations they perform under.

If someone can propose a relevant metric that is economical for a small to medium size business to collect, that can be measured over time in small enough units to show increased performance due to specific process changes, that has some relation to reality that can be meaningfully communicated to senior managers, and doesn’t create more problems than it solves, I will be happy to consider it.

Posted: February 19th, 2008 under software development.
Comments: none

Jeff Sutherland published a paper at HICSS-41 that documents cost savings a CMMI level 5 organization delivers switching to Scrum.

As I just wrote, I would not invest in productivity measurement to justify agile adoption.

But a CMMI-5 company invests in more measurement than I would ever do so let’s take advantage of what they learned. While taking it with a grain of salt.

The company believes work costs about half as much if they use Scrum instead of their best of breed CMMI level 5 waterfall practice. For those of you who hate process, lack of a disciplined process (CMMI level 1) costs even more.

Jeff says this company does a diverse mix of work both in terms of size and platforms and that the results hold. I would want to know more about the company’s engineering practices both before and after but since Jeff is involved I’ll assume this is one of the small percentage of teams who claim to be doing Scrum that are really doing it.

Posted: February 10th, 2008 under scrum.
Comments: none

Jeff Sutherland said he was finding more developers who will only work in agile software development teams.

He also said that to his estimation about 10% of shops that claim to be practicing Scrum pass the Nokia test and have self-organized teams, product backlogs prioritized by a product owner and estimated by developers.

And that doesn’t even speak to refactoring, test driven development, pairing, continuous integration, built in quality, acceptance testing, etc.

And that doesn’t speak to knowledge creation and sharing practices across the entire organization, clarity of vision, understanding competitors, collaborating with customers, continuous improvement, and embrace of change.

I’ve come to understand that agile values place demands on development, management and business practices.

Two questions arise from this:

• Would you only work in an [agile] shop?
• What do you mean by [agile]?

for [agile] feel free to substitute: Lean, XP, Scrum, XP/Scrum, Crystal, Adaptive, etc. etc.

Posted: January 19th, 2008 under Uncategorized.
Comments: 1

I just presented Ilio Krumins-Beens’ [and my paper] on unbounded collaboration between the product owner and development team at the 41st Hawaii International Conference on System Sciences. (I’ll link off to the paper when the transaction is published on the IEEE site.)

HICSS is an interesting mix of academics and practitioners. On the list of presenters in the agile mini-track were Jeff Sutherland, Stephen Cohen from Microsoft, and Gabrielle Benefield from Yahoo as well as researchers Ann Fruhling from the University of Nebraska at Omaha, Kevin Kwiat from the Air Force Research Laboratory, and David F. Rico.

HICSS is an instance where the academy has invited us developers into their living room to discuss what we do, the way we actually do it.

There’s a huge disconnect between what I practice as a software developer and what many institutions of higher learning teach.

Theoretical exercises in waterfall practices are not helpful precursors to TDD, pairing, continuous integration, refactoring, interdisciplinary collaboration, self-organizing teams, etc. etc.

Arguably, they are not even helpful precursors to waterfall as it’s actually practiced. If you think XP requires experienced developers what the heck do you get when you make someone with little experience architect a market trading system in UML!

We need the academy to understand us. They not only train our workforce, their research informs policies, standards and business management practices that shape government and industry expectations.

We need business schools that train prospective CXO’s to build lean businesses that will in turn build out agile/lean IT and product development organizations.

Another big barrier to agile adoption is lack of empirical support for the benefits of specific Lean, Scrum and XP practices. We need original research that correlates to the obvious things: quality, risk mitigation, market performance, productivity and cost reduction.

I’d also really love to see original research on how agile, highly collaborative practices correlate to ethical behavior on the part of individuals and organizations, gender and ethnic diversity, and sustained innovation.

Posted: January 10th, 2008 under scrum.
Comments: none

This is the third pattern of collaboration that entrenches status quo.

“Contrived collegiality” and “balkanization” suggest a certain amount of bad faith. Bounded collaboration is a subtler dysfunction.

A pragmatic and collegial relationship between a product owner and team can honor roles and feel like collaboration while barely tapping or actually working against the potential of a project and its participants.

We may simply define our contribution too narrowly.

A development team may communicate to a product owner only during formal inspection points. They limit co-work to the immediate needs of the project and not range to larger questions and concerns. Under the pretext of “single, wringable neck” they shield themselves from the struggle to shape a business outcome and stand at a distance from the product owner.

“Bounded collaboration rarely reaches deep down to the grounds, the principles or the ethics of practice. It can get stuck with the more comfortable business of advice giving, trick trading and material sharing of a more immediate, specific and technical nature. Such collaboration does not extend beyond particular units of work or subjects of study to the wider purpose and value of what is taught and how. It is collaboration, which focuses on the immediate, the short-term and the practical to the exclusion of longer term planning concern.” — A. Hargreaves and M. Fullan

Seeming collaboration limits business opportunity and works against sustained invention and true innovation. “Contrived collegiality” and “balkanization” are forced upon us but what boundaries do we ourselves create? To what degree do we champion agile practices while surrendering the values that inspire them.

Jeff Sutherland cites the exceptional Borland Quattro Pro development team as a significant inspiration for what became Scrum practice. He also points out that Quattro Pro didn’t win in the marketplace.

Superior technical execution and transparency to a single, empowered product owner is not, unfortunately, enough. We developers need to move beyond how and when to engage a broader set of questions over what, for whom and why.

We need to work jointly with our product owners to understand the opportunity, the end users and the value our software brings to them.

Posted: January 2nd, 2008 under scrum.
Comments: none

Jeff Sutherland has an interview on InfoQ where he describes the Nokia Test for evaluating whether a team is practicing Scrum:

Iterative Development
A precursor to Scrum is practicing iterative development of any kind.

1. Fixed iterations of not longer than six [weeks]¹
2. Working software at the end of each iteration
3. Start iterations without requiring a “complete” specification
4. Testing during rather than at the end of iterations

Jeff states, “this rules out about half of (self-identified) Scrum teams.”

Scrum
The minimum to foster self-directed development teams working to clear business priorities using the tracking mechanisms of Scrum.

1. Got a product owner? A single, empowered person who works directly with the team to determine what to build.
2. Does the product owner have a product feature backlog? Is that backlog prioritized by business value? Is it estimated by the team?
3. Track work with a burndown? From that, can you derive a velocity?
4. Hands off during an iteration? “Nokia has a rule that you can’t have a project manager interfering with the team in the middle of an iteration because that stops the self organization.”

Jeff’s been saying for years that if you don’t have a backlog, you don’t have Scrum.

The first thing we lost in the acquisition process was our product owner. From there the rest deteriorates. Without a strong, empowered product owner the backlog becomes arbitrary and so does planning work against that backlog. See what that does to talented developers used to fueling themselves on intrinsic motivation.

It will be at least as hard to re-build these practices as it was to build them in the first place. The work of the new year and perhaps many years to come…

¹ corrected from six months to six weeks.

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

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

I was just asked whether I had metrics to demonstrate our pairing practice benefits the business compared to waterfall.

In my business context, I can’t cost-justify the kind of measurement Jeff Sutherland illustrates in his paper demonstrating efficiencies with Scrum in a CMMI 5 organization. Someone needs to do the same thing for XP practices. We have raw data from our revision control and tracking if that will help.

What I have to say is subjective. As a VP, I want our work more innovative, our code more maintainable and our progress more predictable. Pairing supports these goals in the following ways:

Shared Ownership

A risk managed approach to IT encompasses the bus test – how deep a hole are you in if one or two key people we’re suddenly unavailable (as in hit by a bus). Aside from specifications, waterfall tries to solve this with comprehensive code reviews and standards guidelines. In my experience, these were good intentions that NEVER happened. The problem was they sat outside the inherent work of writing code and felt like overhead.

In pairing with switching, these goals are largely accomplished in real time. And rather than management pulling teeth, the team themselves champion it.

Visibility

In a waterfall process, accurately monitoring progress takes great amounts of non-value adding effort by someone with a high-level of development experience. In pairing, the pair is constantly discussing progress. A project manager (or scrum master in our case) in the room, is able to learn a lot osmotically without pulling developers off task.

Momentum

As a developer myself, I understand that even the most talented coder can get side tracked, distracted, bored or otherwise stall out. Pairing forces focus. In a culture of collaboration fostered by pairing, developers use each other to break through obstacles. Progress is much more predictable and developers produce more efficient and purposeful code.

New Hires and New Learning

Bringing new or junior members up to speed is a high overhead to a small team. Often, the best learning happens when two people of roughly the same skill work together. Sometimes someone with less experienced needs mentoring by someone with more. Pairing ensures each person has the opportunity to learn from everyone else. Carefully vetted, new hires on our team begin contributing within the first sprint.

I have complete confidence my team can bring in new technologies and languages. They’ve proven it to me with Ruby, WPF, and SQL Server OLAP/Analysis Services.

Creativity and Collegiality

The types of people who seek out a pairing environment are social, take initiative and want to engage in the big picture. These types of developers create a vital workplace and contribute more fully to product development. I’ve written several papers getting at the relationship between collaboration and innovation.

Pairing fosters friendships that extend beyond the workplace. Gallup has found a high correlation between worker engagement and whether they believe they “have a best friend at work.”

To Conclude

I admit these are all subjective observations. However, my day to day experience convinces me our team is much better for our pairing practice.

Since we began pairing, even the most senior of our developers has grown their technical and interpersonal skills. We have delivered predictably for our business on multiple streams of work in diverse, sometimes emerging technologies. I’m confident we can maintain our applications no matter which team member takes vacation.

Finally, not one of my team “clocks in”. They bring their whole selves to our work and our workplace. If a manager needs a chart to tell them why that matters, they shouldn’t have authority over people.

Posted: October 30th, 2007 under Uncategorized.
Comments: 1