I began advocating agile principles at my company four years ago. Over time, my co-workers and I have grown into a Scrum/XP team. We have a track record of successful projects and a handful of supportive sponsors. Senior executives value our developers. My CTO understands the team dynamic itself is the prize asset.

Having reached a milestone on one of our larger projects and seeing ambitious work ahead, I wanted to write about how I stood at a crossroads: contribute to the team or attempt to nurture agile values elsewhere in the organization.

It’s a pleasant, contrasting choice. But it assumes a lone agile team can thrive after becoming visible to the larger organization. There are two pressing reasons why I doubt this is true:

• An agile team attacks impediments from within or without. Either the team makes progress against these obstacles or it declines.
• Human nature abhors exceptions however exceptional. If the organization doesn’t become a little more like us, it will surely, inevitably re-make us to be more like it.

So, no crossroads. One path lies before me and it looks surprisingly familiar.

As I did four years ago, I must advocate agile from within and peer to peer. This time around, I have success at my back but face longer odds.

Scrum the project. Scrum organizational change.

I can only make progress one step at a time. I must demystify what we do by allowing more chickens into my team’s reviews. I must find and coach others predisposed to agile values. I must find at least one executive willing to scrum a thorny project with their staff. If I get the chance, I must seek out expert coaching for those above and across me in the organization.

As four years ago, success relies more on others than on myself. But I believe, as before, that not trying is worse than failing in the attempt.

Posted: August 27th, 2007 under scrum.
Comments: 1

Oxygen Software Development is off to Agile 2007. Four of us are speaking:

Ript™: Innovation and Collective Product Ownership
by Ken H. Judy and Ilio Krumins-Beens
XR11: Product Ownership
Thursday, 4:00pm

In 2006, Oxygen Media CEO Geraldine (Gerry) Laybourne, the woman largely responsible for Nickelodeon’s early success, partnered with her XP/Scrum development team to create a new mission and new revenue stream for her company. This experience report covers product conception through initial release of a single product. It describes how Gerry’s leadership qualities paired with agile practices to engender deep mutual trust and collective ownership over technical execution and business outcome. This unbounded collaboration provides a template for future projects at Oxygen and other organizations with innovation as part of their agile product development strategy.

The Gentle Art of Pair Programming
Oksana Udovitska and Wendy Friedlander
Wednesday, 8:30am

The presenters build upon their experience as software professionals and the pair programming practices employed at Oxygen Media, the first and only cable Network owned and operated by women, to teach The Gentle Art of Pair Programming. This tutorial will cover the basic principles of pair programming, why it is a worthwhile practice and how to get started. Discussion will include how to take full advantage of pairing and how to cope with its challenges. For those new to pair programming, this will serve as a good introduction and include concrete first steps. For those already in a pairing environment, this presentation will include new viewpoints and interesting discussions on familiar topics. Additionally, everyone will benefit from the interactive and fun games for improving and enhancing communication skills. Being women in a male dominated profession gives the presenters unique perspectives and insights into pairing which they are eager to share in passionate and exciting ways.

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

For the last year, our development team combined work from two different product backlogs into one sprint backlog.

One product backlog contained work in support of mission critical television operations. The other was our first consumer software effort, Ript™.

In taking on a sprint commitment, the team did their best to honor a 55%/45% allocation roughly measured in story points. Our primary revenue stream had the higher allocation and the higher priority. The team was to prevent obstacles in the Ript project from endangering commitment to mission critical television support.

We had good reasons for doing it this way. It worked for a while. Then it didn’t. We’re adapting.

Why we did it

• With six developers we were too small for two teams. We pair and didn’t want a two person team. Been there. Done that.
• We wanted contribution from everyone on Ript. Jointly conceived and striving for innovation.
• We wanted everyone to be familiar with our mission critical applications.

Why it worked

• Our television support projects fit in a cohesive program, were predictable and reliably estimated.
• The team felt a strong emotional commitment to Ript.
• The team has a mature Scrum/XP practice.
• We let the team manage the allocation while holding them accountable to the commitments they set.

Why it stopped working

• The television support work transitioned to an unpredictable mix of smaller projects and maintenance.
• Ript grew into a larger project and strained against the allocation assigned it (effectively 2.5 heads).
• Ript raised enough interest that it became a higher priority to the company.
• We foresee an ambitious portfolio of projects coming up from both sides of the business.

How we intend to change

• Grow to create two four person teams.
• Each team will focus on one line of work.
• Run two sprints on sync’d two week cycles.
• Have a co-located product owner proxy for each team.
• Share the Scrum Master.
• Two senior developers (manager and coach) will swap between the two projects daily.
• The remaining six developers will more slowly rotate among teams at sprint intervals.

We’ll still have to balance maintenance and project work within each sprint backlog but we will avoid drawing work from two product backlogs. That solution fit a particular set of challenges from our business and I don’t regret having done it but now it’s time to adjust.

Change drives more change and I expect our actual practice to adapt in ways we haven’t anticipated.

The thing is, as long as we managers protect the integrity and cohesion of the department, I’m confident the team will be able to respond. We’re committed to the company. We’re committed to each other’s success.

Posted: August 9th, 2007 under scrum.
Comments: 1

Informed Consent — “the right of each individual potentially affected by a project to participate to an appropriate degree in decision making concerning that project” (Gail D. Baura, Engineering Ethics: An Industrial perspective)

