- We will learn about Susan’s transition from waterfall to Agile as an Agile business analyst
- Understand the differences for the requirements approach on an Agile project.
- Integrate best practices on an Agile project.
The Vanguard Group went Agile to shorten implementation cycle and to deliver most valuable features first. Makes sense to us, a great reason to go Agile!
Agile for Vanguard Group is:
“Better, Faster, Cheaper.”
As an Agile business analyst, Susan tells us that back in 2007 a enterprise initiative was funded for a multi-year program and went Agile halfway through!
A life before Agile business analysis for many projects looks like:
- Project Charter
- Estimate requirements up front
- Negotiate requirements duration
- Produce a project plan for requirements phase
- Conduct requirements sessions
- Document detailed requirements in templates
- Go through a change control board for changing requirements
- Handoff to development team
“Certain kinds of projects cannot be Agile.”
After transitioning to Agile, Susan’s team found that:
- Processes are responsive to change with iterative planning and smaller units of work.
- The teams have daily communication
- The Agile teams are cohesive in that they are committed, accountable, and available
- During the transition, Susan’s team stopped cold turkey their old ways and went Agile. Interesting point here!
Agile at Vanguard has successfully transitioned to Agile over three years and developed Agile training curriculum in-house! This is a great success story!
The biggest takeaway here is that it takes time to transition to Agile, three year transition is not to shabby.
What Agile Scout liked about Susan Block’s talk:
We found, from Susan’s talk, that the biggest challenges to transitioning to Agile from Waterfall included the following:
- Scope open to interpretation
- Scope management during requirements phase
- SME participation in requirements sessions
- Deliverable contraints
- Product changes
- Process changes
- Lack of team cohesiveness
- Communication gaps
Some of the suggestions that Agile Scout elicited from Susan’s talk when transitioning to Agile include:
- Co-locate your team
- Attend Agile training as a team
- Engage Agile consultants (as needed)
- Use project artifacts to build an initial Product Backlog
- Just start writing user stories, even if they were bad in the beginning
- Use “Planning Poker”
- Leverage business and technical architecture
- Convert your CCB meeting to a Scrum Planning meeting (if applicable)
- Challenge your team in continuing to learn Agile practices
- Engage in retrospectives in every sprint
Susan’s client experienced great things with Agile! Some quotes:
“I no longer wait 10 months from the time requirements are captured to time they are fulfilled in production.”
“Requirements now reflect my changing business needs.”
“I no longer have to review and approve long requirements documents. Requirements are packaged in smaller increments.”
“The project management ‘red tape’ is gone. Everything is visible on the scrumboard. Business and IT have daily interaction and accountability.”
Some great questions for Susan:
Question: “What’s the perfect balance for the amount of requirements to write?”
Answer: “Most important are the business rules and context. But the business rules are the most important.
Question: “How communicate project status to individuals not around the scrumboard?”
Answer: “Holding a weekly meeting on progress with business stakeholders.”
What are some tips for the Agile business analyst?
- Attend daily standup
- Focus on commitment
- Be flexible
- Apply skills and swarm
- Stay hungry to close stories
- Lend / Receive team support
Biggest difference between waterfall and Agile?
- Requirements upfront
- Large undertaking
- phase approach
- fully decomposed requirements
- abstract description
- 20% business value delivered
- 80% documentation
- Requirements as you go
- Small units of work
- Iterative approach
- Incremental requirements
- Functional product
- 80% business value delivered
- 20% documentation