Tag Archives: Jeff Sutherland

Coffee and Ethics in Paradise

Posted on by

DSCN0680.JPG sunset at buddha point
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?

Re: Interaction designer in a Scrum team

Posted on by

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.

Concept Drawing from BrainstormingThe 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.

Don’t Justify Agile Based on Productivity (revisit)

Posted on by

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.

Cost Savings with Scrum

Posted on by

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.

CMMI and Scrum Productivity Gain

Scrum and CMMI Level 5: The Magic Potion for Code Warriors, Sutherland, Jakobsen, Johnson, Hawaii International Conference on System Sciences 2008

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.

[agile] or Else

Posted on by

Cork Board by kjudyJeff 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.