home

Agile Software Development and Business Analysis

By:  Scott W. Ambler

In this article Scott W. Ambler, Practice Leader Agile Development in the IBM methods group, overviews agile software development and the implications for business analysts.

AttachmentSize
Agile Software Development and Business Analysis.pdf39.51 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Thanks...

A timely overview, especially the "favor left over right", not "ignore the right"... and a thoughtful prescription for Business Analysts, prsenting Agile as an opportunity, not a threat, the way one should approach any new challenge.

So, what does this mean for all of us, the Business Analysts working today? Where I am now, it is a smaller shop, less than 10 developers, of which I think only one could move to colloborating with the business in an agile way; the rest I don't know about. My role as bridge between developers and the business has been important in past projects, sometimes needing to explain in much detail why something the business wants is important; this has also been true in other shops where I have worked in the past.

So, I agree that Business Analysts should be prepared when "Agile comes to town", I just don't know if I am going to see it where I am anytime soon. What do other BA's reading this think? Is your shop going Agile? Is it ready for Agile?

David Wright
Member, IIBA

Baby steps, not giant leaps

One of the things that I tell people when I give seminars about agile development is that you can't do everything at once. Instead you need to adopt the techniques and philosophies that are most appropriate for your situation right now, improve what you can, and then do the same thing again and again in the future. You can't do everything today, but over the next five to ten years you should be able to make significant improvements.

Scott W. Ambler
Practice Leader Agile Development, IBM
http://www-306.ibm.com/software/rational/bios/ambler.html

Agile - Low Hanging Fruit?

A great article - you have provided some excellent guidance on how our community can start to adopt agile approaches.

Like anything else that introduces change it requires time to personally and organizationally incorporate change in to a culture. This is no surpise, but I found your comment that you should see significant improvement in 5 to 10 years a bit disheartening. Most environments would likely demand a faster pay-back period.

In your experiences are there specific elements of Agile that could be adopted early and successfully? The Agile Adoption Survey suggests that it is knowledge of the Agile approaches that is an important factor in achieving success, but it does not go into detail about the specific techniques that could yield a positive outcome more immediately. As you have already mentioned you can't go for it all out once - could you comment on the major priorities for new Agile Practitioners?

Rob Beckmann, Principal Business Architect Caro Systems Inc.

Low Hanging Fruit

As always, it depends. Typical consultant answer, I know, but unfortunately true.

Here are some suggestions for low-hanging fruit:
Introduce short iterations. I'm a firm believer that iterations should be no more than 4 weeks in length, but prefer one or two week iterations if possible. Short iterations help to squeeze the bureaucracy and waste out of the process because you simply don't have time.

Co-locate the team. Both developers and stakeholders should sit together as much as possible, and the development team itself should be in a single room together.

Active stakeholder participation. Put those folks to work! It's easy to do, and provide huge benefit in terms of improved feedback.

Document less, code more. The primary goal of software development is to produce high-quality working software which meets the needs of its stakeholders. The secondary goal is to ensure that you have adequate documentation. Keep those priorities straight.

Put a lot of whiteboards up, and let team "own" as much whiteboard space as possible. That way they don't need to capture as much information in official documentation because it's right there in front of them. And they have easy to use modeling tools at their disposal as a result.

Treat acceptance tests as requirements artifacts. There's a lot less documentation to do.

- Scott

Scott W. Ambler
Practice Leader Agile Development, IBM
http://www-306.ibm.com/software/rational/bios/ambler.html

Progressive Implementation

I believe that the best way to effectively introduce any new methodology or large scale practice to an organization is to adopt what may be termed a "Virus" approach. Rather than try to introduce some of the concepts across the whole organization at once, introduce all of the concepts to a small part of the organization at once.

As a first step:
- Create a small team of your top people, people who want to see the new thing work, who want to try it and make it successful and are generally well motivated and self sufficient. You will need some, preferably more than one, for each role you see for the practice;
- Get your new team a mentor, someone who has been through the wringer, successfully used the process, and can not only talk about it but practice is themselves. Then put them in a practising position in the team;
- Get a significant, non-vital and manageable project for them to work on that has senior management interest. It should be small enough to complete in a reasonably short time frame e.g. six months, but challenging enough to test the process;
- Get senior management support and organizational backing for the move. Do not let your team be constantly sniped at by opposition camps who do not like change;
- Create the right environment. If it is Agile then create an environment conducive to the way that Agilists should work, get the open rooms, the props, the white boards etc., etc.,
- Set targets that are challenging but at the same time realistic, but do set targets and monitor progress, and continually make adjustments.

When the first project is successfully complete, split your team in two, bring in your next set of people, create two teams, get two more projects of more significance, use your first team as mentors for your second and third teams and repeat the process.

If you started with ten people, and six month projects, then in two years, the "Virus" would have spread significantly, you would have completed 15 projects involving 80 people and be a long way on your trek to change the way your organization operates.

The Role of a Business Analyst in An Agile Practice

Scott,

I have been curious about the Agile practice upon intially stumbling across a copy of your book on agile modeling. I realize its stengths, at the very minimum, of improving the SDLC processes.

However, as a business analyst myself, I have been concerned that there is nearly no mention of the role of business analysts in Agile methodology even though prominent attention is given to developers, project managers and testers.

In your opinion, do you think the business analyst has a role in Agile practice? If yes, what do you think it is?

Thank you

Analysis is important

I think that analysis is an important thing, but that the role of business analyst is overly specialized. That isn't to say that business analysts can't work on agile teams, it's just that they need to expect to do more than just analysis. Having said that, an existing business analyst could potentially fill the role of product backlog owner, being the person responsible for providing information to the team, explaining requirements, and prioritizing them.

You might find http://www.agilemodeling.com/essays/agileAnalysis.htm and http://www.agilemodeling.com/essays/businessAnalysts.htm to be of interest.

- Scott

Re: Analysis is Important

Scott,

Thanks for the response and for the links you provided. They were very useful.

However, while methodologies such as RUP may have over-emphasized on "big requirements upfront" as a requirements development approach, is it not possible that Agile may also be over-emphasizing on "less and less requirements documentations"? In an environment where requirements are transiently documented on whiteboards, flip charts, etc., what happens if there is a need to go back to refer to the particular requirement, in the event of a conflict between stakeholders and developers, but then the "throw-away" documentation has been discarded?

In your experience how real is this scenario, and how does one go about resolving a misunderstanding around a requirement that does not have a permanent document and, therefore, there is no trace of it ever being agreed upon between stakeholders and developers? How important then is the use of a requirements traceability matrix in an Agile environment?

Again, thanks for explaining Agile to some of us.

RUP not BRU

I'll let Scott answer your question to him.

I would however like to point out that RUP has NOT 'over-emphasized on "big requirements upfront" (BRU)as a requirements development approach' which would be very much a waterfall approach and anti-RUP.

RUP is a customizeable methodology and while it is possible to use a BRU waterfall approach as one a life-cycle model it is very much NOT recommended by RUP.

I have assisted several large organizations in the adoption of RUP and always professed an agile AUP approach with success.

Re: RUP not BRU

Keith,

While I am aware that RUP takes an iterative approach to the development lifecycle, perhaps I should have made myself clear that the criticisms that it emphasizes on "big requirements upfront" and "over-documentation" are not mine but observations found in the literature.

I quote here an article by Gary Evans as an example: "Structurally, RUP is similar to the waterfall approach: Do requirements first; then do analysis, design, implementation and testing (the RADIT cycle); finally, release the product..." (refer to http://www.ddj.com/dept/architect/184414763)

Thanks.


© 2007 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group