“(T)he astronauts should have been informed of the possibility of O-ring failure before the Challenger launch…” — G. Baura

Often the people asked to pay down a risk are not the ones who suffer if the risk plays out. For Challenger, this distance contributed to the sacrifice of innocents.

As developers, we must never hide risk for which others suffer the consequences. This is core to Scrum. The team tells the Product Owner anything that may affect the business outcome of a project.

Scrum’s focus on self-directed teams instills the courage informed consent asks of us. Frequent opportunities to inspect and adapt gives it voice.

However, an ethical view obligates us to more than delivering business value and we cannot entirely cede our conscience to our product owners. We have an obligation to each other, our collective reputation, the people who use or indirectly benefit from our systems, and the public good. For the most part, these interests have no informed consent on our projects.

As Agile practitioners and Scrum advocates, how can we expand our conversation and help each other exercise due care?

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

The certifying committe just accepted my CSP application.

I like where scrum certification is going. Hands on experience should be a requirement.

Posted: July 3rd, 2007 under scrum.
Comments: none

I’m a moderate in the agility vs. discipline debate.

Scrum/XP has worked for my team. Four years in, we deliver better adapted solutions with higher code quality.

What I love about Agile is that it acknowledges what’s hard and treasures what’s valuable. There is inherent complexity in modeling partially understood and fluid problems. There is deep potential in talented people rallying to achieve a goal.

However, Agile is not the only path to valuable software. As Stephen McConnell and Barry Boehm say, it’s all a matter of the appropriate tools for the appropriate context. Different levels of planning, description and formality have their place.

The only way to know whether a practice works for your team is to learn it (seek mentors), apply it with discipline, and track your performance over an extended period of time.

The infuriating thing is many shops don’t think deeply about what they do: “The Demise of the Waterfall Model Is Imminent” and Other Urban Myths

The value of any practice is really doing it.

Posted: July 1st, 2007 under scrum.
Comments: 4

Scrum is really simple, barely a process, more a framework. The hard work in using Scrum is fixing the things that it exposes, actually inspecting the things that it makes transparent and adapting to optimize the results and the organization that produces the results. — Ken Schwaber Scrum and NonScrum

My team embraces retrospectives. Every two weeks we list what we’ve done well and what we didn’t. We choose one or two things to do differently in the next Sprint. We revisit those commitments over time to see what progress we’ve made.

My team exists in a larger company.

In Waltzing With Bears, the one irrefutable reason to not do risk management is when no one else is doing it. If you are the only one presenting costs and possible negative outcomes management will assume your projects are troubled and you are a negative thinker. They’ll fund proposals that by comparison look cheap, safe and promise outstanding success.

I don’t exist in that extreme situation. But my team’s willingness to acknowledge mistakes is sometimes taken for negativity. Our willingness to admit the possibility of failure sometimes provides support to skeptics. Our willingness to question assumptions is sometimes seen as stone throwing.

Leading Change

In order to build something new we straddle two realms. In one we cultivate our aspirations and in the other we struggle to attain them.

At times we need to set aside our skepticism to see the world as it should be and people as we hope they are. Other times, we need to see how far we are from where we aspire to be, dig our feet into the soft earth and push.

Jeff Sutherland has a simple exercise for spurring organizational change

• Setting aside all the obstacles in your path, picture one thing you would like to change. Write down what it looks like.
• Now, go back to where you are. Look at that outcome. List things you can do in the short term that get you closer to it.
• Which of the items on that list are achievable and most effective. Put those at the top of the list.
• Identify what you can do in the next week to to achieve the items at the top of the list.
• Assign each of those items to someone in the room with you.

You’ve just planned a Scrum.

The Hair Shirt

There is a difference between justifying one’s mistakes and reflecting on past performance in order to improve. There is also a difference between acknowledging one’s fallibility and dwelling on it.

We developers are crafts people not monks. Our job is not righteous contemplation — it is thoughtful and rightful action.

So as reflective developers, we do not wear a hair shirt. Our goal is not to dwell on our own or other’s failings.

We are idealists.

We embrace grand visions, ambiguity, contradiction and change. We believe good people deliver the best results in environments of trust and honesty.

.. And we are pragmatists.

We believe believing doesn’t in itself make it so: success requires discipline, determination, and ingenious problem solving.

And as we embrace both the outcome to which we aspire and the given circumstances that surround us we will acknowledge mistakes. We will shine a bright light on obstacles in our path. With humility and tenacity we will challenge ourselves, our teams, and our companies to do better.

Posted: June 24th, 2007 under scrum.
Comments: 1

My co-worker Ilio Krumins-Beens and I are presenting an experience report at Agile 2007 in August. Special thanks to Jeff Patton, our champion and adviser through the submissions process!

Abstract

In 2006, Oxygen Media CEO Geraldine (Gerry) Laybourne, the woman largely responsible for Nickelodeon’s early success, partnered with her XP/Scrum development team to create a new mission and new revenue stream for her company. This experience report covers product conception through initial release of a single product. It describes how Gerry’s leadership qualities paired with agile practices to engender deep mutual trust and collective ownership over technical execution and business outcome. This unbounded collaboration provides a template for future projects at Oxygen and other organizations with innovation as part of their agile product development strategy.

Posted: May 18th, 2007 under scrum.
Comments: none

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.

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

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.

Posted: March 10th, 2007 under scrum.
Comments: none