Dancing inside the waterfall - ProjectTalks - ProjectTalks · Ryland Leyton, CBAP, PMP, is a...

Dancing Inside the WaterfallBorrowing Agile Concepts

to Benefit Your Waterfall Environment

www.RylandLeyton.com

[email protected]

@RylandTheBA

Ryland Leyton

http://www.rylandleyton.com/

mailto:[email protected]

© Ryland Leyton 2019 [email protected]

Agile is a set of values, not a standard.

We are uncovering better ways of developingsoftware by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.


Waterfall practices have trained our customersinto bad habits. We can remedy that if we try.

IT projects are hard. They’re expensive, they take a lot of work from my team, they don’t deliver anything for a long time, and they inevitably ask me to cut scope. So, at the beginning, I always ask for everything I could possibly ever want, so that I have a chance of getting at least some things I need by the time I get the deliverable.


The following ideas should not be controversial.• We always want to improve the

delivery process.

• Faster delivery is better than slower delivery.

• Projects benefit from engaged and collaborative stakeholders.

• It is important to create business value.


We always want to improve the delivery process.


Don’t we already do that?

“Lessons learned” meeting at end of project:• Becomes shelfware, possibly tribal knowledge.• Is often perceived as “blamestoming”.• Is too late to make a difference on the project

that created the knowledge.


Let’s do something when it can make a difference.Why not have a periodic “Team self-check?”

• Have a facilitated 60-minute meeting every 2 wks.

• List problems and barriers to getting work done.• The team (not managers) vote on which one is

most important to fix.

• Brainstorm on what the team could do to fix it.

• Identify action item owners (like at any meeting).

Continuous Improvement of DeliveryThe applied concepts: • Creating a self-managing team of knowledge workers.

• Enabling, empowering, problem solving, delegation.

The thing(s) you do: • One 60-90 minute (NOT LONGER!!!) meeting every 2 weeks.• Facilitated session. No managers are present.• Team members surface problems, roadblocks, issues that they think will improve

their productivity, happiness, or quality.• Team votes on which is the most important to solve.• Discusses how to solve that issue for 20-30 minutes.• Outcomes: owned action items which attempt to improve the situation.

Note: if something the team is really struggling with is something they do not have the authority to solve, take that as a project management issue and try to help them.

How to say it without mentioning agile:

“We’re going to hold our own self-check every two weeks. I’d like to get the team to talk about what problems they run into so we can clear those ASAP, instead of finding out at the end of the project when we can’t do anything about it. I think this will really help us have good internal risk-avoidance radar, and hopefully enable the teams to be proactive.”

© Ryland Leyton [email protected]


Faster delivery is better than slower delivery.


Typical Waterfall pattern:Delivered value comes last.

THE FIRST MOMENT OFEARNED VALUE FOR THE CUSTOMER


Adding phases accelerates earning of value.

High level planning incorporating• Phase thinking• Parallelization• Customer review and checkpoints• Working software

R1 R2 R3


More phases is better.

• Earlier delivery of software.• Better adaptation to change.• Some benefits of iteration.• “Working software focuses the mind”.• Estimation of smaller pieces is easier.• Reveals hidden issues “end-to-end” in

the development process.

Deliver Completed Work In PhasesThe applied concepts: • Deliver end-customer value as fast as possible.

• “Working software focuses the mind”.• Get customer feedback and engagement; reduce requirement & expectation drift.• Reduce project risks.

The thing(s) you do: • Prioritize your deliverables.• Plan around working pieces of software (not functional components).• Achieve “parallelization” quickly. • Review work with stakeholders/customers at (or before) each release.• Have conversations about business value


“I’m thinking that [6-24 months] is a long time to wait to have completed work. Is there a way we could deliver in phases? It would help us with resource levelling and let us discover faulty assumptions and any critical problems sooner.”



Projects benefit from engaged and collaborative stakeholders.


Stakeholder engagement

“Working software focuses the mind”• Showing someone working software gets their full attention.• You may get change requests – put it in a future phase if you can.

• If your environment is resistant to phases…this may help change their mind!

“I have to deploy to show it to end users. I’m not ready.”• If you have software which is “QA Passed”, then you can figure a way

to show it to an end user, stakeholder, or sponsor.

