We are seeing a lot of success with agile projects when an experienced BA is on the team. We have completed two iterations of a project internally using an agile approach and our business users are very happy with the results. They are also happy with the fast turnaround time. Agile is really just about scoping a very small set of requirements and quickly producing a software component that answers the need. All of the same analysis skills are required: elicitation, analysis, problem solving, communication, verification, and validation. The work is just done on a smaller piece of functionality and the team is 100% dedicated to the project.
Initially some agile experts downplayed the need for a BA on these projects. They assumed that experienced developers could also do the business analysis work. But as we know, not all developers can or want to do business analysis. With a BA on the team, the developer can do what he or she does best – code.
Share your agile experiences here – good and bad. Let's help each other show that we add significant value to these projects, just like all of the other types of projects we work on!
Coming soon - a B2T White paper: "How does a BA add value in an agile project?"
2 Comments
The term "agile projects" is something really new in the Brazilian systems development environment, but the idea to make always smaller versions to keep scope under control is vivid here. Even working that way, we can't see it working without having BAs on the team because someone has to make things make sense. It's really easy to implement and document a series of small changes, but who's' going to take care of the whole scenario? I have systems that were run that way for years and ended up being a complete mess because no one took care of basic things such as the stakeholders and the respect for theirs interests by the system. Something a BA lives for. The use of agile without BAs or not depends on what kind of service you are offering. If your clients take real care of the system, it's interactions with the business, you may adopt the agile approach and become a small changes supplier. If your clients demand SOLUTIONS, you will need BAs to be your change agents. We work to offer solutions and act like partners, sharing responsibility, so, we designed the area with - 3 BAs: Responsible for scope definition, business use cases, system use cases, entity class diagram and state machine diagrams. 10 Analyst-programmers: responsible for the refined entity class diagram, DAO and MER (database). They are also responsible for the programming and for the pure programmers management. 4 Pure programmers. People seem to be happy working this way because they can focus. Not having pure system analysts is good too because we can slowly transform the programmers with analysis capabilities into system analysts without loosing the programming side. They trust us as the ones who take care of the stakeholders interest while they can focus on the system interests (such as framework issues). Kerber ITBA Digitro Technology http://www.digitro.com http://www.kerber.com.br
In my view, a good BA could well play the role of on-site-customer, which is a crucial role in an agile (or any) project.