Knowing Where You Stand

“What is it about the Apple Store that’s just so great?” is the question that opens the UDig blog post “How to Staff Your Organization Like an Apple Store”, by Kyle Lagunas. In the article, he observes:

Apple is running a seriously smooth operation in their retail stores. Each employee has a distinct role to play, understands that role, and does his/her part to deliver the level of service we’ve come to expect from this powerful brand. All of this requires serious alignment of brand, business goals and people process.

Although Kyle is discussing staffing, the characteristics of Apple’s operation that he highlights are extremely relevant to the development process. Understanding your role within a process where the objectives of all roles are aligned to produce customer satisfaction is critical to success. Consider the following:

Once upon a time, there was a development organization that had unhappy customers. Those users would spend countless hours defining solutions to their needs. The tomes describing these solutions were then duly turned over to the organization. Product managers, responsible for serving as the liaison between the business and the technical staff for a given part of the application, would then review the voluminous output of the business users. After filing their documents in the trash can, the Product managers would produce their own detailed solution to what they perceived the customers’ problems to be. These documents would then be deposited on the desk of a developer working on the application module controlled by that Product manager. The developers, finding the requirements document to be technically deficient, would then implement their own interpretation of what the users wanted. The code would then be deposited in the laps of testers. Those testers, unconstrained by the visions of the users, product managers, or developers, would then proceed to enter bug tickets based on how they thought the application should work. At this point, an iterative cycle would occur: developers would “fix” bugs according to the testers’ tickets, subject to the developers’ adjustments; tickets that made it past testing would then be sent back by the project manager to be reworked according to the product manager’s vision; the reworked tickets would then be rejected by the testers, returning the cycle to the beginning. At some point, enough of the players would give up and the release (perhaps “escape” would be a better term for it) would make its way into the hands of the end users. The customers, having received a buggy product, late and with little resemblance to what they had asked for, were dissatisfied.

Amazingly enough, the story had a happy ending. A structured, iterative process was adopted. The end users worked with analysts (the re-titled product managers) to turn business needs into coherent requirements, analysts worked with architects to understand the architectural implications of changes and enhancements, architects worked with developers to design the technical expression of the requirements, and testers ensured conformance to the requirements. Issues were bubbled up to the appropriate level: analyst and users dealt with the functional and quality questions; developers and architects handled the purely technical ones. Communication and collaboration were promoted. Usurping another’s role was prohibited.

Although they did not feature in the story above, the DBA and infrastructure roles were included as well. Pairing responsibility with skill is as important in these areas as in those noted above. A key role that was introduced, invisible to end users, but vital nonetheless, was that of the release management specialist. I’ve previously detailed the importance of release management in the post “Do you have releases or escapes?”.

What did not change is as important as what did. The same people involved in the old dysfunctional process defined and refined the new process. What changed was their understanding of their roles and how those roles were to come together to produce quality software. Having each role, from user to tester, acting as partners in the process made it work. Each role had both authority and responsibility over its own area while deferring to the other roles in their areas. Far from being constrained, each role was empowered by this as it allowed them to concentrate on their own area of expertise, all in the pursuit of consistently producing software that met the needs of its users.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s