We’re looking for a developer to join our team at Simon & Schuster. We’re a small shop mainly working in Ruby on Rails. We practice Extreme Programming (XP) and Scrum. We value sustainable pace, work/life balance, and the sanity and happiness of our team members.

You can look at the full posting on Craig’s List or Simon & Schuster’s corporate jobs extranet.

Unfortunately, no recruiters.

Thanks.

During both searches, I asked myself the same questions.

1. Limit my search to [agile] shops?
   • Yes.
2. What do I mean by [agile]?
   • Scrum project management with the XP discipline.
   • Empowered, accountable product owners.
   • Collaboration and reflection.
   • User-centered product development.

Why such a narrow search?

• I want to accomplish something.
• I want to be inspired by my work and my co-workers.
• I want to be part of a real team
• I want to have fun.
• I want to balance my work and my personal life.

I don’t claim my criteria are the only way to achieve these ends but they are my path to them.

At only two months, let’s consider my last gig a walking shapiro.

Fortunately, my second hunt of the year went well thanks to peers in the NY Scrum and XP community.

This is a good time for experienced agilists and I’m grateful to provide for my family and aspire to fulfilling, collaborative work.

Even if things don’t always work out.

I start my new, new job in June.

Team Cohesion

Before and during our agile adoption, I informally administered the Gallup Q12 employee engagement survey. It is composed of twelve simple questions. Agreement correlates to retention, customer loyalty, safety records, productivity, and profitability.

From the beginning to the mid-point of our adoption, staff went from a response rate of 70% agreement 30% disagreement to 80% agreement, 15% neutral and 4% disagreement.

The most improvement was in daily opportunities “to do my best” and daily feedback on performance and expectations.

I’m convinced if I had administered the Q12 late in our adoption, we would have had even better results. The key un-addressed concerns were about having a best friend at work and feeling connected to the mission of the company. By 2007 our team grew to include people brought in by personal recommendation of other members of the team and our portfolio included consumer facing work directly for our CEO.

Rather than re-take the Q12, we undertook a 360° performance review. That we did this on our own initiative shows just how much trust we had built with each other.

Test Coverage/Code Quality

XP practices enforced methodical unit test coverage, mutually arrived at coding conventions, and real-time code inspection by multiple members of the team. The team went from no unit test practice to comprehensive coverage over the business logic and controller layers. (Unit tests against data access and gui were less comprehensive. I don’t intend to get in the middle of that debate here.)

A user story, test-driven approach to development has been shown to reduce defects in final testing by 40%.

XP and Scrum force conversations between the development team and product owner that incentivize all to build quality into the software rather than allowing technical debt to accumulate and relying on downstream QA process to fix the application.

In 2006-2007 there were no business impacting failures of our internally authored software. We were able to function as a project team with no dedicated developer maintenance staff. Change requests were minimal enough that we were able to prioritize them into our project sprints as overhead.

Reduced Risk

While any team has experts, “Agile” practices reduced our reliance on “specialists”. The entire team was capable of working on and maintaining any aspect of the code base. We passed the “bus test”; despite our small size, no project was at risk if any given member of the team became unavailable.

Leadership

Our team raised our skills and began contributing to our field. We write, present and teach at conferences on topics of scrum, XP and platform as well as contributing to open source projects and developer knowledge bases.

Recruiting and Retention

After establishing “Agile” practices we recruited skilled candidates from higher paying positions who desired to work in our culture and with our practices. We received inquiries from as far away as South America and Europe. Despite the reputation of our team and market demand we retained staff.

An additional benefit is that pairing provided an efficient on-boarding process for new hires. Developers joining the team provided immediate contribution. A metrics-based way to demonstrate this is to show that sprint commitments weren’t affected new hires first weeks. I observed that but mainly base this on comments from the team lead and existing members of the team.

Workplace Diversity

A 2006 paper by McDowell, Werner, Bullock and Fernald found that pair programming practice, “may help increase female representation in the field.”

Agile values and practices support a collaborative, empowering and sustainable work place. Such environments support diversity and take advantage of the breadth of experience each worker represents.

Client Satisfaction

We asked for quotes from our clients, vendors and even competitors which we included in our budget presentations (I’ve pretty aggressively scrubbed them):

“Working with the agile Software Development team has been rewarding on many levels…it’s a team that celebrates creativity, organization, listening, feedback, openness, honesty…and is proof positive that a great process results in great product. I look forward to our very regular meetings (I even readjust my travel schedule as much as possible to not miss anything) and am never disappointed. They are an engaging and engaged group of individuals.” – CEO

“[____ saved] half a head in [another team] and a full head in my team.” – VP

“The _______ written by our development team are the guiding-light to our decisions. [third party solution] has a vast wealth of information but no good reporting and our in-house [solution] enables us to divine meaning from the mountain of data.” – VP Traffic Operations

