A few months ago, I had the chance to assist to the Montreal Agile Tour. There were a lot of very narrow conferences covering various subjects, all of them obviously focusing on the Agile mindset (you can read my review of the event in a previous post on this blog).
A few days after the conference, I realized that the Agile mindset can be applied in almost any situation, even outside of software development (where Agile is often considered as a methodology, and not necessarily a mindset). I saw a good example of this in a TED conference I listened to a few years ago.
This gave me the idea to put on my Business Analysis glasses and have a new look at the Agile principles. The exercise brings an interesting perspective on Business Analysis, whether you work in a waterfall or Agile organization.
The 12 Agile principles… revisited
The original Agile principles from the Agile manifesto can be found online (don’t forget to endorse the manifesto while you’re there!). Some of them are very straightforward and translate easily, but others require more thought. Let’s take a look at them from a Business Analysis perspective.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
It starts well, since satisfying your stakeholders is supposed to be one of your priorities as a BA too! Satisfaction comes from the value you generate for them, through a good use of your deliverables among other things. They have to be understandable by your stakeholders, but they also have to be of some use to them, not only to you or the implementation team!
Satisfaction also comes from a continuous and meaningful involvement in your activities. There is nothing worse than involving your stakeholders only at the end of your analysis process only to discover that you missed requirements or that you didn’t understand what they really meant!
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Change is inevitable in organizations, so you better get used to it. As a BA, your role is to guide your stakeholders in finding the best answer to change. However, welcoming change doesn’t mean to accept every change!
Change brings uncertainty towards the solution in your stakeholders’ minds. Reducing the uncertainty can be done through more teaching about the solution and how it can handle the change; through the identification of possible workarounds with the current solution; or through the implementation of a formal change request if required.
Brace yourself, change is coming!
Wait! There’s more!
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Like for the previous Agile principles, continuous involvement also means continuous delivery of BA requirements packages to your stakeholders. Not only this helps find issues with requirements faster, it also reduces resistance to change toward the new solution and facilitates the assimilation of requirements by your stakeholders.
And being in a waterfall environment doesn’t prevent you to integrate this principle in your BA activities!
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Here’s where the “BA as a bridge” stereotype comes to life! More seriously, these Agile principles are once again perfectly aligned with our work as BAs. Our role as a communication facilitator among all stakeholders (including business people and developers, among others) from the beginning to the end of a project is essential, no matter if you’re in an agile or waterfall context. These Agile principles are perfectly supported by our role.
And a few more principles to complete the review
7. Working software is the primary measure of progress.
Although BAs don’t deliver working software per se, this principle can be applied in a Business Analysis context. How? By creating value for our stakeholders, as stated above! Valuable artifacts are not working software, but they can be used to enable working elements of a solution by stakeholders (such as new business processes).
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Maintaining a constant pace as an Agile Business Analyst means that your stakeholders will have to be involved in your activities at a constant pace too, which can be harder to achieve in a more traditional, waterfall approach.
This is probably the hardest of all the Agile principle to integrate to your own practice. However, given all the benefits brought by the others principles, you could let this one go if your stakeholders don’t follow you 🙂
9. Continuous attention to technical excellence and good design enhances agility.
If you’re currently reading this (I hope you do realize that you are actually reading this), you’ve already integrated this principle to your habits! Take time to look at how your colleagues are working, what tools and techniques they use, what is going on in the Business Analysis community, so that you can improve yourself continuously.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Do you like what you’re reading?
Do you think you can integrate the Agile principles in your Business Analysis activities? Share your thoughts with us in the comments or on social medias!