Skip to main content

Tag: Agile

An Eye for Value: What the Business Analyst Brings to the Agile Team

Written by Cynthia Low on . Posted in Articles.

There’s no question about it: agile project management expedites the new product development process. It is a streamlined methodology, based on having only essential people work in tight knit teams for quick and efficient results. Of course, one very important member of the team is the business analyst. Why? Because if companies hope to achieve strategic goals, they need someone who is focused on the business value expected from the project outcomes to help provide guidance, not only during a project, but also before it is invested and after it is delivered.

In traditional project management, which comes from the construction industry, a great deal of up front planning and requirement generation is done. People can then walk away with finished plans in hand to construct a building. Though it is a logical approach for construction, project management has been adapted over time into an agile system for business projects that contain a significant technology component. For such tasks, it is difficult to articulate requirements for a future way of working that has not yet been tested. Agile projects proceed on more of a ‘learn as you go’ premise where small working teams include customers and developers who are co-located and spending 100 percent of their time dedicated to the project. The work is done in increments, and quick iterations are continually evaluated and modified. A project manager and a business analyst each play a crucial role on such a high performance team.

A project manager is essential for overseeing a product development project and making sure it comes in on time, on cost and with full scope. The business analyst is key in managing the evolving business requirements and the business benefits. According to the International Institute of Business Analysis (IIBA), the official definition of a business analyst is a person who works as, “a liaison among stakeholders, in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.” With the advent of agile product development and the constant requirements evaluation and modification within a project’s lifecycle, the business analyst is more valuable now than ever before. 

The business analyst involvement in agile projects, unlike that of the project manager, is not limited to the period of time when the projects are active. Business analysts provide continuity for companies, from cradle to grave, by working with portfolio management teams to make sure the most valuable projects are being invested in, providing oversight during projects, and finally measuring actual benefits after projects are completed.

Chart a Course with Portfolio Management

Portfolio management is a relatively new practice, which is coming into its own as organizations better understand the importance of how choosing the right projects to invest in helps them to achieve their goals. When involved in the early planning stages, business analysts serve a company by providing enterprise analysis. By evaluating the competition and conducting benchmark and feasibility studies, business analysts identify business opportunities and create a list of potential projects to support.

Next, the business analyst puts together a business case in which they analyze the best approach to a particular project and show quantifiable benefits. After all potential solutions are studied and analyzed individually they create concise project investment decision packages for the optimum solutions to present to portfolio management steering groups or governance committees.

Created with the right expertise and tools, these project investment design packages provide the information for proposed projects in a consistent way. Such a presentation allows the executive level decision makers to compare apples to apples, the expected value, cost and risk of one proposed project versus that of others. The decision-making boards can then wisely select and prioritize major project investments.

Stay the Course During Product Development

Once a project is approved and funded, a project manager is assigned to technically manage it. Ideally, a business analyst will continue to oversee and elaborate the business requirements and benefits they originally helped to define. The two professionals have different but complementary roles in the product development process. Through team leadership and collaboration, they successfully guide an agile project that is both efficiently and effectively run, and that has significant long-term benefits for the company.

A business analyst’s main priority, when first attached to a specific project, is to elicit business requirements and categorize them into valuable features or functions. Then each feature is described in enough detail to determine its cost versus its benefits. By knowing what it will take to deliver each individual component of the project, as well as what the return will be to the organization, the development team can then build components or features based on value, and deliver the highest value features first.

As an agile project progresses through its lifecycle of requirements, design, construction, testing and deployment, the team continually learns new information. It becomes clearer how many resources will be needed to perform detailed design, construction and tests, how much risk there is to the project and how the risk needs to be managed. Accordingly, it is important to go back and check original assumptions concerning costs to develop and operate the new solution and business value to see if they are still true.

Working with the project manager and the core team of developers and customers, the business analyst updates the business case at key milestones throughout the project and adds more detail to the project plan. For example, the business analyst may discover that a project is going to take 12 months instead of six, and will cost 10 million dollars instead of eight. The portfolio management team needs to be informed, so that they can decide if the project is still a good investment and if it should continue. The business analyst will make valuable recommendations, such as continuation with some sort of course correction, like a scaling down of the requirements.

Because agile projects often involve upgrading information systems, it can be easy for the technical developers to focus on what technology can do, rather than on how technology can best serve the specific goals of the company. Throughout the constant adjustments in the development process, the business analyst always keeps the focus on the business requirements, the costs and risks involved and what value the project will ultimately return to the organization.

