Tag Archives: xp

Scrum Gathering – Agile and Ethics

Posted on by

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.

Women & Agile Development (revisit)

Posted on by

ACM Technews referenced this article from searchcio.com.au.

IT still trying to find what women want

The world is flat. Better go out and hire some women.

That seems to be the gist of a recent Gartner report on the gender gap in information technology …

The article lists five gender-based traits CIOs should pay attention to when building IT staffs.

There’s a danger of drawing conclusions about individuals from differences in large samples. Just because men are statistically greater risk takers than women doesn’t mean I’m bolder than any particular woman. Or that she has better listening skills.

But at the level of an entire industry statistical differences are meaningful. Software would be better if we had collaborated and communicated better. Our products would be better if we had more empathy for customers and end users. Attracting qualified women into the field is a contribution to that end.

As the article suggests, the only appropriate way to do that in the context of a specific hiring decision is to include people skills as a requirement of the position, cast a wide net and hire the best candidate.

But you need to have a workplace and compensation package that is attractive to someone with people skills, technical chops and wants to give you their best at a sustainable pace.

To the argument that inviting women into a dysfunctional IT culture won’t make things better, I’d say that’s not my point. More women in IT is a hoped for result of humane workplaces — not a solution for creating them.

We have to work from within to make our companies better. In my software development team, our use of Scrum and XP has helped us do that. So far, my employer has been receptive.

I know that isn’t true everywhere. All I can say is those of us who have a choice sometimes have to make tough decisions about where we choose to collect our paycheck.

The Road Not Taken

Posted on by

Mountain Path Ript - Photo by Kathie Horejsi

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.

Mountain Path Ript - Photo by Kathie Horejsi

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.

Off to Agile 2007

Posted on by

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.

Two Product Backlogs – One Sprint

Posted on by

Forked Road 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.