Reluctant Business Analyst Using Agile

I enjoyed the Business Analyst World Conference in Atlanta last month and presented “Confessions of a Reluctant Agilist” to a group of Business Analysts. I asked everyone to write down one reason they are reluctant to use agile approaches, and then encouraged the attendees to be more open about the possibilities for success using these new approaches. It’s interesting to see where the reluctance is coming from. Much of it seems to be related to myths about agile rather than facts. Here are some of the reasons reported.

Why Are Business Analysts Reluctant?

It’s not surprising that a number of BAs are worried about the lack of  requirements documentation and inadequate time for analysis. I believe this is a direct result of the lack of a role for business analysis on most agile teams. Unfortunately many of the agile methodologies (like Scrum) don’t acknowledge the importance of analysis. I am hopeful that agile teams will recognize the value of including an analyst on their teams anyway.

Myth: Agile Is Chaotic

Several attendees said things like: “The project will get out of hand.” “There is no change control process.” “Without structure will we truly meet business needs and will we have more defects?” These are valid concerns and ones that will be alleviated by learning more about agile processes and structure. Agile approaches do have structure and planned processes to keep the work in control. Daily stand-up meetings keep the team aware of progress and problems. Short sprints allow the team to benefit from lessons learned (retrospectives) and adjust their working rules to improve productivity.

Myth: No Requirements Documentation

In the Agile Manifesto the value of “working software over comprehensive documentation” really upset the business analysis world. Over the past 10 years, BAs have been searching for better ways to make sure requirements are not missed and to make sure requirements documentation is clear and unambiguous. We have worked hard to create “comprehensive documentation.” But agile doesn’t say that requirements should not be documented. It recommends that we document just what is needed and focus less on the formality of the documents. Yes, we need documentation for ongoing product support and future enhancements. Documentation is also important for verifying traceability and making sure we haven’t missed any important needs.

In Scrum, one of the most commonly used agile methodologies, user stories serve as brief requirements. They are really placeholders for the team to use when planning work. As each story comes to the top of the priority list, it is discussed, analyzed, and designed using whatever models and documentation make sense for it. Analysis is critical in agile. A particular type of requirements document is not.

Challenge: Management Support

As with any change, management support is critical. Several attendees expressed concern about the lack of commitment from their management to helping agile succeed at their organizations. Agile approaches recommend a dedicated team, but most organizations don’t allow a resource to be dedicated to only one project. Another concern was a lack of understanding of agile by management. One attendee said, “My management is using agile as an excuse to abandon documentation!” This is a very grave problem and one that must be addressed by educating managers and executives about the true nature of agile.

When managers don’t understand agile, it’s difficult for a team to operate well.

Challenge: Different Teams Working Differently

Most people agree that an agile approach is not right for every project. We’ll always have some teams working in a more traditional way. Organizations will need to find ways to allow different teams to work differently while still working together as needed. In addition, various agile teams work differently. They may perform work as they learned from an outside consultant or coach. Agile approaches are still evolving as their effectiveness is being evaluated. Some variation between teams should be expected, but we will also see more consistency as teams figure out the best practices for their organizations and products.

The Key Is Trust

Human beings struggle with change, and moving to agile is a big change. Fear, anxiety, and overly enthusiastic team members all contribute to the challenges of shifting to agile. Individuals embrace change when they trust each other and believe that mistakes are inevitable when learning a new way of working, and should therefore be expected and forgiven. Trust is a key value of successful teams. BAs understand the importance of trust and will be good team members, listening carefully to others and working to create value for their organizations. In a trusting environment, it’s much easier to deal with stakeholder reluctance, a lack of commitment, and a fear of change, as well as to convince businesspeople of the benefits of agile.

The Answer: Learn the Facts about Agile

Probably the most honest answer I heard from attendees was, “I’m reluctant to use agile because I  just don’t know enough about it.” The VersionOne survey on the State of Agile for 2013 reported that product owners and BAs are the least knowledgeable about agile principles and practices. Education–including learning the facts about agile rather than the myths–will help BAs feel more positive about the future of their agile projects.