Agile Development at ePredix by Shawn Lyndon

CIO says XP revolutionized more than the development process
Taken from Tech Republic, March 4, 2002
http://articles.techrepublic.com.com/5102-22-1045991.html

Shawn Lyndon is CIO of ePredix, an online human capital assessment company. He's also a proponent of XP. Shawn has more than 10 years' experience in the global IT industry, covering all aspects of enterprise systems development, management, and implementation. His primary area of expertise is in providing business continuance strategies for mission-critical applications. As CIO, Lyndon ensures that the current and future ePredix software and hardware infrastructure is highly available, scalable, and robust enough to deliver the ePredix solution. His previous role includes regional Sun/Oracle solutions architect, Sun Microsystems and Oracle Corporation Australia.

During a recent interview, he wanted to convince me that a stack of 4” x 6” index cards and freeing employees from traditional development roles has revolutionized not only the development process but also business values. This is what he had to say.

Takeaway:
Shawn Lyndon is CIO of ePredix, which produces online human capital assessment tools. In this article, he discusses why and how his organization began to use Extreme Programming (XP) and the ways that its impact has extended beyond the development team.

Builder.com: What model did you select for your development process?

Lyndon: Our development processes borrow heavily from XP and other Agile Development methodologies. In the spirit of XP, we have adapted these methodologies to address our individual business needs by adding our own modifications and adjustments. We continually challenge our processes in several ways. At any point, team members have the right to question why we do things a certain way. In fact, we expect such questions.

Also, if we have software-quality, performance, or general product issues, we ask ourselves what we can do better to prevent that problem from reoccurring. It is the constant questioning and refinement that has allowed us to develop our processes into a methodology that suits
the needs of both our customers and our team members.

More than just a theory

Builder.com: Do you emphasize certain aspects of the methodology?

Lyndon: I would say one of the overriding aspects of the methodology for us is the focus on the business need or problem and not the solution to that problem.

Builder.com: Sounds good in theory. Could you give an example from your organization?
Lyndon: Nearly two years ago—pre-XP and Agile Development—a member of our account management team came to me with a request for modifications to the primary Web report that our customers use to view scores of applicants using our solution. He wanted our developers to
paginate the report, with 20 records per page, and add navigation controls to allow users to jump to the desired page of the report.

Within four days, we implemented the changes, released them to production, and made them available for the client's use. It turns out, however, that our solution did not address the account manager’s concerns. Instead, he complained that loading a report still took the same time to load as before he submitted his request. I immediately realized that he was not interested in improving ease of navigation, a functionality issue, but rather he wanted to cut down the time it took to load the report, a performance issue. He thought by reducing the number of records displayed per page, he would get the performance improvement his client was looking for.

What he did not know was that we were preloading (caching) the entire report before displaying the first set of records. From a development standpoint, pagination was irrelevant to performance. Had the account manager stated what the problem was and why the client needed the improvement, we would have been able to provide a solution that addressed their needs the first time around. Instead, the account manager focused immediately on how he thought the problem should be solved.

In other words, the account manager told us how we should fix the problem, leaving the development team to merely implement the changes requested without any clear understanding of what the client actually needed and why. The better approach, and the approach we have since adopted, is for the account manager to express the what and why of the business need and leave it to the developers to come up with the technical solution—the how.

Builder.com: So if the account manager had a better understanding of how to ask the question, the problem could have been avoided?

Lyndon: Exactly. If the account manager had come to us and said, "Clients have a problem displaying over 200 records. They complain that it takes too long to view the applicants’ scores,” developers could have addressed the what—trouble displaying over 200 records—and the why—because it takes too long.

In our team, we believe that developers should be able to interpret business needs. By answering the what and why questions, our developers are focused on those needs. How many CEOs or CTOs can say that every developer on his or her team knows why they are building something and what it will deliver to the business?

Builder.com: How did XP methodologies enter the picture?

Lyndon: Fortunately, several members in the team began reading Kent Beck’s book Extreme Programming Explained. These team members adopted Beck’s mantra, "Embrace change," and pitched the idea to management. The decision to adopt XP was a natural one—it made sense for
both the development team and the company as a whole.

Builder.com: What was the first step you took in XP?