“We also use [third party solution] for all of our broadcast networks but I have heard about your software technology for ____. We currently do that through manual operators but I’d like to understand how you do that more sometime and how it works…” – Senior Executive, Competitor

“Given the complexities of ____ that includes the combined limitations of automation, graphic and traffic systems I believe [the team] has created a solution that has proven to be much more capable than most systems than I’ve worked with.” – Vendor

Frequent Delivery, Adaptability

Throughout 2006-2007 our team of 3-8 developers balanced two simultaneous lines of work on diverse projects built in Microsoft Windows Forms, ASP.NET to SQL Data Analysis Services Data Warehouses, Vista compatible Windows Presentation Foundation and XAML, open source .NET MVC frameworks and Ruby on Rails including a rich windows application built on beta Microsoft Technology.

The team completed eight IT and three consumer projects while doubling head count from 5 to 10 (+2 contractors). We initiated our consumer product initiative and achieved our first release of a rich windows application with a six month allocation of effectively 1.5 – 2.5 developers.

Invention/Innovation

Agile practices evolved from Lean management and associated knowledge creation theory. In this, it shares ancestry with Six Sigma.

Agile is based on empirical not plan-driven process control. It is closer to lean product development than lean industrial manufacturing.

Lean product development models sustained innovation as a process of knowledge creation and conversion within an organization that acquires and shares learning in an cycles within and across teams and up and down from leadership.

Agile fosters true joint work which is the only form of workplace collegiality that advances organizational change and innovation.

Our consumer product was recognized for its design and implementation by Microsoft’s platform and developer evangelist team as well as by the WPF team. It achieved high ratings in usability testing with end users (avg rating 8 of 10) and showed potential to deliver on its revenue targets.

…and that’s a good thing.

The tyranny of metrics.

Metrics have unintended consequences. Particularly when they justify incentives or affect people’s workplace. In the short term, performance improves regardless of what you measure. Over time, behavior distorts in ways you don’t want.

What to measure?

Lines of code? What a terrible measure of productivity! Is “thethethethethe” 5x’s more valuable than “the”? I know it takes longer to copy edit.

Function points? Who has access to a qualified function point counter? Is 6 fp’s more productive than 10 fp’s? What if I only need 4 fp’s to get my job done?

Velocity? Too many agilists fall into the trap of thinking of velocity as something objective.

Example: A team of three performs 40 story points in one sprint. A team of ten does 50. Which team is more productive?

If the teams estimate in isolation, work on different types of projects or if the sprints were months apart the appropriate answer is, “who knows.”

People will adjust their sense of how long things take over time and in response to change. That’s good. 1pt <> 1pt. 1hr <> 1hr.

Velocity is a feedback mechanism for the team – a way of informing their own intrinsic motivators and refining gut estimation. Burndown is an early warning mechanism for iterations or releases. Leave it at that.

What’s my baseline?

Rigorous tracking is a hard-won part of agile adoption itself. I have no “before” to compare to an “after”.

Small businesses are volatile. Our team grew and our work changed dramatically during the course of our agile adoption.

We have better things to do.

Measurement is an overhead. Tracking a backlog and velocity are enough.

There are better reasons to adopt agile.

We sought improved customer satisfaction, reduced risk, improved quality, incremental delivery, and innovation. We obtained other benefits including: great recruiting and retention, rapid professional development, high employee engagement. [I'll go over these benefits in a future post.]

Be the change

I saw an XP experience report by a big BPM vendor. Even they didn’t have quantitative metrics to support their adoption. Why? Because the reasons above apply to big companies as well.

If nothing else, agile practice should shorten our patience for doing things we know don’t add value. Re-frame the conversation.

Before this, we were hit and miss. Success relied on individuals. We had few shared practices. Our goal in going “Agile” was to consistently perform across projects.

“Agile” declares a set of common values and supportive practices. It fosters collaboration with customers and shared ownership within project teams.

In time, the team became proficient in core XP practices:

Planning

• User stories
• Iterative development
• Tracked velocity
• Daily stand-up meetings
• Regular retrospectives with continuous improvement

Designing

• Simple system metaphor
• Use of development spikes
• Refactoring

Coding

• Onsite customer
• Pair programming with switching
• Test driven development (TDD)
• Continuous integration
• Collective ownership
• Sustainable pace

Testing

• Extensive unit test coverage
• Bugs are resolved within the iteration
• Acceptance testing by the on-site customer

Within a year the team’s performance was more consistent and visible. We were measuring our velocity and predictably delivering on our 30 day iteration goals.

We discovered our project management practices had become a bottleneck. We were clearly hitting idle periods within and around projects because of a failure to efficiently describe and prioritize work.

We introduced Scrum as a management framework on top of XP. It provided practices for organizing and prioritizing work. It helped us define roles and responsibilities.

We clarified our expectations of internal clients and achieved more efficient interactions overall. We created mechanism for reporting progress and costs to senior management.

In Q1 06, the team’s practices were evaluated by an Agile Coach, Jason Lewis. Among his findings:

Oxygen Media’s Agile software development process overall rates above average and is better then the benchmark team. The benchmark did have considerably more Agile experience, but less time together as a team.

In the evaluation of practices, the team was overall: 1) well above average to outstanding in the adaptive learning practices, 2) Above average in Sprint practices and 3) Average in planning practices. High points for the team’s individual practices were the retrospective and use of the wall for iteration tracking. The one low point was the maturity of acceptance testing.

When comparing roles to the benchmark team, the benchmark team had a much better customer role but the team was stronger in the developer and facilitator roles. When comparing the team’s adoption of the practice’s versus the benchmark the team was generally more effective. Iteration tracking was one key area the benchmark team was better, however, the team was much stronger in the all the adaptive learning practices.

After the audit, we pre-staged our iteration planning, reduced our iterations to 2 weeks and formally planned releases.

We added discipline to our acceptance testing. We described acceptance tests in a narrative script authored by and exercised by our product owner (proxies).

We never automated acceptance tests for rich windows applications or systems tied to large, volatile back end data stores. But by Q3 2007, the team was using automated acceptance tests on it’s web applications.

The most drastic improvement however was in the customer role. Scrum defines the responsibilities of the product owner. In our case, that role was divided into two individuals.

The product owner, is an empowered single authority for prioritizing business value at the feature level. They are usually are executive level and work in the business unit “funding” the work. They also have working knowledge of the system to be built. Product owners participate in planning and review, and are available for ad hoc questions within iterations.

The product owner proxy is a member of the development staff who acts as onsite proxy for the product owner. This person assists in authoring user stories and maintaining a product backlog, meets regularly with the product owner, and acts in their place to broker decisions within the development team during iterations.

By Q2 2007, the team had product owner proxies for both our IT and our consumer facing work. Product owners included the VP of Broadcast Operations, VP of Ad Sales Traffic, our CTO, and our CEO.

Throughout 2006-2007 our team performed exceptionally well, balancing two simultaneous lines of work and maintenance in both .NET and Ruby on Rails with four to six developers. Our projects delivered on client satisfaction, originality and early monetary goals.

Team members raised their skills and began contributing to our field. They were writing, presenting and speaking at conferences on topics of scrum, XP and platform as well as contributing to open source projects and developer knowledge bases. We were drawing positive attention from our peer community and within our company.

Our consumer product, Ript™, was recognized for its elegance in design and implementation by members of Microsoft’s platform and developer evangelist team as well as by members of the WPF team. It also achieved high ratings in usability testing with end users (avg rating 8 of 10) and showed potential to deliver on its revenue targets.

Ript Promo – Click to play.

At the end of 2007 our company was acquired by a much larger television company. Software we wrote for internal use is considered valuable enough by the acquirer that they are hoping to transition into their much larger operations.

The way to win over an entrepreneur is to out-perform expectations set from painful, past experience.

Before Scrum/XP

…six months later, they deliver what the assignment was. And you look at it and say, “Oh no, that’s not what I wanted.”

With Scrum/XP

…you work on a two-week cycle… You agree on what the priorities are in the meeting. You review the priorities. You evaluate where you are, and you move to the next step…

He also said that to his estimation about 10% of shops that claim to be practicing Scrum pass the Nokia test and have self-organized teams, product backlogs prioritized by a product owner and estimated by developers.

And that doesn’t even speak to refactoring, test driven development, pairing, continuous integration, built in quality, acceptance testing, etc.

And that doesn’t speak to knowledge creation and sharing practices across the entire organization, clarity of vision, understanding competitors, collaborating with customers, continuous improvement, and embrace of change.

I’ve come to understand that agile values place demands on development, management and business practices.

Two questions arise from this:

• Would you only work in an [agile] shop?
• What do you mean by [agile]?

for [agile] feel free to substitute: Lean, XP, Scrum, XP/Scrum, Crystal, Adaptive, etc. etc.

Great Scrums Need Great Product Owners: Unbounded Collaboration and Collective Product Ownership

Abstract

Scrum describes a separation of roles; the product owner is accountable for achieving business objectives and the team for technical execution. A pragmatic and collegial relationship between a product owner and team can satisfy the definition of collaboration and honor roles while barely tapping or actually working against the potential of a project and its participants. This paper surveys literature to describe different forms of collaboration, to establish that deep, unbounded collaboration is at the heart of agile values, and that partnerships of high trust and shared risk lead to value and innovation. Finally, this paper incorporates a real- world example of a product owner who, while remaining accountable to the outcome, shared ownership over vision, priorities and execution with her Scrum/XP development team.

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