A product owner describes work. The team estimates it. The product owner sets a delivery target. The team commits to it.

Estimates

People are good at estimating their own ideal effort on well-defined work within their realm of experience.

People are poor at translating ideal effort into calendar days, estimating how long others will take to perform work, and estimating work that is either poorly understood.

Estimation is time consuming with diminishing returns so the effort should be managed to cost, i.e. time-boxed. That is why Agile practices invest more energy and place more value in estimating immediate work than on more speculative work farther out.

All estimates contain uncertainty. Industry research says an upfront estimate can be 25% to 400% of actual performance. The range of uncertainty is deeply dependent on context: how much work is involved, development lifecycle, experience with the particular work, shared experience within the development team and maturity of the management organization.

It is poor practice to “pad an estimate”. Padding doesn’t match the scatter that surrounds upfront estimation. For large scopes of work a developer should express an estimate as a range of uncertainty (i.e. “four to eight months skewing to between six and eight”).

Middle managers should not pad or trim a developer estimate. That is undermining the developer’s authority and making them un-accountable. The estimate is the estimate.

That doesn’t mean that the business doesn’t make planning decisions based on estimates. It means those decisions are separate from, though informed by, the estimate.

Targets

When a product owner or sponsor takes a developer estimate of 4-8 months and sets a release date six months out, they are moving beyond the estimate to set a business target. This is a judgment of what expense and time to market promise sufficient value to justify the work.

The product owner is using the developer’s estimate to inform themselves of the risk they are taking with their investment. An aggressive target within an estimate with high uncertainty is a larger risk than a conservative target on a more certain estimate.

Commitment

Setting an achievable target and owning that decision, communicating the rationale for your decision and having that rationale inform your priorities earns trust and rallies a team to deliver.

It’s the targets, stupid

Don’t set arbitrary targets. Don’t burden yourself with unnecessary risk, demotivate your developers and thoughtlessly constrain the value built into your software.

Do set meaningful targets. Take calculated risks, manage costs, partner with your developers and know what and when you need to deliver to your customers.

It’s not an estimate. The developer cannot assume your risk.

It’s not a commitment. You’ve got to earn that.

At the end of the day, the product owner is responsible for understanding the business climate, understanding the customer, describing and prioritizing the work, and managing the company’s investment to a successful outcome.

Posted: July 10th, 2008 under development, scrum.
Comments: none

Not to get super preachy on you all, but sometimes I think we’re full bore on the wrong mission.” — ‘Agile Shop’ by Dave Laribee

As people, we embrace change we can ourselves effect. Our conversations about value turn to story writing. Our conversations about competitiveness turn to scale.

But we risk engaging the surface of things and not the things themselves. Means to what end?

As brother bee preaches, I stand before you penitent of the sin of local optimization.

In my last job, I led a development team. We were an agile team in a non-agile company. We were engaged in the effort of years, championing organizational change bottom up.

In spite of everything we’d built — an excellent agile team, a direct relationship with our CEO, visible release backlogs and delivery — the business remained opaque. It was unable to rally to us and unwilling to provide the transparency and focus we needed to effectively rally to it.

As a result, our timeline didn’t match the life-cycle of the business. When it was acquired, our efforts were shelved and we all moved on.

An agile team in a non-agile organization is not agile enough.

Posted: July 6th, 2008 under development, scrum.
Comments: 1

Fail fast is a technique for improving the quality of software:

“failing immediately and visibly” sounds like it would make your software more fragile, but it actually makes it more robust. Bugs are easier to find and fix, so fewer go into production. – Jim Shore

Scrum aspires to a fail fast approach to building software.

It describes practices that surface problems:

• a backlog prioritized by the product owner and estimated by the team (accountability)
• short iterations
• frequent retrospection
• a role dedicated to removing impediments

It champions values that motivate individuals to address problems:

• delivering business value
• collaborating with customers
• empowering teams
• building quality in
• continuous improvement
• courage and honesty (a refusal to hide risk)

Possessing these values and practices, an organization is less likely to overlook or tolerate dysfunction when it materially affects the setting and achieving of project goals.

1. risks are identified before they become problems
2. simple problems are detected and resolved quickly
3. thorny problems are mitigated
4. catastrophic problems are aired to all concerned parties (informed consent)

