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?"
October 8th, 2007 at 7:21 pm
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 www.digitro.com www.kerber.com.br
October 12th, 2007 at 3:28 am
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.
October 24th, 2007 at 6:08 pm
[…] Post original: Share your agile experiences here! […]
October 25th, 2007 at 3:39 pm
Strickly speaking what is being descrbed here is not Agile but Incremental which has been around for many years. And yes, it works. I think the greatest weakness of Agile methods has been the elimination of good business analysis in favor of light weight methods such as user stories.
October 26th, 2007 at 4:43 pm
James, I am interested in understanding more about your comment around the elimination of good business analysis for user stories. I think it may be a factor on how you use agile at your organization. From my experience following a recent successful agile project, user stories were extremely helpful in "compartmentalizing" a requirement scope but not defining how that user story was actually going to operate in the system as a whole. Analysis work still needs to be done to determine things such as: (1) story dependencies (2) functionality and features related to the story (3) UI requirements (4) integration concerns. Like I said earlier, I am interested in your experiences around agile development.
October 27th, 2007 at 11:53 am
Phil, thanks for your response. I have never been on an agile project and probably never will be. However, I have studied the literature and find most of the claims about agility to be questionable. If you want to streamline the requirement engineering process, I would recommend starting with event analysis rather than user stories. Events can later be mapped into either user stories or use cases (as triggers). The issue here is level of abstraction. The basic trace hierarchy is:
Goals/Events to
Use cases to
Use case steps to
Features to
Requirements / Data / Business Rules
Finally, note that:
(1): Story dependencies probabaly can be traced to goal or event dependencies.
(2): Feature mapping is very important but works better at the use case step level rather than the story level.
(3): UI requirements are simply requirements of UI features.
November 2nd, 2007 at 6:35 pm
James,
If I understand what you mean by goals or events they could be at the user story level depending how you choose to abstract the story. Having a user story that says: “As a frequent flyer member, I would like to be able to see my mileage balance.” could be considered a goal or event as well. It may not be the theoretical characteristics of agile (Scrum) user stories, but seemed to work well from this project I just finished. This is because you can do additional analysis to determine if this story can be broken down into additional goals and events (stories) or deeper analysis work would need to be performed.
November 10th, 2007 at 6:12 pm
True agile story: A superior asked me to write a brief email answering the question “Is our process agile?” Since I enjoyed comparing methodologies to practices, I dove in.
After reading and abstracting, I concluded that agile is
(1) carefully planned iterations
(2) iterations quickly done (hence “agile”) so important changes could be brought in during the current or near-future interations
(3) issue resolution by aggressive, group concentrations of all parties involved.
However, the iteration cycle planned for was 3 months. Not quite agile. I switched my attention to corporate possibilities and, looking for the silver lining, concluded in my email that “No, we’re not **quite** agile, but given people’s schedules, we iterating as fast as can be expected.”
* * * * * * * * * * * * * * * * * * * *
To relate this story to the current discussion: Expectations of agile development create unique, and possibly unforeseen, situations.
To remark on “needed BAs” aspect, in this company, BAs were the main leaders of the technical and issue work. Their actions were primarily responsible for the production shift from “slow waterfall” to “not-quite agile.”
November 13th, 2007 at 8:59 am
One of our instructors refers to “not quite” agile as little “a.” I think many companies methodologies are little “a” these days.
November 13th, 2007 at 9:19 am
Jim, we seen to experience the same over here. If my boss asked me that question, the answer would be the same. Our BAs are also responsible for the production shift from “slow waterfall” to “not-quite agile.”
Our iterations are taking about two months and it does not look that they will get shorter soon.
Thanks for sharing your research conclusions with us, I´ll keep it in my sleeve just in case he asks.
Kerber ITBA
Analista de Negócios
- Dígitro Tecnologia www.digitro.com / www.kerber.com.br
November 13th, 2007 at 9:35 am
[…] Post original: Share your agile experiences here! […]
January 3rd, 2008 at 2:59 pm
Currently the customer uses 1-week iterations with Agile Development Method in developing their applications and the former managers didn't believe in documenting requirements, business rules or hardly any piece of information on applications being developed. I read in Dr. Dobb's Magazine that using Agile to develop software doesn't mean not to document, but means to streamline your documentation so that development can be completed ontime and within budget. Developers here are responsible for of course development of the application as well as testing, QA and minimal documenting. I think Agile development is good but can be better if it understood that documenting system development is still required and what documents are needed before starting development.
June 13th, 2008 at 12:25 pm
My new assignment takes me to entirely new world where I would be solely foccussing on designing stuff, no more errors/excpetions in coding front.Not sure whether the change is for good or not.I come from agile background where requirement gathering and analysis is what agile developers do.I too was one of it.With this new role of Buisness Analyst/Solution Desginer,I am confused whether I would be suited for only those big budget projects or would I still mean to agile projects which are fast catching in software industry ??