Self-Organization: Create your Own Role

Back view of businessman looking at mechanism of cogwheels.jpeg

Self-organization is one of the principles of the Agile Manifesto. The concept is that the team is better able to organize itself and plan its work than any manager could be. And self-organization’s merits are best shown in the Daily Scrum (or Daily Stand-Up), where team members will volunteer expertise that others might not know they have, saving their team members time and headaches. Self-organization is awesome.

And we Business Analysts often have the most difficult time with it.

We BAs have for so long viewed ourselves as the "requirements people." We elicit them; we gather them; we document them; we analyze them; we model them; we manage them. For many of us, our job starts at the beginning of a waterfall project and slows down once we turn requirements over to development.

That’s not how it works with Agile.

Instead, we have a list of prioritized features from the Product Owner, hopefully in the form of user stories and acceptance criteria. Often, the team can run with those, asking any clarifying questions and developing the features rapidly.

So, what’s our job?

Assuming we are not the Product Owner or ScrumMaster, we are team members. And it’s our job to work with the rest of the team to deliver the functionality that we (as the team) commit to. Everything else… we figure out through self-organization.

Consider some of the typical tasks that roll up under user stories: UI design, technical design, development, testing. Tasks are typically performed by a single person (whereas user stories are team efforts). Most BAs are not going to handle development tasks, but some of us will work on the UI design and testing efforts. We can help out with implementation. And we spend a large amount of time resolving analysis spikes.

Just keep in mind that it’s not your job to get this stuff done. It’s the team’s collective job to accomplish everything. So yes, feel free to jump in and help with development (if you’re able). And test away. Do whatever is necessary to help your team be successful.

Because that’s the job of an agile Business Analyst.