The role of liaison between developers (engineers who may not understand the intricacies of the business process) and customers (business people who may not know what exactly to request technologically) is an important one. Alice Zavala, Senior Consultant for Management Concepts in Euless, Texas, gives the following example: An agile team was working to create a new company website, and the customer asked for a drop down menu with both credit card and check payment options. The developer has the know-how to create what is asked for, which is basic information on an aesthetically pleasing background, but there are business rules that need to be applied to the process that were being overlooked. In this case, the business analyst bridged the gap between what the customer requested and what the developer needed to provide, by proposing a back screen to perform an approval process before the credit card or check goes through. According to Zavala, such a situation requires oversight because, “in order for information to be put on the screen, we needed to know what other business processes are going to be touched.”

By being involved during the development process, business analysts validate that new components are actually meeting business needs. They also take information to other groups outside of the agile team, to further corroborate that the changes have the support of other stakeholders, who will also benefit from revised requirements or at least not have conflicting requirements that need to be addressed.

The Finish Line and Beyond

In conjunction with the cost of the development of a new business solution, the operational component needs to be analyzed and assessed before the project is implemented. With a major new business system, perhaps there will be a need for some reorganization, retooling, retraining, or acquisition of new staff. Working with management, the business analyst helps to insure the organization is prepared for the impact of the changes. That way, when the final system is ready, it can be operated optimally.  

Once the new system is in place, the actual costs of development / acquisition and operation should be compared to its actual benefits to the company. If a business analyst has been involved from the beginning of the process, he or she will have created a business case containing projected quantifiable benefits, which can be measured against the end results. This final analysis shows the organization whether they have received their predicted return on investment. If the performance metrics show that the project was a success, great. If not, the business analyst can investigate to find out where the project went wrong. Was it a bad investment because it was too high risk? Was the project executed poorly, so that the project cost a lot more than expected? Was the organization not prepared for the new system, so that operating costs are much higher than predicted? This type of post-project evaluation is crucial to improving future projects because it allows a company to learn from its mistakes.

Team Players

With all of the opportunities enabled by new technology, businesses are establishing strategic goals to keep up with the times and stay ahead of the competition. To both set and achieve their goals, they rely increasingly on the skills of business analysts, who can not only assist in making projects successful, but help select and prioritize those projects with the most business value, and analyze the effectiveness and worth of a deployed system.

The project manager and the business analyst are both integral in creating a high performance agile team. While the project manager’s role is more technical (keeping the project running smoothly) the business analyst’s role is more strategic (provided the team with a road map). Without a business analyst on board, with an eye on strategic company goals, an agile team can be like a high performance car without a navigator – making good time, but not sure where it is headed.

This article first appeared in PM World Today eJournal. www.pmworldtoday.net 

Kathleen Hass, PMP , is the Project Management and Business Analysis Practice Leader for Management Concepts, Inc. and has more than 25 years of experience in project management, including project office creation and management, business process re-engineering, organizational development, software development, technology deployment, project management training, mentoring and team building. For more than a quarter of a century, Management Concepts, Inc. has provided quality training and performance improvement solutions for the mind at work. For further information, please call 703.790.9595 or visit the company website at http://www.managementconcepts.com/.

If Agile Were to Go Mainstream

Written by Cynthia Low on . Posted in Articles.

If agile methods are to go mainstream, it might be when their popularity and legitimacy reach a tipping point. An example that this could be happening is a recent NY Times article called “Google Gets Ready to Rumble With Microsoft” (16 December 2007), which my colleague Ken Orr wrote about in the newsletter Cutter Trends Advisor entitled, “Velocity Matters: Google, Microsoft, and Hyper-Agility, Part 1” (20 December 2007).

The articles are about Google going after Microsoft’s customer base, using something called its “Cloud” computing framework. But Ken Orr’s interpretation of the Google-Microsoft confrontation emphasizes the time-to-market advantages that Google’s software development lifecycle has over Microsoft’s. Google is apparently practicing a more agile, iterative-style approach (sometimes quarterly) to releasing software, while Microsoft is more tied to the big bang, multi-year cycle for its products.

Might the public start perceiving companies like Google as “agile and adaptive,” while tagging Microsoft as “heavy and slow?” Agile methods may have found their version of Malcolm Gladwell’s “sticky message.” Most agree that it began in earnest with the infamous Agile Manifesto — elegant in its simplicity. It emphasized the value of “individuals and interactions” in creating “working software via customer collaboration while being responsive to change.”

Simple and Elegant.

But some people felt the word “manifesto” carried an interesting connotation because of its perceived arrogance. One manifesto, by a crazed lunatic called the Unabomber, made headlines years ago by decrying the evils of an industrialized society and railing against the establishment. The agilists (who were NOT crazed lunatics) were also railing against an establishment; in this case, the Carnegie Mellon Software Engineering Institute (SEI). The agilists’ message was that they were “lean and fast,” while anyone who followed the SEI was “heavy and slow.” Put simply, it was the younger generation calling their village elders (or at least their software processes) FAT.

