Tag Archives: Extreme Programming

Hyperproductive? I don’t know but I’ll take it.

Posted on by

I’ve written about how our agile practice, particularly continuous improvement, has re-organized our product and development group into one, high performing team. How this has resulted in less code, less waste, higher quality and more value.

Jeff Sutherland talks about mature, agile teams achieving what he calls hyperproductivity. At this point, the team output accelerates and they outpace the organization around them.

annotated-burnup

Performing beyond even our own expectations allows us slack to help our product team and our sponsors define the work we do. As a matter of fact, last week, the dev team accounted for 9 of 15 stories in our backlog including 5 consumer facing additions or changes. Our sponsors have so much trust in both our ability to deliver work and our judgement that we have top down support behind the kinds of necessary efforts companies find hard to justify like platform and framework upgrades.

It is a virtuous circle, performance allows slack, slack allows time for reaching outside the immediate task to understand and optimize work for the next week, to keep up with our training and industry, to get out of the room and talk to the business, to imagine new features, to identify and solve problems.

Team members are allowed an opportunity to express their individual talents and interests: one developer can bring in a prototype of an entirely new implementation of our website, another can research and improve our search engine rank. All while working as a single collocated team that pair programs with daily pair rotation through a weekly iteration cycle and a shared backlog.

It is a synthesis of contradictions: deliver features and create less code, remove interruptions and make time out of the team room, strive for collective ownership and individual autonomy.

It results after years of dedicated practice in the techniques of Extreme Programming: pair programming, test driving, collective ownership, refactoring, iterative delivery — and determined Scrum project management: impediment removing, iterative delivery, retrospection, adapting our organization, earning trust, and protecting the team so that they could get their work done. A team is an organism that needs to close inwards, build strength and discipline before it can open up and expand outwards.

It’s the second time I’ve been a part of a team that’s reached this level of performance and both times it’s taken years to get there. I’ll take it.

Antidote the diving catch culture of heroics and privileged roles

Posted on by

These are notes from my presentation at the Hawaii International Conference on System Sciences (HICSS) #45.

I’ll link to my full paper when it is available and to subsequent posts as I publish them.

Agile values, product innovation and the shortage of women software developers Part 6 of 7

(37) Antidote the diving catch culture of heroics and privileged roles

“Many SET cultures place a high value on risky behaviors: They celebrate heroic diving catches made at the eleventh hour to rescue a failing project”

(38) Problem statement

“Why don’t we just build the system right in the first place? Women are much better at preventive medicine. A Superman mentality is not necessarily productive; it’s just an easy fit for the men in the sector. Because it is generally men who are making the promotion decisions, they recognize this behavior and reward it.”

(39) Collective ownership

Supporting that sentiment are the following Agile principles: “Continuous attention to technical excellence and good design enhances agility.” “Simplicity–the art of maximizing the amount of work not done–is essential.” What I’m getting at here is an emergent property like self-organization called collective ownership It’s an outcome of teams that embrace Agile values of self-organization, quality and simplicity.

(40) What collective ownership feels like

“Collective Ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs or refactor. No one person becomes a bottle neck for changes[50].”

(41) Practices that support collective ownership

Collective ownership is the engineering expression of self-organization. To achieve collective ownership, a self-organized team should explore disciplined, collaborative engineering practices: pair programming, evolving architectures with refactoring, frequent integration, unit testing and test-driven development[53].

(42) Why is collective ownership an antidote to heroics?

A diving catch implies a single set of eyes on code. It implies haste and a need for emergency intervention, i.e. poor quality. Emergency code is not unit tested, it is not elegant. It also implies a team that is not pulling together to deliver the goals of their iteration.

(43) Why is collective ownership an antidote to special job assignments

Collective ownership discourages the use of specialists which represent bottlenecks and opaque stores of tacit knowledge. The Scrum guide includes as the basic definition of team, “There are no titles on Teams, and there are no exceptions to this rule. Teams do not contain sub-Teams dedicated to particular domains like testing or business analysis, either[52].”

Next: How values create change from small networks to large…

Previous: Antidote to hostile workplaces and the alpha geek

All slides published to date.

There is abundant research on the problems women face in our field. I would love researchers to jump in on whether Agile principles and Agile practioners can really make a difference.

I’d also love any suggestions of organizations, institutions and individuals I might reach out to for more information, collaboration, or to take up the cause.

Please comment on my proposal to Agile 2012.

The full citation list for my paper.