Lyndon: We started with “stories.” Each person, whether it be the CEO or a salesperson, makes a request of the development team, expressing it in terms of “what” and “why” on a simple 4” x 6” paper card. Each card represents a story. As a group, the team estimates how long it will take to deliver a solution to the story and records the estimate on the card. With this estimate and knowledge of the team’s capacity, the business (the “internal client”) has a clear picture of turnaround time for each story and can prioritize them according to ever-changing business needs.

As those needs change, the business has the opportunity to reprioritize the stories with full knowledge of available resources and consequences. For the first time, the business felt like it had some control over development timelines. From the development team’s perspective, the business was limited to requests that we could actually accommodate, and we felt as though we weren't saying “No” all the time. It was our first big breakthrough.

This concept of having the internal client create an index card ensured that we were addressing only immediate business needs in completing a story. We have effectively eliminated overengineering solutions to accommodate possible business needs.

We achieved two milestones in our early implementation of the XP methodology:
1. We gave back the power to the business to say what it wanted and what was important.
2. We delivered short releases that added real value to the business on an ongoing basis.
In the space of four weeks, we met more tangible business needs than we had in the previous six months.

Senior management buy-in

Builder.com: Was this the event that helped senior management see the light?

Lyndon: Yes. As soon as management could see these quantifiable results, they were all for it.
Agile development and the principles like those in XP are so much a part of our fabric as a company that it now extends through all parts of the business. We have many non-IT departments implementing Agile Development principles.

In fact, our COO, Nigel Dalton, has taken this into areas such as product development and account management. It is this belief and support from an executive level that allows us to continually improve our processes.

Builder.com: What do the business drivers and end users think of it? Are they deeply involved in the process?

Lyndon: The success of this type of development methodology relies on deep involvement of both external and internal clients at every stage of the process. The by-product of such involvement is constant feedback. Clients no longer feel like they are throwing the specification and pizza box over the wall to wait for the product. They are being listened to and can receive constant progress reports.

They see the product take shape before their eyes. It is an exciting and interactive process, and clients are genuinely enthusiastic about getting involved.

Inviting the bull into the china shop

Builder.com: Are internal and external clients deeply involved in the development process?

Lyndon: Absolutely. Internal clients, such as customer service, sales, and account managers, work side by side with the development team. We have taken this to the extreme by inviting one of our largest external clients to come into our offices and sit with the team as we go through the process of a release. This intimate involvement of external and internal clients is a fundamental driver behind our success.

Builder.com: In terms of skill set, what happens if, at a key moment during development, a person "less inclined" toward QA is responsible for testing?

Lyndon: Good question. In our team, we do not have any of the traditional roles such as business analyst, architect, QA engineer, or project manager that are generally associated with traditional development shops. We have a team in which everyone actively participates in every role. In some cases, a person remains in one role during an entire iteration. Other times, they rotate through all roles in one iteration.

For example, the most junior and senior developers will be involved in design, analysis, support, testing/QA, and resource management. Why have just one architect when you can have an entire team of architects at your disposal? How many times has a developer received a specification from an architect, only to find obvious omissions or weaknesses in the design?

We try to harness the full power of the team by allowing as much input for design as possible. We prevent one person from being labeled the "support person" or the "QA person" by making these roles a small component of each person’s responsibilities. By making each developer a QA person, we make everyone responsible for what they write. If they don't write a quality product, they will get to handle the resulting call for support and debug the problem later.

There are some cases where we have additional testing in place by the business to cover the issues around testing your own code. However, integrated unit testing and a focus toward functional testing make these processes less important.

Team building becomes a core value

Builder.com: Do natural leaders emerge in the open process?

Lyndon: This methodology requires a unique, flexible, and communicative personality. Everyone in the team is empowered to contribute to the highest level they feel comfortable. For example, during design process, anyone from a first-day employee to the CTO can take to the whiteboard and suggest architectures.

In this environment, people seem to gravitate toward being "thought leaders" in different areas of the system and development technologies, sometimes even surprising themselves!

Builder.com: Any warnings for organizations that are looking to adopt these methodologies?

Lyndon: XP and Agile have limitations, and they may not be for everyone. Before implementing these methodologies, understand why you are adopting them and know what you want them to do for you and your business. If you decide they are for you, be brave and be adaptable, and you will be rewarded.

At ePredix, we have had fun adopting XP and Agile methodologies. These processes have made the difference between success and failure in a very competitive and depressed market. We only hope spreading the word will allow others to enjoy similar success.