BA World - BA in AGILE Projects

1,025 views

Published on

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,025
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
44
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

BA World - BA in AGILE Projects

  1. 1. MethodGroup business analysis specialistsIs a BA required on an Agileteam?Lucas Murtagh – Lead Business AnalystMethodGroup – Business Analysis Specialists
  2. 2. MethodGroup business analysis specialistsAgenda
  3. 3. Agenda  Introduction  Projects   What are projects?   How projects work and why some succeed and some fail  Business Analyst   What role do BAs perform?   Good BAs Vs Bad BAs  Agile Concepts   So how does agile work?  Traditional Vs Agile Analysis  Wrap Up – We need to change our behaviour to become Agile  Questions?
  4. 4. MethodGroup business analysis specialistsIntroduction
  5. 5. A little about me Lucas Murtagh
  6. 6. A little about me Born in 1974
  7. 7. A little about me Lived in the bush for most of my teens
  8. 8. A little about me Studied actuarial & maths at Uni
  9. 9. A little about me Spent first five years of career crunching numbers in Actuarial and developing complex systems to understand risk
  10. 10. A little about me Got offered a job as a full time gambler
  11. 11. A little about me Got married and had some kids
  12. 12. A little about me Had to get a real job
  13. 13. A little about me Became a BA…..Real Job!
  14. 14. A little about me Worked on lots of projects
  15. 15. A little about me Across many industries
  16. 16. A little about me Telecommunications Throroughbred Racing Mining Banking Wealth Management Insurance Media Property Asset Management
  17. 17. A little about me A variety of subject areas, sizes and complexities
  18. 18. A little about me Some projects went well
  19. 19. A little about me Some projects didn’t go so well
  20. 20. MethodGroup
  21. 21. MethodGroup Clear philosophy Simple Structured Collaborative Industry Aligned Approach to Business Analysis
  22. 22. The world is changing IT is moving faster than the business Companies are subscribing to services rather than building applications
  23. 23. The world is changing What does this mean for us?
  24. 24. MethodGroup business analysis specialistsProjects
  25. 25. © 2009 Forrester Research, Inc. Reproduction Prohibited
  26. 26. Rusty and Waterfall   Slow to market   Documentation is out of date by the time it’s complete   Product/Solution is out of date by the time it’s delivered   Silo behavior   May be restricted by what has been agreed in contracts   Worker slave relationships within project It must have some good points….
  27. 27. Definition of Project 1.  Project:“A temporary endeavor undertaken to create a unique product, service or result” 2.  Has a definite beginning and end 3.  Is Unique 4.  Consumes resources 5.  Starts with an objective
  28. 28. Where do Objectives come from (worstpractice)?   From a senior manager’s posterior   As a knee-jerk reaction to a media article   From a big lunch with a supplier   From something someone said over drinks at a conference   From the Chairman’s wife not being able to get through to the call centre   From the need to be seen to be doing something   From hearing that’s what they do in the US
  29. 29. Where do Objectives come from (bestpractice)?   An efficient business will continually forecast the emerging threats and opportunities in their market   An efficient business will continually measure and analyse the effectiveness of their operation and will thereby identify opportunities for improvement   Based on these inputs an efficient business will devise and maintain an explicit business strategy including strategic objectives   An efficient business will identify the programmes of work required to deliver the strategic objectives   Project objectives should trace up through programme objectives to the overall business strategy   All objectives will be SMART
  30. 30. Example of a reasonably clear objective JFK Stated this one objective in a speech It is Timely, there is time component to the objective It was Realistic with Our goal is, before this the technology decade is out, to send a man It is Measurable, available at the either the time (although to the moon and return him astronaut returns ambitious) to send a safely to earth alive or he does man to the moon John F Kennedy not Congress passed the funding – it was Agreed SMART!
  31. 31. Why Projects Succeed Project Success Factors % of Responses 1. User Involvement 15.9 2. Executive Management Support 13.9 3. Clear Statement of Requirements 13.0 4. Proper Planning 9.6 5. Realistic Expectations 8.2 6. Smaller Project Milestones 7.7 7. Competent Staff 7.2 8. Ownership 5.3 9. Clear Vision & Objectives 2.9 10. Hard-Working, Focused Staff 2.4 Other 13.9 Source: Standish Group, Chaos report, 2007
  32. 32. Why Projects Fail Project Challenged Factors % of Responses 1. Lack of User Input 12.8% 2. Incomplete Requirements & Specifications 12.3% 3. Changing Requirements & Specifications 11.8% 4. Lack of Executive Support 7.5% 5. Technology Incompetence 7.0% 6. Lack of Resources 6.4% 7. Unrealistic Expectations 5.9% 8. Unclear Objectives 5.3% 9. Unrealistic Time Frames 4.3% 10. New Technology 3.7% Other 23.0% Source: Standish Group, Chaos report, 2007
  33. 33. Why projects fail – My Experience  The real problem trying to be solved is not understood  The solution is agreed before the problem is understood  There’s no planning. Not just the PM but BAs as well  People don’t talk  People infer and assume rather than getting the facts  Project teams don’t work together to achieve the goal….SILOS and blame
  34. 34. Why projects succeed – My Experience   Everyone is on the one page and understand the end goal   Everyone has a clear role, deliverables and realistic scope/schedule   The project team works together. The business, IT and Vendors are one. Not Silos   The right skills are on the project
  35. 35. MethodGroup business analysis specialistsBusiness Analysts
  36. 36. BA ROLE IN PROJECTs Every project team needs:   Someone who understands the business domain   Someone who understands how people behave   Someone who looks at the bigger organizational problems   Someone who helps with the management of artefacts and requirements   Someone who can help create diagrams/models to illustrate system working better   Someone who can help capture learnings and adapt
  37. 37. The IIBA defintion  A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.
  38. 38. What are BAs really doing  Working in Business and IT projects. Mostly IT.  90% of the time BAs deliver   Business Requirements   Functional/Non Functional Requirements   Use Cases/ User Stories   Requirements Traceability   Process Maps and Procedures   Data Modelling   Lots of workshops/1-1 stakeholder interviews   PA services to PM!!!
  39. 39. Good BAs  Have fantastic written and verbal communication  Build trusted relationships with Stakeholders and their team  Keep all stakeholders on the one page  Plan their activities  Have a clear approach to completing deliverables  Use modelling, benchmarking and reviews to identify gaps and ensure quality of business needs and solutions  Don’t over analyse.  Identify and communicate risks and issues  Love unraveling ambiguity  Are proactive
  40. 40. Bad BAs  Write down what the stakeholder tells them to write down  Create the requirements themselves rather than engaging the business. Become SMEs  Write confusing requirements and define a solution rather than understanding the business need  Document to-be processes without testing they will work  Sign up to unrealistic deadlines  Say yes rather than ask why  Act as a PA rather than BA  Are reactive
  41. 41. MethodGroup business analysis specialistsAgile Concepts
  42. 42. The Agile Philosophy   Individuals and interactions over processes and tools   Working software over comprehensive documentation   Customer collaboration over contract negotiation   Responding to change over following a plan
  43. 43. © 2009 Forrester Research, Inc. Reproduction Prohibited
  44. 44. Kate and Agile   Fast to Market   Collaborative   Everyone is clear of what they’re responsible for delivering   Team commits to each other   Continuous review of approach, products and outcomesSounds great but must choose the right project
  45. 45. Agile Methods   SCRUM   Lean   XP Scrum is the most commonly seen
  46. 46. Scrum’s 3 + 3 + 3Three roles   Product Owner – Describes the Vision. Represents the business and its stakeholders. BA often perform this role.   Helps write user stories   Prioritises the product backlog   ScrumMaster – Runs the process. Makes sure the team adheres to the rules   Sounds a bit like a Project Manager   Development Team – Build the product   Self organising   Analyse, Design, Build Test & Train
  47. 47. Scrum’s 3 + 3 + 3Three artifacts   Product Backlog   List of the features requirements that need to be delivered   Provides an overview of the business value and development effort required to build   BA play a very important role in helping formulate and prioritizing this list   Sprint Backlog   The sprint backlog is the list of work the team must address during the next sprint.   Work is not allocated. Team members pick the next task as required   Can be split up into “Done”, “In Progress” and “To-Do”   Burndown Chart   Charts the work remaining in a sprint
  48. 48. Scrum’s 3 + 3 + 3Three Meetings   Sprint Planning Meeting   Select what work is to be done   Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team   Identify and communicate how much of the work is likely to be done during the current sprint   Daily Scrum Meeting   What have you done since yesterday?   What are you planning to do today?   Do you have any problems that would prevent you from accomplishing your goal?   Sprint Review Meeting   Review the work that was completed and not completed   Present the completed work to the stakeholders (a.k.a. “the demo”)   What went well during the sprint? What could be improved in the next sprint?
  49. 49. The Agile Overview
  50. 50. Agile works best when   Project delivery (and ROI) can be incremental   Core team can be co-located and are dedicated (business and technology)   Governance model allows for high visibility and adaptive planning   High commitment and availability of stakeholders and executive sponsors   Scope and/or High Level Requirements are not stable or clearly known   A small team structure which is cross-functionally skilled is feasible   Majority of development is on a single system, although may interface to many   Project has low external dependencies on vendors or other projects
  51. 51. There are tools to help you confirm yourproject is a candidate for agilehttp://www.hostfrontier.com/.../008_Agile%20Project%20Selection%20Criteria.xls
  52. 52. MethodGroup business analysis specialistsAgile Analysis Vs TraditionalAnalysis
  53. 53. Agile Vs Traditional Analysis Requirements planning activities Set the stage to gather requirements for the project, identify stakeholders etc. Traditional Agile  Project chartering sessions to   Conduct product vision and define vision, identify roadmapping workshops stakeholders etc   Design and plan release and  Analyse overall high level plan iteration planning workshops for project delivery- tasks, time, delivery dates
  54. 54. Agile Vs Traditional Analysis Requirements elicitation activities Identify the sources of requirements and then elicit requirements from those sources. Traditional Agile  Plan elicitation techniques   Plan and conduct short suitable for project and requirements modelling stakeholders sessions throughout each  Plan, design, and conduct iteration requirements workshops over   identify user acceptance test weeks/months data in real-time while story is being designed/coded/prepare for testing
  55. 55. Agile Vs Traditional Analysis Requirements analysis activities Understand and refine requirements further so as to help customer prioritize Traditional Agile  Define full scope up front   Work with customer, to define  Develop analysis models for all high-level scope up-front (just- requirements enough scope)   Work with customer to define user stories and develop supporting models if-and-when needed through each iteration   Customer is responsible for prioritization based on business needs and ROI
  56. 56. Agile Vs Traditional Analysis Requirements specification activities Refine and organise requirements into documentation Traditional Agile  Write a full-blown requirements   Customer and team work specification document together to write user stories   Create user acceptance tests for each story   Determine the form and format of any other documentation that is necessary and sufficient for requirements-related work- in-progress, handover, or product documentation.
  57. 57. Agile Vs Traditional Analysis Requirements management activities Monitor the status of requirements and control changes if any Traditional Agile   Smallest necessary requirements  Write Requirements Management attributes are established for each Plan backlog item  Establish requirements baseline,   Use simple requirements mapping document change control and organization techniques such processes and generate as story cards on the wall requirements traceability matrices   Changes are considered an  Conduct change control meetings important aspect of the Agile approach and these are incorporated quite simply as part of the next iteration
  58. 58. MethodGroup business analysis specialistsWRAP UP
  59. 59. Tips to being a great BA in Agile Work beyond the title of ‘Business Analyst’  A change in mindset is required- same work, different tools/format/techniques/physical environment  Learn to keep the requirements slices to a bare minimum necessary until it is just about to be developed  Connect the development team to the ultimate sources of business needs  Get the clients closely involved in the development of the project  You are not the sole custodian of all the requirements, you are part of a self-organizing empowered team  We need to be more adaptable
  60. 60. MethodGroup business analysis specialistsQUESTIONS?

×