Advanced Search
Username
Password
Forgot password?
 

Top Forum Posts
Welcome to the Catalyze Forums

The Forums on Catalyze give members an opportunity to network with other members and ask/answer questions on current topics.
Want to post?

You must be a registered member of the Catalyze community to post;

Click here to JOIN TODAY  If you are already a member, SIGN IN HERE
 
Forums > All Catalyze > Methods & Processes
Subject: Agile style projects
 Add Tag
You are not authorized to post a reply.  
Author Messages
Rating:
Kupe
Posts:8
08/31/2007 3:46 AM Alert 

Have you been part of an Agile team?  There are mixed views on how the Business Analyst fits in.  Please share your experiences and thoughts.
LMarine
Posts:28
09/10/2007 7:20 PM Alert 
I worked on a project last year that employed a form of Agile development. One of the key success factors was to design the interactions before starting any of the development iterations. I provided a complete set of interface blueprints, based on user research and user-centered design methods, to the development team. They used these to drive their Agile processes and only a few design changes were required.

The net-net of it all is that Agile (and XP) development processes are just that, development processes. They are NOT design processes and they work best if they have a big picture of the product laid out for them and then they iterate on the small sections of the design. This mirrors other projects I've heard of.

So, one way to help an Agile process succeed is to design the product first, then hand it off to the developers.
SarahKampman
Posts:3
10/18/2007 11:21 AM Alert 
Yes, at two different companies. After trial and error, some of the keys to success that emerged were:
* Do high-level specifications and estimates before the project begins, so that the team knows what it's putting into each of the sprints. You can't postpone detailed analysis, or the team will find it's agreed to things it can't actually deliver.
* Do postpone detailed estimates until you're in process, because scope changes and the domino effect will render premature estimates useless.
* Have the design fully spec'd and mocked up at least one sprint before coding begins, so that the developers have something to work with from Day 1, and so that any problems are identified before they begin.
* The BA/designer must be available during the development sprint to address last-minute questions and problems. Not having the BA available is a *huge* risk to the sprint, and designating an interim BA doesn't help as much as you think it would.
idebro
Posts:2
10/19/2007 5:20 AM Alert 

Posted By LMarine on 09/10/2007 7:20 PM
I worked on a project last year that employed a form of Agile development. One of the key success factors was to design the interactions before starting any of the development iterations. I provided a complete set of interface blueprints, based on user research and user-centered design methods, to the development team. They used these to drive their Agile processes and only a few design changes were required.

The net-net of it all is that Agile (and XP) development processes are just that, development processes. They are NOT design processes and they work best if they have a big picture of the product laid out for them and then they iterate on the small sections of the design. This mirrors other projects I've heard of.

So, one way to help an Agile process succeed is to design the product first, then hand it off to the developers.

 

 

 

hmm, that doesnt sound very agile to me, sounds more like the old waterfall:

agile development is about adapting and improving along the way.

 
Kupe
Posts:8
10/19/2007 7:31 AM Alert 
Great comments everyone. Sarah, I agree completely with your lessons learned. I have found the same to be true.
Kupe
Posts:8
10/24/2007 2:44 PM Alert 
Check out this article, http://www.mycatalyze.org/Default.aspx?TabId=871&FolderId=183&FileId=2415
LMarine
Posts:28
11/01/2007 5:44 PM Alert 

Actually, considering all of the other parts to product development that must occur, Agile is more waterfall than the process I mentioned. With Agile development processes, the other teams, such as Marketing, Sales, Training, Documentation, QA, etc., must wait for development to end. So, Agile tends to impose a critical path bottleneck, often running over schedule and budget and therefore creating an urgency on the follow-on activities.

By creating a blueprint of the product ahead of time, all teams, including development, can operate in parallel instead of having to wait for development to edn before knowing wht that the product looks like. This "blueprint first" approach has proven to reduce the delivery time by almost half. Moreover, it has kept the product truer to its intended target than Agile processes typically seem to.

But, as I said, my experience is limited, so the repeated successes I've seen over the past 15 years may be an anomaly.

Larry
idebro
Posts:2
11/06/2007 3:36 AM Alert 
Posted By LMarine on 11/01/2007 5:44 PM

But, as I said, my experience is limited, so the repeated successes I've seen over the past 15 years may be an anomaly.

Larry

 

 


No need to be ironic. I thought that the idea of a discussion forum was to discuss.

My experience of agile projects is faaaar less than 15 years, but what you describe is not what I would like to label as iterative and adaptive.

In the agile projects that I have perticipated in we started development after an initial conceptual analysis phase, were we identified users goals, stakeholders goals and the desired effects of the software. Then we stated to develop sotfware and did specifications along the way, just a little bit ahead of development. That way we could adapt to changes in the requirements easily.

/Idebro

 
Sam Hranac
Posts:2
11/20/2007 1:55 PM Alert 
I have to agree with idebro. I think there are some risks to being agile that you folks are trying to mitigate by taping a waterfall front to the process. Maybe a hybrid method does work, particularly for large projects. Smaller projects might benefit more from a purer agile approach, taking advantage of all the flexibility.

But then, I still don't have a lot of comfort with using agile on large projects.