Tag Archives: Yahoo

HICSS-41

Posted on by

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.)

20070110 177HICSS 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.

The buck stops… where?

Posted on by

A fundamental value of computer ethics, agile and Scrum is truth telling.

As developers we have an obligation to provide honest feedback around decisions that affect either the quality or value of software our employer asks us to create.

I am now the senior person dedicated to software in my company. If that means anything it is that my responsibility has expanded to protect the best interests of my employer on any project we undertake that has software development dependencies.

The profound challenge in this is that while the company has expanded my scope of Responsibility it has not necessarily expanded my scope of Authority. As a mid-size, growing company we give department heads great discretion. My company is also one of many with a structural distinction between online and IT related software development. Therefore my team has no direct role in some of the most visible outputs of our company.

As a result, I cannot have true accountability for some outcomes since I cannot change them. That does not absolve me of my ethical responsibility nor allow me to narrowly define success in my current role. That is why to take my job seriously is to take on a certain amount of anguish.

The obvious answer is that I never should have taken on the role unless I was given commensurate authority. Perhaps this is correct.

I accepted the promotion because I believe it raises the profile of my team and makes more visible the quality and value return they are producing. I also believe that while responsibility without authority is flawed, it is a common state of play for those of us who introduce agile practices into a company. Let’s be honest, introducing agile is an attempt to lead change. Since I am not an entrepreneur it is a given that I will have to earn trust at each step of the way in making that change.

So given these circumstances, what is my responsibility to my employer around truth telling? Who am I obligated to tell truth to? Let’s focus on questions of value and quality and leave aside safety or legal concerns because as dramatic as whistle blowing is, that is not my reality.

Basic risk management tells me that the person who’s interests are most damaged should a problem arise owns the risk. In a functioning Scrum organization this is the product owner — or as Yahoo calls them, the single wringable neck. This one person is held accountable to the performance of a product in the market place. It is to them that any concerns over the value or quality of a software product need to be raised.

As I’ve said, I have a Scrum team but I do not work in a Scrum organization. There are times when projects originating outside my team do not have a clear “single wringable neck”. This presents a huge challenge. Who will be most affected by a problem if no single person is assigned real accountability for the outcome of a software project?

I have decided after hard experience that in circumstances where there is no responsible and empowered product owner the person most affected by problems is the person most identified with our brand and our products, my CEO. Therefore my responsibility for truth telling is to her.

This is, to me, a freeing realization for in it lies great opportunity for my company. My CEO who has proven herself to be an exceptional product owner. If anyone on the business side understands agile principles and my ethical responsibility as a software developer it is her. If anyone is capable of creating positive change in my company it is her.

Therefore, in the spirit of my CEO’s own vision, I will expect the best of people while maintaining my integrity and independent judgment to serve the best interests of my company, our customers, my peers, and our society.