The agile manifesto from a business analyst perspective

- 17 guys at a ski resort in Utah, it sounds like of a beginning of a bad joke, but that gathering in February of 2001 produced the Agile Manifesto, which prompted a significant shift in software development strategies and processes and now business operations and strategies too. The Agile Manifesto describes the common ground that this group of 17 methodologists found as they vented their frustrations and discussed what works to get to valuable, high quality products. They were frustrated by heavy document-driven processes for creating software with detailed plans, and this made changing needs difficult to address. In creating the Agile Manifesto, they were able to emphasize a shared set of values. These values strongly resonated with the rest of the industry and since then, the Manifesto has lead to many new approaches for software developers. But few have given pause to what this means for business analysts and requirements. So, let's take a look at how the Agile Manifesto applies to BAs and requirements work. The Agile Manifesto is made up of four values and 12 principles that Agile teams strive to truly be agile. First of the four values is individuals and interactions over processes and tools. For BAs, this means that we focus on face-to-face conversations over following a specified process. We use high-impact collaboration techniques to elicit and analyze requirements. While processes and tools may help at times, we want the interactions with the team to drive requirements. Next, working software over comprehensive documentation. For BAs, this can be a tough one. This is about making sure we focus on getting feedback associated with the actual software rather than feedback on a document. Requirements will evolve faster and more accurately when our customers and users get their eyes and hands on working software. Our role is not about documenting, but about facilitating value to customers and users. Third, customer collaboration over contract negotiation. This is all about understanding, as a team, that contracts and agreements need to flexible given our ever-changing environments. We need to focus on collaborating rather than requirements documents and contracts. Shared understanding through dialog will result in better products over a focus on creating a document as the process for requirements. We embrace the changing needs as we learn more about what we're building in a changing context. Last, responding to change over following a plan. We still plan in Agile, but we plan differently. We plan in value increments instead of big, task-based Gantt charts. This means we plan based on outcomes rather than schedule and tests. We work with a dedicated team to deliver a small piece of value in a short amount of time. With such an intense focus, a detailed plan is not needed to keep track of such a small scope. However, details of what's valuable is needed. We also plan longer-term in Agile, we plan with a vision, a product roadmap, and release plans. These plans are all about the value dimensions of what's being delivered, keeping the team focused on what's valuable. We still track progress in Agile too, but Agile tracking calls for transparency that often exposes rough spots for the team that may have been easily hidden before. We fight to keep work in progress small, so we can respond quickly when priorities change. The first sentence of the Agile Manifesto starts with "we are uncovering better ways." This lets us know that continuous improvement is important. There is no one way to go about it. The last sentence of the Manifesto is important too. It states that "while there is value in the items "on the right, we value the items on the left more." This helps us with not letting go of process, documentation, contracts, and plans, but to embrace collaboration, conversation, change, and outcomes as a priority over them. The Agile Manifesto's four values also come with 12 principles and that's what we'll look at next.