Ways to Gain Stakeholder EngagementThe applied concepts: • Customer feedback is good.

• Earlier feedback keeps engaged customers• Consistent engagement reduces requirement drift.

The thing(s) you do: • (If possible) do your project in phases.• Periodically (2-4 weeks) show QA’d software to users/stakeholders/sponsors.• Gracefully accept feedback and collaborate on prioritization.• Organize your work around delivering business value.


“I know software projects can appear long and difficult, and you only see our work at the end. I would like to show you things as we accomplish them and get your feedback. “

“You’d have to understand that we’re not completing every feature at once, and things will be shown to you in pieces.”

“If you can accept that limitation, I would like to show you our progress every 2-4 weeks. Can I set up a cadence for that?”



It is important to create business value.


Business value vs. technical function:You already care about this, you may not know it.

Which of the following is valuable to you?

• The disc is installed.• The calipers are installed.

• The anti-lock system is installed.• The car slows down when you press the brake pedal.

Someone is building the brake system for your car.


A sample pattern we might see in construction:

• This is organized around what’s easiest for the technologists.• The customer isn’t being considered. • Bonus Question: At what point can you start getting user feedback?

Time

DB API

ETL

SECURITY

BIZ LOGIC

USER INTERFACEQA AND

INTEGRATION

SCALABILITY


What happens if your funding or scope gets cut…?

DB API

ETL

SECURITY

BIZ LOGIC

USER INTERFACEQA AND

INTEGRATION

SCALABILITY

Here? ..or here? …or even here?

“Foundation without a house.”

“Did you build the logic and the UI for the same things?”

Polluted app: some stuff QA’d, other not. No way to pull them apart.

Risk: This project is highly vulnerable to scope and/or funding changes.


Organize around business value instead!

…and so on.

• This is organized around what’s best for the customer.• Bonus Question: At what point can you start getting user feedback?


Project is less vulnerable to risk from change.Here? ..or here? …or even here?Scope/Funding change?

Organize Around Business ValueThe applied concepts: • Reduce risk to scope/time/funding change.

• Deliver business value faster.• Think as a customer.• Get customer feedback.

The thing(s) you do: • Challenge technologists to build using “lean” concepts, avoiding waste, focusing on constructing only those things which are needed for the feature at hand.

• Work with architects, senior developers, to create organizing principles.• Ensure features have been prioritized carefully by the business.• Try to think in terms of “what is just enough?” to construct this feature.• If you must, have brief period of “foundation” work, but only what is necessary to

enable the team to start constructing releases.


Speaking to dev team and stakeholders:“Team, I’d like to organize our project around features. I think this will let us bank project earned value quickly, and reduce risks. It will also help us frequently show our work to our stakeholders and sponsors, ensuring we are always building the right thing.”


About RylandRyland Leyton, CBAP, PMP, is a business analyst, speaker, educator, Agile coach, and technology translator. He has worked in the technology sector since 1998, starting off with database and web programming, gradually moving through project management and finding his passion in the BA field.

Ryland is passionate about strong analysis practice and prefers Agile environments where possible. He has built both Agile and waterfall SDLC processes for development teams, customizing each one to the challenges facing that particular client group.

Ryland is an active member of the Atlanta Chapter of the IIBA, speaks at local and national conferences, and serves as an Agile coach and educator. His early experiences as a developer have been advantageous when serving as the bridge between business and technology groups. He is well positioned to understand the needs of disparate teams all striving to ensure business success from their own point of view.

Ryland’s book, “The Agile Business Analyst” has received excellent critical reviews.

Ryland is a core team member of version 2 of The Agile Extension to the BABOK as well as the recently published IIBA Agile Analysis Certification Exam.

Ryland is Lead Business Analyst at Aptos.com, responsible for supporting high quality BA and Agile practices for development groups.

www.Amazon.com

www.RylandLeyton.com

[email protected]

@RylandTheBA

http://www.amazon.com/

http://www.rylandleyton.com/

mailto:[email protected]

Dancing inside the waterfall - ProjectTalks - ProjectTalks · Ryland Leyton, CBAP, PMP, is a...

Documents

Transcript of Dancing inside the waterfall - ProjectTalks - ProjectTalks · Ryland Leyton, CBAP, PMP, is a...