Show notes
In this episode, we’ll take a look at the 12 principles of the Agile Manifesto and see what they mean in the context of Business Analysis.
After listening to this episode, you'll understand:
- How to apply each of the 12 principles of the Agile Manifesto to Business Analysis
- The mindset shift we need to make to be successful in agile environments
- What you can do to adopt agile practices, even in waterfall environments
Show Notes
The principles behind the Agile Manifesto help align mindsets and behaviors to help people shift their thinking. Below are some thoughts on how these principles may be applied in Business Analysis. I encourage you to review the values and principles of the Agile Manifesto for yourself and consider how they can be applied in your context.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
BAs need to focus on customer priorities and their satisfaction. We can help the team to achieve fast and continuous delivery of software by breaking large requirements down into smaller, valuable chunks that can be delivered in small increments. If you’re working in a waterfall environment, perhaps you can break your project into small phases to deliver valuable pieces sooner.
If you consider the time value of money, getting working software into the hands of your customer quickly allows them to start seeing some results while waiting for additional functionality and potentially start seeing income sooner.
Prioritization also comes into play here. We need to understand what capabilities are most valuable to our customers and prioritize the highest value items first, or at least work to understand how to properly prioritize based on things like value, time criticality, risk, cost or effort required, and other factors.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
As Business Analysts, we need to be transparent about our work products and be open to feedback. Frequent, short feedback loops (ideally based on working software, prototypes, or some other representation of the product) help us to get the critical input from customers that we need to adjust and ensure we deliver exactly what the customer needs and expects.
Get as close to the customer as you can and give them a way to interact with what you’re building. Use observation, interviews, and other techniques to get feedback and adjust your plans accordingly.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Frequent delivery of working software helps with the rapid feedback loops I just mentioned and potentially allows your customers or your organization to begin realizing benefits sooner.
Business Analysts can enable frequent software delivery by breaking requirements into small, valuable chunks as mentioned earlier. We can also use strong communication skills, lightweight prototypes, and visual modeling approaches to quickly create a shared understanding.
- Business people and developers must work together daily throughout the project.
Here’s where our communication and facilitation skills really come in to play. Often, business people and software developers have difficulty communicating.
Use your skills to bring these two groups together and facilitate a conversation, creating a shared understanding. Foster and promote a collaborative environment in which business people and developers can co-create a valuable solution.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This is similar to the last principle in that we need to create a collaborative, open environment. In addition, whenever possible, we need to find motivated people with the right skills for the project team.
Through stakeholder analysis and sharing a compelling vision of the project, you can help motivate the right people and influence others to support you.
You’ll also need to understand any roadblocks that the team is facing and work with others to remove the impediment.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Most Business Analysts should know and practice this one already. Always use the highest bandwidth form of communication available.
Email is great for moving files and calendar appointments, but it’s terrible for communicating. You lose all tone and nuances associated with other forms of communication. Not to mention that some people don’t check their email very often.
Instant messaging is a little better, but you still lose 50-80% of communication through that channel. Using the telephone at least allows you to convey information through verbal cues such as tone, volume, and pace.
Video allows you to use non-verbal cues and in some cases is almost as effective as face-to-face.
The highest bandwidth form of communication is face-to-face using a whiteboard or some other visual diagraming format. This allows you to relay the message using verbal and non-verbal cues as well as share ideas with visuals to ensure you have a shared understanding.
- Working software is the primary measure of progress.
As Business Analysts, we need to understand that the value isn’t in the documentation. Documentation is a means to an end. To get to that valuable outcome earlier, we need to keep our documentation as lightweight as possible.
Do just enough just in time and focus on outcomes rather than outputs.
Again, breaking requirements into small, valuable pieces helps get working software out the door and into the market.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This principle is all about working at a sustainable pace. When you have a project with an impossible deadline, have the courage to speak up and have an open discussion about options.
Can the scope be reduced? Can the timeline for some pieces of functionality be extended? Can we add more people or better tools?
An understand of true stakeholder needs and their expected outcomes helps with this conversation, as does building trust before it comes to this point.
For the team, make sure the vision and expectations are clear and you remove any non-value adding work.
- Continuous attention to technical excellence and good design enhances agility.
The ability to understand the solution architecture and how to start with high quality is essential. Quality starts with a clear understanding of the vision and follows through to requirements before a developer ever touches anything.
Understand what good requirements look like and create a shared understanding with your team. You can even use mockups, wireframes, lightweight prototypes, and other approaches to get clarity on the design.
- Simplicity–the art of maximizing the amount of work not done–is essential.
This principle aligns to the earlier statement about the need for lightweight documentation and doing just enough. Review all of your tasks and outputs and determine which add value and which don’t.
You can also look at this principle another way. Are there organizational processes that are overly complex or don’t add value? Use process models, value stream maps, and other tools to simplify processes. That’s a great way to add value to your organization.
- The best architectures, requirements, and designs emerge from self-organizing teams.
Finally . . . a principle that mentions requirements. Good requirements and designs emerge from self-organizing teams.
Notice the use of the word ‘emerge’. Requirements aren’t something to be gathered like ripe strawberries along a path.
Not all requirements will be known upfront or be clear right away. Requirements need to be discovered and sometimes they emerge when a team works together to come up with something new.
The self-organizing part is similar to the principal about building teams around motivated individuals. Use your facilitation skills to create an environment in which a diverse group of people can come together to come up with new and unique solutions.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
To continue to improve your analysis skills, you need to reflect frequently on what you did, how you did it, and outcomes achieved. You can do this on your own or within a team.
Be open to feedback and accept it in the spirit it’s given; like a gift. And like when you receive a gift, the only response you should have is ‘Thank you’ or perhaps ‘Thank you. Tell me more’.
Constantly question what could be better in order to continuously improve.
Most importantly, do something with the feedback. Take action to improve. Continue to refine your skills. Learn, cultivate, and grow.
Listen to the full episode now!
http://traffic.libsyn.com/masteringbusinessanalysis/MBA089.mp3
Z
Your Homework
Review the 12 principles of the Agile Manifesto and consider how they apply in the context of your role.
Links mentioned in this episode:
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
The post MBA089: Agile Manifesto – What it Means to Business Analysts appeared first on Mastering Business Analysis.
Our TOPPODCAST Picks 
Stay Connected
