by Nikesh Parbhoo,

Business Analysis (BAPL) Consultant

Confessions of an Agile convert

Having to work in an agile environment for the first time can be a daunting challenge, particularly if you’ve done work in waterfall environments for most of your career. Agile is being adopted to a greater degree in IT delivery. You will find that each country, city, industry or client/employer will either be more mature or less mature at effectively applying Agile techniques. Ensure that you understand where you need to operate at in this maturity continuum.

What does it take to make that leap across the chasm into the world of agile?

Firstly, read up on agile as much as you can. The IIBA has the Agile extension to the BABOK which is useful.  Speak to as many professional agile practitioners as possible. Some cities have Agile meetup groups that you can leverage off.           

If you have a decision to make regarding accepting a piece of work in an Agile project, your preparation should give you the confidence to say yes. All your analysis skills developed in your Waterfall life is fully transferable in Agile. Agile is just a method of work – the skills associated with being a business analyst remain the same. Attention to detail, people skills, business acumen and all other good BA skillsets will be to your advantage in any Agile space.

Know your new tools and artefacts

Gant charts, Microsoft project, requirements specification documents and business process management tools/artefacts are some the assets of knowledge you would have built up during your waterfall career. Agile is less structured, and so you need to understand your new paradigm of working and the tools that go with it.

The Atlassian suite (Jira and Confluence) is widely used in agile IT implementation projects.  The good news is that using these tools are intuitive and nota mountain to overcome to become productive quickly.

‘Let go’ of your artefacts

Typical Waterfall BAs have a very close, sometimes emotional relationship with their artefacts, be it the requirements specification document, business process maps, etc. This ownership mentality is something that must loosen up in an Agile environment where the team owns the artefacts through co-creation and collaboration.

The BA takes primary accountability for an agile artefact (like a User Story), but it is ultimately a product of the greater team. Don’t feel like your space is being intruded upon when the product owner or the SMEs make a change to your User Story on Jira.

Agile is more human

Agile offers teams the ability to think and produce value like we do natively as human beings.  We naturally operate on a try-fail-try again basis as humans. Think babies or children and you soon realise that they essentially operate on an agile basis. They are never perfect, but they are constantly trying and eventually get it right. The frustrations that accompany the ‘throw it over the wall’ mentality of Waterfall evaporate quickly in a well-run Agile team. Remember: Fail fast to get to ‘good–enough’ quicker.

Information Crosshairs

For all its goodness, Agile also presents some challenges. Information flow is one of those that Agile cannot necessarily fix. Too much communication, too little absorption by all the relevant stakeholders can lead to rework, distractions and duplication. When important decisions are being made on the fly (which is a strength of agile), it is critical that these get communicated effectively to the team. Use the daily stand-ups to facilitate this.

Get everything into Jira & Confluence

Your agile project is probably using Jira/Confluence as its tool. Ensure that Jira (or any other tool of choice) is the one and only source of truth. A half-baked attempt at using Jira does not help the project move forward, and only serves to intensify the problems associated with information crosshairs.

Jira is great, but Kanban boards can be better 

Tools like Jira are fantastic to keep track of all your user stories. Physical Kanban boards where team members update their stories at daily stand-ups form part of powerful agile rituals that can congeal a team. There is something inherently primitive about having a tactile experience of moving a card to ‘feel’ progress. More so, a physical Kanban board is a prevailing communication tool to sponsors, program managers and similar management stakeholders that have a constant visual report they can access at any point in time.

Physical Kanban boards however, do not work very well when you have distributed teams located across the globe. In these circumstances, a Kanban board can work better for a localised team that is working on a stream within a larger project.

Getting the best people in the room

This concept is not unique to Agile. Having the best people in the room increases your chances of working in any environment. I have found that two key agile roles can have a huge positive effect on the life of a BA in an agile project are:

• •          The Product Owner:  This person needs to be a strong advocate for the system and should be empowered to make substantial decisions on behalf of the business.  All team members (business analysts included) will turn to the product owner when making critical decisions about the solution.
• •          The Scrum Master:  A good scrum master should be able to facilitate momentum on the project and clear any obstacles. A good scrum master connects the dots between all project disciplines and overlays this with his/her deep insights about agile practices.

Most importantly … play and have fun

Kids in a playground manufacture fun in a way that might be observed as chaos to an outsider.  An agile project has similar traits. Leave the shackles of your waterfall past behind and embrace a more collaborative (sometimes messy), but ultimately more energetic, adaptable and fun way of working.

To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn