In the most recent VersionOne State of Agile Survey released in 2014, Business Analysts are considered the least knowledgeable about Agile. Please see the diagram below.
Working with many Business Analysts, I am not surprised by this statistic, but it does concern me. In the Scrum world, there is no official role for a Business Analyst. We don’t write the functional requirements the way we did in the past and a Business Analyst is not required or needed to write or draft user stories. Business Analysis skills are very much needed, however the traditional BAs that simply write functional requirements will either need to re-skill or retire.
Recently Forrester research shows that more than 90% of organizations are actively pursuing Agile. If Business Analysts do not learn and embrace Agile now, and they plan on continuing writing functional requirements in the ways they have in the past, then they should start planning a new career as their positions will soon be eliminated in a future downsizing effort. If the BAs in your organization have not made the transformation to Agile, please call us at Enfocus Solutions; we can help. We can provide you with the education, knowledge, and tools to transform you business analysis function to the Agile world. Please attend the Webinar tomorrow to find out more.
[cta id=”7436″]
I note that 90% of how many organizations?
We keep hearing of a number of kinds of Agile. Some claim that Agile is ONL a principle or approach but NOT a method.
If there is NO method, what is it that is followed? Is there any specific way of applying the Agile principles (let’s first agree on the latest valid list of principles) to generate expected results within some tolerance?
Are there some other factors that determine how and if Agile works? If so are they officially recognized and made part of Agile?
Specific answers to these may help knowing what Agile is and what to do with it.
The survey does not state how many responded. It does state that 66% of the respondent were from North America and 20% from Europe. The Forrester Survey had 137 organizations with 90% using Agile.
The dominantAgile method is Scrum with over 55% of organizations using this method. Other methods include:
Scrum/XP Hybrid
Custom Hybrid
Scrumban
Kanban
Scrum methods are very well documented in many books available. Here are some techniques being used
– Daily Standup
– Iteration Planning
– Retrospectives
– Velocity
– Burndown
– Collective Code Ownership
Many surveys have been conducted about the effectiveness of Agile by reliable organizations using a large database of clients. One leader researcher, Standish Group reports that Agile projects have 3 times more chance of success than non agile projects.
Specific factors to measure agile should match your business objectives.
– Higher Quality
– Faster Cycle Time
– Higher Customer Satisfaction
– Higher Developer Satisfactions
– Better Business Outcomes
Agile has shown significant improvements in these areas over plan-driven development. It is for these reasons that Agile is being widely adopted.
Thanks for the information and sources. They will be more effective to popularize Agile.
So, what BA skills do you think are needed?
David,
I think Business Analysis skills are needed now more than ever. However, I think that Agile changes the role of a traditional requirements analyst.
In Agile, requirements are written by the Team, the Product Owner and others in a collaborative way. The requirements are expanded through conversations between the developer and the product owner or SME.
I think the skills that are most needed are discovery skills such as:
– Defining the business need or problem
– Preparing the business case
– Defining the Vision
– Defining capability gaps
– Analyzing and designing the business process
Agile changes the ‘roles’ for everyone. I sometimes imagine developer-oriented web groups with comments like ‘you mean I have to talk to the business people now?’
anyway, some of your examples are more about project definition and initiation, something PMs might have an opinion on. I have done business cases, but it is mechanical task because given a project definition, the business defines the benefits and developers define the costs; slap then in a spreadsheet with payback and ROI calcs and that is done (and if the business declines or fears to define $ benefits, don’t just make some up…) And who is defining capabilities in the first place?
Process is key, but defining it comes before development of any kind, defines where systems are needed and scope before any first iteration.
you see, not every IT project is new s/w dev, most are maintenance or COTS implementations, the latter where a BA is needed but developers are not. So it is two-way street. Widen your viewpoint and see that not all projects are agile, because they don’t need new s/w. What we really need is not agile s/w development, but developed s/w that is agile.
The number one reason that projects are late, over budget, and do not meet expected functionality is because of incomplete requirements due not incorrect elicitation, documentation, and management of requirements. BAs are the most capable and experienced at this crucial phase of all projects including Agile.
In my case I’m a Certified Scrum Master, that is also a Business Analysis Manager, and BI Analyst. So munch for putting professions in a box.
It’s interesting how many people believe Agile is a method or a process. Perhaps it’s a philosophy or framework. There are MANY organizations that practice Agile that have absolutely NOTHING to do with software. And furthermore, you do not need to have new development to utilize Agile, maintenance teams can utilize Agile just as effectively as development on greenfield projects.
While Scrum has eliminated the BA role from inclusion in the framework, I think we should be careful to avoid the leap toward shooting all the business analysts to put us out of our misery. There might not be a specific role by title, but that doesn’t necessarily mean there is no need for skills traditionally provided by BAs. Let’s also remember that often product owners are key customer/business stakeholders who know their stuff, have day jobs and don’t know much about software development or how to represent business interests in SD.
We must realize that we might need to sell be differently to highlight skills/skill sets without too much worry about what we’re called. In the meantime, let’s try not to panic. There are plenty of legacy waterfall projects that could use good BA.
I am amused by statements like “Number one reason….” as if everything else is perfect and predictable. There are multiple influences and situations at play which must be collectively addressed and processed in a balanced manner to progress to a series of intermediate goals leading to overall goal. This is precisely why I believe multiskilled professionals share multiple responsibilities and work together without “perfect or complete ….”
IMO Agile is gaining popularity to accept incomplete and imperfect inputs at inception and still moving ahead. This is certainly a welcome approach but overall goal, incremental planning, preparation and are still necessary.