Agile Projects Role of Business Analyst in project success Presented by Faizan Tayyab
Common Development Methodology Teams lack structured approach to software development. Time spent on research before choosing the technologies & platforms. Interaction with customer at minimum. Initial meeting to gather requirements. Usually programmers play the role of analyst. (Collect requirements). Programmers start working right away. Each programmer working independently on separate features. If needed, programmers contact customer by email for clarification. Image: http://www.agileproductdesign.com/useful_papers/miller_customer_input_in_agile_projects.pdf Or so called methodology
Outcome Building too little, too late. Building lower priority items. Buggy software. Architectural risks. Software not maintainable. Change cannot be accommodated.
Adopting a Methodology Waterfall vs Agile Waterfall is linear with phases. Move to next phase only when previous completed. A lot of time and money spent on up front design. Agile Iterative & incremental. Continuous delivery of working software. Continuous customer feedback. Accommodating change. Testing early & often. Team review feedback and make informed adjustment.
Adopting a Methodology There are many examples of organization successfully adopting Agile. “ The main advantage I see is that you spend more time working on the right [system] features by talking to the customer all the time and working on it”……developer at BT. http://www.infoworld.com/d/developer-world/bt-case-study-in-agile-programming-112?page=0,1
Agile Success Adopting Agile doesn’t mean project success, therefore agile is not remedy for failing project. Although Agile makes sure that projects that are destined to fail will fail faster and cheaper. http://www.zdnet.com/blog/projectfailures/agile-anatomy-of-a-failed-project/1100?tag=rbxccnbzd1 Important point is to adopt and follow the Agile methodology (Agile manifesto) properly and ensuring all agile principles are put into practice. Each member of the team has to play a vital role and should be committed to the success of the project. Image: http://www.agilemodeling.com/images/generalizingSpecialistsAgileTeam.jpg Team work is essential
Customer Requirements Understanding the customer requirements is vital for success of any project whether agile or not. Important: At times user description will be vague and difficult to visualize. Ability to understand and simplify what the user wants and what the desired system should do. User will not understand technical jargon hence technical terms should be kept to minimum in discussions. Effective communication is a fundamental requirement for agile modeling. Issues: Semantics.
Importance of Complete & Accurate requirements Example: Mars climate orbiter went into orbit at 57km above Mars instead of 150km. Cause: some navigation calculations performed in Imperial units and some in metric units. Most project failures are due to incomplete/inaccurate requirements . Lack of customer involvement in requirement, defective requirements or unclear requirements are major culprits contributing towards project failure. Get the requirements right to achieve quality and customer satisfaction. Use collaborative workshops along with walkthrough and QA checklists to develop high quality requirements.. Requirement driven planning is necessary for product roadmap and release planning.
User Stories Creation of user stories. Needs to be simple as one or two line statements. No need to create lengthy requirement specifications. If a user story is complex (cannot be tested), it means it needs to be further simplified. It needs to be testable. Tasks defined on basis of user stories. If user stories are incorrect, the derived tasks will be incorrect. User stories should truly and accurately represent the customer requirements. With experience, the quality of user stories will improve. Use of available tools to manage agile lifecycle. Rally is a popular Agile lifecycle management tool .
Customer as part of team Collaboration. Customer prioritizes the requirements. Play vital role in deciding what to implement. (Customer may not agree with the rest of the team on which user story to implement first). This is the point at which negotiation is important. Something on which all members of the team must agree. Customer can introduce change. Communication preferred over documentation. Customer to obtain continuous feedback in form of working software (Not all functionality is implemented). Customer needs to be informed in all stages of software development. Maintain a communication plan (if needed) 2 nd biggest reason for project failure: lack of user involvement.
Managing Change Customer is always right. Need strong impact analysis. New stories to be incorporated into the backlog. Agile methodologies help manage change. Change will occur in almost every project. Ability to accommodate change in certain iteration. Agreeing with customers on change and prioritizing the change. Wait for next iteration. Restart iteration if vital. Traditional methodology not flexible to accommodate change.
BA & Development Team Ability to communicate with the development team at technical level. Involvement in stand-up meetings during iterations. User stories generated are fed into the development teams. (Tasks). Actively contribute in planning the agile iteration and releases. Estimation and maintaining backlog. Incorrect estimates are recipe for project failure. As the project progresses with each iteration, estimates tend to get more accurate.
Managing Iterations Need to keep track of the progress during iterations. Use of tools to track the progress. All relevant people including BA need to be present in iteration review. Ensure the backlog is well maintained.
Case Study Case Study: Development of location based social networking software. (Assuming this project failed) Pre Statup: Customer not clear about exactly what is required. A lot of changes are expected as project progresses. Technological decision can be made early however the requirements are difficult to determine. Initial estimates can be put forward. Communication plan/strategy can be laid out but should not slow down the overall product development. Time Deadline. Budget (can define scope). Agile Cycle: User stories (BA plays important role). Iteration/Sprint planning. Product Backlog. New changes Design, coding and testing. Iteration review/ code reviews.
Case Study Progress: Measure of progress is working software? Possible causes of project Failure: Customer doesn’t know how the product is being developed. No understanding of the impact their decisions have on the backlog. Not understanding customer expectations. Difference in assumptions. Customer takes a U-turn on things which are agreed earlier. Limited communication within customer environment. End users not kept within communication loop. Customer representatives not the right individual for the job.
Limitations with AGILE Limited support for distributed environments. Face-to-face communication still best of communication rather then video conferencing or other forms of communication. Limited support for developments involving large teams. It is recommended that agile teams should be small. This can be an assumption due to difficulty in managing large teams.
The End Thank you for your time. Any Questions?