Certified Scrum Practitioner
The certifying committe just accepted my CSP application.
I like where scrum certification is going. Hands on experience should be a requirement.
Short link: http://jkat.me/lxBxXi
The Limits of Informed Consent
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?
Short link: http://jkat.me/lZ73hD
Related posts:
Two Product Backlogs – One Sprint
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.
Short link: http://jkat.me/iVTEyd
Off to Agile 2007
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.
Short link: http://jkat.me/dHSJMR
The Road Not Taken
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.
Short link: http://jkat.me/gEV9LA
