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