The defiance had gotten personal. They were mad about project overrun statistics and sick and tired of being blamed for them. All those Ed Yourdon Death March projects had taken their toll. They were not lunatics, but they were irreverent for lots of reasons, and it was understandable.

Manifestos and name-calling seemed to help the Agile message to stick. Moreover, if Agile rides a Google wave, it will make a lot of software development organizations consider following Google’s lead.

Meanwhile, there’s an interesting quote by a long-ago congressman named Willard Duncan Vandiver. In an 1899 speech, he said, “I come from a country that raises corn and cotton, cockleburs and Democrats, and frothy eloquence neither convinces nor satisfies me. I’m from Missouri, and you have got to show me.” Some people say that the speech is the reason why Missouri is famously nicknamed, “The Show Me State.”

Westerners at the time used the phrase to suggest that Missourians were slow and not very bright. (There’s that name-calling thing again.) Missourians, however, turned the definition around and claimed that “show me” meant that they were shrewd and not easily fooled. (It turns out that the phrase was current before Vandiver, so the thinking is that his speech may have merely popularized it.)

Now here’s where it gets interesting. Manifestos and name-calling might have some frothy eloquence to them, but they neither convince nor satisfy one important constituency that many agilists need badly so they can practice their agile craftmaking. This constituency happens to be the people who sign the checks: senior management. Senior management has to buy into the idea and take risks with a “manifesto” concept that can impact the company that employs all of them. They’ve been around long enough to see fads come and go and can be cynical at times. Management also doesn’t like the processes that they’ve invested in to be called fat.

The agilists come to the elders and they ask for some money. They want a new thing called Agile Methods. The elders respond with, “You have got to show me some productivity metrics.” No metrics, no money. The agilists cringe, because they associate metrics guys as process-heavy people spouting function points.

But you don’t have to be process-heavy or say “function points” all the time to be someone who knows a little bit about IT metrics. I am neither of these and have been collecting essential core metrics on hundreds of projects over the years. Many of my clients in the last 12 months are companies running Agile projects, mostly XP and Scrum, and they want to know how they compare against waterfall projects.

We have plenty of data in a worldwide database of over 7,400 projects — agile, waterfall, package implementation, new development, legacy, military, commercial, engineering — you name it. The numbers are so very interesting that I can’t fit them all into this article. Suffice to say I’ve been on the lecture circuit recently on this subject and conducting webinars for people who want me to show them.

So what have I found? Here are some of the highlights:
• Agile teams have metrics. The perception might be that Agile teams are a bunch of undisciplined programmers slinging code and not documenting anything. Not true. They know their schedules (time), keep records of team members working on their projects (effort), they count requirements and things called iterations and stories (a size metric), and they keep track of bugs (defects).
• We easily draw this out along with their velocity charts on a whiteboard sketch. This profile is all we need to capture the measures and load them into a computer database.
• Agile trends can be plotted on a chart where a picture says a thousand words (or in this case, metrics). Smaller releases, medium-sized releases, and large releases are charted from left to right. Vertically, we can chart the schedules, team size, and defects found and fixed.
• As a group, the projects were mostly faster than average. About 80% were below the industry average line. Note that some took longer, for several reasons (too long to explain here). Some companies developed software in two-thirds or even half the time.
• They used larger than average teams. Even though many of the smaller releases used small teams, some — apparently in response to deadline pressure — used large numbers of people. One company applied seven parallel Scrum teams totaling 95 people, where the norm was about 40 people.
• On waterfall projects, the “laws of software physics” showed a predictable outcome of large teams trying to create fast schedules — high defect rates (sometimes 4x-6x). On Agile projects, we saw a shockingly low number of defects — in some of the companies. The best performer had high-maturity XP teams. These project teams showed defects that were 30% to 50% lower than average. Other less-mature Agile teams had defect rates that were more like waterfall projects.

The initial results from these companies were fascinating. One thing that stood out was that there was in fact a learning curve. The sample had a range of Agile experience from one to four years. You can easily see that the highest performing teams achieved a level of performance that the others didn’t match. Agile was not a cure-all for all of the companies, but it will be interesting to see how the others fare as time progresses.

Another factor that was interesting indeed, was that all of the companies were being challenged by the outsourcing/India option from the top down. Some adopted Agile methods as a better, faster — and, yes, cheaper — alternative while saving their jobs in North America.

It will also be interesting so see more patterns emerge as more data comes in. Soon enough, we’ll have sufficient statistics for a series of Agile industry trend lines against which we can make direct Agile-to-Agile project comparisons. And the Agilists will have something they surely have longed for all along: Agile metrics. And the village elders just might buy into the idea.

Michael Mah is a Senior Consultant with Cutter Consortium, and also Managing Partner of QSM Associates. He welcomes reader comments and insights at [email protected].