The agile methodology, like many concepts, is based on an “ideal” setting or environment. In the agile domain this usually constitutes a 100% co-located team of generalists who have unfettered access to the primary business stakeholder. Working in an ideal environment makes sense when you are describing theory, but organizations can find this perfect environment unachievable due to basic business constraints: resource skill sets, location, and time allocation. These constraints present barriers to agile adoption, can hinder productivity, cause frustration amongst the team, and can lead to project failure.
To mitigate constraints and foster the development of a simulated ideal environment agile development teams should incorporate the role of the business analyst.
The introduction of business analysts into their agile software development methodology may seem counterintuitive to Agile practitioners. After all, agile purists have been saying for years to cut detailed requirements gathering cycles out of the equation and rely on direct communication between users and developers. What some do not realize is that business analysts do more than elicit requirements and these unique skills not only adapt well to the agile methodology, but greatly improve it. In their role of developing requirements business analysts have built up core competencies such has effectively communicating with distributed resources, facilitation/elicitation, as well as a deep understanding of an organization’s business environment and enterprise architecture.
Each of these core competencies brings a unique value to agile projects. They should be leveraged whenever possible to mitigate many of the risks that agile projects traditionally face:
- Working with co-located teams
- The lack of “generalist” resources available to agile projects
- Waste caused by miscommunication with the business
- Alignment with enterprise architecture and business strategy
In reality, business analysts are not “agile road blocks”, but resources who agile practitioners can put to work.
Bring Remote Resources into the Mix
More and more businesses are adopting a ‘virtual office’ where employees work from home or remote locations. Unfortunately, this is bad news for agile teams who have become dependant on in person communication. Today’s agile development teams need to adapt to this reality, finding ways to replicate the face-to-face communication that a successful implementation of the development methodology demands.
For the business analysts these challenges are nothing new and have been overcome in the waterfall world by applying highly tuned and specialized collaboration techniques, such as business process diagrams, context models, and use cases which can also succeed in the agile environment. Through the construction of models and the introduction of basic requirements collaboration techniques, JAD sessions and virtual stand up meetings, the BA can open up lines of communication between co-located and remote resources. In this way the BA can work to simulate the team room environment using software tools and collaboration techniques to replace the whiteboards and index cards.
Put Specialists to Work
A small group of generalists, individuals who hold multiple roles on a project (design, develop, test, and deployment), are the ideal team for projects following the agile methodology. Unfortunately, generalists are far and few between making them difficult to hire. At the same time training generalists is not easier, requiring employees to complete multiple projects in numerous roles to build their skill sets. In most organizations not all agile project team members will be generalists. For agile projects to succeed without the benefit of generalists they need a bridge builder, someone who can work and communicate across multiple disciplines while ultimately keeping concerns of the business in the forefront.
Business analysts bring a breadth of knowledge to bear on software projects. In their role as a communicator and liaison they are tasked to work with developers, testers, implementers, managers, and almost all roles in the software development lifecycle. This interaction has given them a wide breadth of knowledge over the entire SDLC. While they may not know all of the intricacies related to the tasks associated with these roles or be able to perform them on their own, they can provide a bridge of communication to resources that can. The use of generalists on agile projects is ideal, because they have a depth of project experience and knowledge that increases their productivity. If we can inject some of that project knowledge through an effective liaison to other project members we can extend the reach of agile development by incorporating staff which normally would not be equipped to take on all development tasks. This new resource allocation reduces project and training costs will minimizing effects on productivity.
Communicate Effectively with the Business
Agile methodologies minimize risk through the introduction of short iterations or sprints for developing and deploying software. The underlying concept behind this approach is that if a business user or stakeholder does not approve of the software solution, it can be quickly changed in the next iteration. This approach works when experienced developers know the facilitations skills to elicit a potential solution from the business users. However, if the agile developer was able to gain a clear understanding of the business need and provide a useful solution project effort is wasted twice. Once on the sprint which got the solution wrong and then again on a sprint to make the correction.
Constant, direct, and meaningful communication between business stakeholders and developers reduces waste caused by misunderstood requirements, but only if that communication is effective. A frequent hurdle presented by this concept is that the role of requirements gatherer can be unfamiliar territory for developers. In many cases they do not know which questions to ask, what information to capture, or how to communicate with the stakeholders.
A skilled business analyst is a master of effective business communication and requirements elicitation. Agile projects can utilize this expertise by allowing the business analysts to act has an elicitation mentor to the project’s agile developers. In this role the BA can work hand-in-hand with developers to mentor and teach techniques for meaningful communication. By asking the right questions and constructing models to represent the future state solution developers will learn how to get the information they need to get the technical solution right the first time. Reducing wasted effort, contributing to on-time delivery, and implementing the features that the business users really need.
Think Beyond the Project
Even when agile developers are able to skillfully communicate with their business users the conversations tends to center around topics directly related individual issues surrounding the current project or system under development. Specific user needs, related business problems, and possible solutions are exactly what should be discussing, but this isn’t always the entire picture. That being said, it is a common occurrence for developers and business users to take a narrow point of view when constructing a new system, focusing on specific features and challenges faced by the user who is sitting in front of them. The problem with this approach is that an enterprise point of view is not considered. This lack an enterprise architecture focus leads to duplicate data, siloed systems, and missed opportunities for cross-business integration.
By assigning a senior business analyst, to serve as an enterprise architect, to the agile project the team gains a 30,000 ft view of a project including a perspective of how it relates to the organization as a whole. Bringing a sophisticated level of business knowledge to the project, the BA’s point of view provides business level context to the problem and the solution. This guidance ensures that the technical solution is inline with the current business objectives, constraints, and that the solution can be incorporated into the established enterprise architecture.
One method of ensuring alignment is the use of the Business Driven Development, a practice which focuses on building technical solutions that directly satisfybusiness requirements. To ensure alignment to business requirements a model-driven approach is leveraged which takes into account the business strategy, requirements and goals and then transforms them into an IT solution.
Agile development is not perfect. As with any methodology there are challenges. But, these challenges can be mitigated. The introduction of a business analyst, and their experience in communication, elicitation, and enterprise architecture, to an agile development team can reduce risks and improve project success and agile adoption rates.
We often use the acronym “BA” as short hand for Business Analyst. But, when properly incorporated into a project BA stands for Better Agile.
About the Author
Matthew Leach is a Consultant with Doreen Evans Associates, Inc. (DEA), a professional services firm committed to business analysis and requirements excellence. He can be reached at [email protected] and http://www.doreenevans.com.