Cases #1-3 increase a project’s chance of creating value.

Case #4 compels an organization to cancel a doomed project.

All four cases represent a better outcome for the business. Assuming that business offers value to the world, that’s better for our end users, our reputation, and our society.

Immediate and visible failure. Much preferable to hidden, prolonged and inevitable failure.

Posted: May 15th, 2008 under scrum.
Comments: none

Just posted a reply on the Scrum Developers Yahoo Group. Keeping up with that list would be more effort than becoming a certified scrum master.

What I am interested in is to find out how graphical and interaction designers can be eased into Scrum development.

In my previous team, our UX director, Bob Calvano, mixed in with the team: proposing UI elements in mockups but also pairing with developers to collaborate on implementations. The team and UX director shared decisions but the UX director retained authority over them.

The team and product owner learned to defer to him on thorny questions of emotion, aesthetic and interaction particularly where the product owner had no clear sense of how the decision impacted tangible customer value.

The team had to learn how to deliver constructive feedback on UX. They had to learn how to express personal opinion in that context.

The UX director needed incredible patience taking in well and poorly delivered feedback. He had to understand his own process well enough to use day to day input to enable his own creativity rather than shut it down.

We evolved this relationship in a small team in an environment of high trust and we took months getting there. He came from a more traditional agency approach but he did have a personality suited to collaboration.

He eventually left our team to become an Interaction Design Director at one of the top agencies. He did so because the high profile of the work and pay were irresistible, so this experience didn’t hurt his career progression or his ability to work other ways. Though I know for a fact he misses that team and is returning to a smaller environment where he can recapture that collaborative experience.

thoughts from people who have read Jeff Patton’s book and what they think about how his ideas fit with Scrum.

Haven’t read the book yet. Talked to Jeff about his ideas at Agile 2007 (He was my adviser on my presentation on product ownership) and at the Fall Scrum Gathering.

High praise for his thinking on user experience as a precursor in product development (why) not simply as part of execution (what).

We tend to focus on story writing as the first tangible step agile plays in product conception. There are whole worlds of collaboration in terms of understanding who the software is for and how it solves problems for human beings that should come first.

Jeff Sutherland says the vast majority of teams run Scrums without real backlogs. How many of those few product owners that have backlogs derive systems and features from a user-centered perspective?

Hoping Jeff Patton will give us practices to tackle that problem.

Posted: April 26th, 2008 under development, scrum.
Comments: none

To help some peers advocate for agile adoption, I prepared an experience report to demonstrate how my old team benefited from XP and Scrum practices. This is an extension and refinement of an earlier post on the benefits of XP.

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.

Posted: February 11th, 2008 under scrum.
Comments: none

Jeff Sutherland published a paper at HICSS-41 that documents cost savings a CMMI level 5 organization delivers switching to Scrum.

As I just wrote, I would not invest in productivity measurement to justify agile adoption.

But a CMMI-5 company invests in more measurement than I would ever do so let’s take advantage of what they learned. While taking it with a grain of salt.

The company believes work costs about half as much if they use Scrum instead of their best of breed CMMI level 5 waterfall practice. For those of you who hate process, lack of a disciplined process (CMMI level 1) costs even more.

Jeff says this company does a diverse mix of work both in terms of size and platforms and that the results hold. I would want to know more about the company’s engineering practices both before and after but since Jeff is involved I’ll assume this is one of the small percentage of teams who claim to be doing Scrum that are really doing it.

Posted: February 10th, 2008 under scrum.
Comments: none

Did I measure “hard numbers” to demonstrate increased productivity with Scrum/XP? No.

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

Posted: February 10th, 2008 under scrum.
Comments: 3

My development team began adopting Extreme Programming (XP) in January 2004.

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.

Posted: February 4th, 2008 under scrum.
Comments: 1

Ilio and my paper is available on the IEEE library site as part of the proceedings of the 41st Hawaii International Conference on System Sciences (HICSS).

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.

Posted: January 16th, 2008 under scrum.
Comments: none

I just presented Ilio Krumins-Beens’ [and my paper] on unbounded collaboration between the product owner and development team at the 41st Hawaii International Conference on System Sciences. (I’ll link off to the paper when the transaction is published on the IEEE site.)

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.

Posted: January 10th, 2008 under scrum.
Comments: none