Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (15)
Semelhante a The Evolution of the Agile Business Analyst
Semelhante a The Evolution of the Agile Business Analyst (20)
The Evolution of the Agile Business Analyst
- 1. The Evolution of the Agile Business Analyst ALSTON HODGE, ENTERPRISE AGILE COACH FEBRUARY 9, 2012 A PRESENTATION TO AGILE-CINCINNATI
- 2. A Quick Survey Within your company: Do you have Business Analysts? When you transitioned from traditional waterfall to Agile approach, what happened to your Business Analysts? What role (product manager, process engineer, business analyst, etc.) typically serves as the Product Owner? Do you have multiple POs per project?
- 3. In 10 words or less…. What do you think is the role of a Business Analyst?
- 4. Consulting:
- 6. In the Beginning…… 1970s – beginning of software application development Business Analyst role emerged Liaison between business and computer departments Goal of application development: increase revenue, reduce cost 1980s – emergence of PCs Need for distributed systems Client serve technologies Attempts to formalize SDLC methods Consulting Business Analysts 1990s – emergence of Internet IT department struggle to keep up Businesses do their own development Quality Movement
- 7. In the past decade…. Business Analysts found in IT and business areas Combined IT and business knowledge/skill Core task: Defining requirements Shift from “software” to “business systems” Translator: Business-speak to Techno-babble More offshoring Working with distributed, culturally diverse teams More detail required for some business sectors (insurance) Agile was formally recognized No formal roles Team focus
- 8. Agile and the Business Analyst Agile is Humanistic “Individuals and Interactions” Customer Collaboration” Agile is Pragmatic Working software Highest business value first Product Owner assignment is most important in Agile. What role should fill the job?
- 9. PO Core Responsibilities Establish vision & goals for overall project Represents the users or customers for the project One voice, even if not one person Typically a person with product knowledge
- 10. More Responsibilities Knowing what to build and in what sequence Manage the return on investment (ROI) Establishes baseline target ROI Measures project against this baseline Prioritizes product backlog to maximize ROI Calls for releases
- 11. Agile Business Analyst (ABA) Traditional BA techniques become even more important in Agile: Liaison between Business and IT Detailed Requirements Gathering/Definition Stakeholder analysis Constant process re-engineering
- 12. Agile Business Analysis is: About increasing the delivery of maximum business value Ensuring the development team has: the right information The level of detail At the right time To build the right product
- 13. Product Owner Scrum Team Scrum Master Simple Scrum
- 14. Product Owner Product Owner Business PM Scrum Product Team IT PM Owner Scrum Architect Master Product Owner
- 15. Product Owner System C Product Product Owner Owner System B System A Business PM Lead PO/ABA Scrum Team Scrum Architect Master IT PM
- 16. Misuses of an ABA in the PO role The Un-empowered BA serving as Proxy PO BAs commonly used for PO role If not truly empowered, a proxy only adds to the length of the feedback loop. Tendency to do all of the backlog (not prioritized) The un-supported BA serving as Proxy PO New/inexperienced BA assigned to complex projects No current-state documentation The un-trained BA No business knowledge No Agile training or experience Business Analysis is commonly under-valued
- 17. What does it take to be a Great ABA? Focus on delivering maximum business value Business knowledge (of course) Facilitation skills Business Analysis skills: Story Mapping Personas/Stakeholder analysis Business Modeling Detail-oriented
- 18. Timing is everything Agile business analysis delivers pretty much the same artifacts as traditional, but: Lightweight (avoiding waste) Just-in-time More frequent feedback loops Evolve over time
- 19. Recommendations for Becoming a Better ABA Get certified in Scrum (CSM or CSPO) Lots of great books on Agile practices/techniques User Stories Applied – Cohn Agile Modeling – Ambler Agile Estimating and Planning – Cohn Agile Product Management with Scrum - Pichler Visit your local IIBA chapter BA Competency model Credentials model (CCBA, CBAP) Agile Extension to BABOK
- 20. BA Body of Knowledge International Institute of Business Analysis Certifications available The Agile Extension to the BABOK Guide (Nov 2011)
- 21. The Agile Extension to the BABOK Guide Agile Extension drafted - November 2011 Business analysis primer for Agile SW development Intro to business analysis practices/techniques Mapping traditional practices to Agile practices For all team members, not just ABAs Get the draft copy now, for free!
- 22. IIBA Agile Extension includes…. Business Analysis in different Agile lifecycles Scrum XP (eXtreme Programming) Kanban Techniques Personas Value Stream Mapping Story Mapping Kano Analysis Backlog Management Agile estimating Collaborative Games Retrospectives Lightweight documentation
- 23. Questions?
- 24. Contact info: Alston Hodge, Enterprise Agile Coach 1613 Crosstimbers Drive Louisville, KY 40245 309-531-0611 alstonehodge@gmail.com
Notas do Editor
- OK, let’s start off our discussion with a baseline of where we all are currently, with regards to using BAs.
- Take a look at this list.These are just some of the companies I’ve coached in the past 9 years in Agile.Guess what is one challenge common to all of them?How to use Business Analyst in an Agile environment.Moving from the traditional waterfall approach to an Agile approach is more than just changing the methodologies. It involves changes in the way we think of team member roles and assignments.In a beginning of the Agile movement, a Scrum team was portrayed as one with no roles, just assignments. There is no Business analyst, project manager, or systems analyst. There is only the ScrumMaster, Product Owner and the team. The team is made up of people who are cross-functional, meaning they can analyze, design, build, and test.And for small companies and small projects, that approach really works well.But as larger companies, like State Farm and T-Mobile, began to adopt Agile, this approach was not quite as easy to adopt. Larger companies have larger systems with more complexities and integrations to consider. To expect a single product owner, to be knowledgeable of all of the business processes involved in larger projects, is simply unrealistic. So some companies have evolved to using Business Analysts, or Agile Business Analysts to serve as proxies to a team of Product owners, each representing their own system or business line.So now the Agile business Analyst is serving as facilitator of the Product Owner team and the single point of contact for the Scrum development team. The ABA serves to collect requirements and translate into stories for the Product Owners.This can actually work very well, if the following Scrum principles are held to:The Proxy PO (ABA) is a single voice from the PO team to the Scrum team.The proxy is empowered to make quick business decisions on a daily basis.The PO team can respond to questions and ideas from the team (through the proxy) on a daily basis.ABAs serving as proxy POs is becoming more and more popular with larger companies. And I’ve a few incidences of it now being used at Humana. I would not be surprised to see it growing in the coming years as the concept is demonstrated to be more effective than the classic “One PO per Team” approach.
- Do you know what this is? A pink IBM punch card.It was the first card in your stack of cards that your ran in batch jobs.There was no such thing as Excel, no Word, no PowerPoint, not Microsoft of any kind.All we had was a key punch machine and card reader.And there were no such thing as developers, systems analysts, or business analysts.
- Software applications didn’t actually begin until the late 1970s. So compared to other industries, it’s really relatively new.And as business began to discover and realize the business possibilities of using computers, computer systems and applications become more and more complex and sophisticated.Specialized roles began to emerge, since no one person can realistically do it all.One of the special roles to evolve since the 1970s is the Business Analyst. This person’s primary role was to serve as the liaison between business people (who had a business problem) and the technology people (who developed business solutions).In the beginning the name “business analyst” served as a constant reminder that any application software developed should further the business operation, either by increasing revenue, reducing costs, or increasing the level of service to customers.Now, by the 1980s, software development lifecycles were becoming more formalized and the business people were becoming accustomed to sophisticated software, but they continued to want it faster and better.Then emerged the Personal Computer ( or PC), which gave anyone and everyone an opportunity to be a computer programmer, designer and user. The growth of PCs led to distributed systems which led to client server technologies. And all the while, software development methodologies tried to become more formal and structured in an attempt to drive efficiency in development. But in reality, business people became frustrated waiting for the large, slow moving IT departments to rollout yet another cumbersome application, which by the time it was released, the market conditions had changed.So a lot of business people started learning to do things for themselves, or would hire external consultants, called Business Analysts, to help them with automation needs. This created problems for the IT departments now, who ended up having to support software that they had not written or approved. Everyone had their own databases which often meant inconsistent data. The role of the internal business analyst was somewhat diminished during this time.By the late 1990s, the internet emerged as the new technology. I was working at the Oak Ridge National laboratory when the internet was still only a government system not available to the public yet. Each department at the Lab had their own webpage which as nothing more than an information page. And I remember how the IT departments were once again challenged to respond quickly to business requests for speed. As IT departments struggled to deliver, many business areas began driving the technology as never before and staffed their own areas with systems analysts and Business Analysts.At the same time, during the 80s and 90s, we had the quality movement with TQM, Six Sigma, ISO, CMMI, which established standards and required more facts and rigor during requirements gathering and analysis, which highlighted the need for more skilled business analysts familiar with not just the business, but IT and quality best practices.
- So today, in the year 2012, most companies have business analyst in both sides of the company. And the expectation is that they have both business acumen and IT knowledge.And at the core of the role is still: the ability to define requirements.But that skill is even more challenged today:With so many companies utilizing off-shore development and testing resources, the requirements need to be in more detail. The successful BA cannot assume the an off-shore team even understandsd the basics of your business.Consider this. In the past 5-6 years more insurance companies in the US are utilizing India offshore companies for development and testing.In the US over 83% of people have health insurance.In India, less than 6 percent have health insurance.Commercial Health insurance has been in the US since the mid 1800s (over 120 years now)Commercial health insurance has only been available in India since the year 2000, (12 years)So is it realistic to expect our global partners to understand the insurance business? If we choose to take advantage of the lower cost services offered by offshoring, we will need to provide more detail about the business, more than we would for people in the US who have grown up with insurance all their lives.That’s why the role of the Business Analyst has become so important in the last decade.
- Then enters AGILE and the Agile Business Analyst.Agile concepts and techniques have been around for nearly 40 years. But it wasn’t until about 11 years that it was formalized recognized. The Agile Manifesto summarized key principles and values for an approach that was much more conducive to the business needs to deliver faster and cheaper and with higher quality.When you step back and look at the Manifesto, it seems to be very humanistic and pragmatic.The focus is on people and understanding the customers and how they interact. I also focuses on the importance of delivering actual working software and providing the highest business value first.And the PO is recognized is the most important role in Agile Development.Afterall, the PO sets the vision and product goal, defines the requirements, sets the priorities, approves all work before being released. From the beginning to the end of the project, the PO is in the driver’s seat.So who should be filling this important role?Ideally it should probably be a product manager, process manager or maybe even a marketing manager. But for larger companies, it’s difficult to dedicate a manager full time to a project. After all, product development is only one part of the total product lifecycle that a product manager is responsible for managing.For many companies today ,especially larger ones, the business analyst is becoming the obvious choice, a proxy, for driving these important concepts.
- Let’s quickly review the role of the Product Owner.The core responsibilities include:
- Within the Agile approach to delivery, Collaboration between the business, IT and customers are recognized as paramount to success. And as many companies began to adopt the Agile approach to delivery, the role of the Business Analyst has become recognized as crucial for success, but not without some hiccups.The Agile approach promotes Lean concepts of minimum documentation and only producing what the team needs. And unfortunately some companies and teams interpreted this as “no documentation”. That might work OK for small projects and small companies, who, by the way, were the early adopters in Agile. But as larger companies like State Farm and Humana have learned, we need more documentation. So the challenge becomes to determine the right amount of documentation.You see, larger companies don’t have a few independent projects and teams. We have large programs and portfolios of projects to manage. And add to that the fact that our systems are becoming more integrated and connected, the business and technical complexity and sophistication of our service offerings are growing exponentially. Add to that the fact that of-shore utilization has grown from 40% to nearly 75% in the last 4 years. So in the beginning (back in the 1970s) the role of a business analyst emerged from the need to help business folks communicate with the IT folks to solve some business problem.Today, with so much more complex, complicated and distributed systems and services, The Business Analyst role has become so much more that a liaison.He or she needs to provide:more detail in the actual business requirements to partners that may not have the personal experience of using the services we have come to understand daily.Help teams better understand the actual users and stakeholders of the solutions being developed.Constant process-reengineering of business processes as offerings expand and systems become more integrated
- So let’s consider the role of the BA in an Agile project. Consider the basic Scrum flow. In certified ScrumMaster class, you learned about the simplest view of Scrum:1 team1 product owner1 Scrum Master and 1 productAnd when initiating Agile to an organization, we typically pilot Scrum in this fashion.But what do you do when your product actually touches 3 or 4 different systems, and you have offshore resources?
- Here’s a possible worse-case scenario for a Scrum team I coached recently:4 POs, each in different locations2 PMS, one IT and one BusinessAn SME/Architect A scrum team with members in 3 locationsAll 4 POs were feeding stories to the Scrum team, each were also injecting stories in the middle of the sprints.I was called in to help them determine why “most stories carried over to the next sprint”.So what would you recommend?
- Well, first of all, the team is being barraged with input from so many people.So we formed a PO team and they selected one to serve as the lead PO? Guess what role the lead PO was?A business analyst.We also convinced the PMs to work through the PO and Scrum Master, rather than contacting and interrupting the Scrum teams.The Architect gradually evolved in being a true team member, once we help them to understand the value of agile modeling and design over big up front designs.
- Of course, there have been challenges to using Agile Bas as Product Owners
- So what does it take to be a great Agile BA?Well, Agile business analysis is:About increasing the delivery of maximum business valueEnsuring the development team has:the right informationThe level of detailAt the right timeTo build the right product
- So what’s included in the Agile Extension?Information on how to perform business analysis in different Agile frameworks, including Scrum XP and Kanban. In one survey over 70% of companies that claim to be Agile are doing Scrum oe a combination of Scrum and XP.But probably the biggest value for me is the techniques highlighted that, for larger projects, are critical, such as:How to develop personas to help teams understand their customersValue stream mapping techniques for current state/future state analysisAgile EstimatingCollaborative games