Wagile Product Development - Being Agile with Waterfall Clients

No notes for slide

Some people may have never worked this way – PRD
There are still organizations that function this way
Define a project, stages and timeline and trying to hit the deadline with a lot of unkowns at the beginning of a project
More than just a methodlogy for delivery software, an entire corporate culture
Separation
Separate teams handoff – stages – hold up the entire project
Leader accountability without ownership
Sets up a culture, of blame, lack of engagement

Releasing software when it’s ready to meet a market need, not to a specific data
Discovery requirements as you go – not holding off development for all the pieces to be 100% specked out
Responding to change
Culture of collaboration – even with customers and end users
Involves all stakeholders and promotes a culture of collaboration

Few companies succeed at fully implementing agile to a T
Works great for consumer startups that have never worked any other way
Super challenging to transition an organization or leadership to agile
agile – buzzword – follow ceremonties without incorporating the ideals
BCBST – hour long daily standup
Challenging to shift waterfall clients to working with an agile organization
Stakeholder-centered methodology – like user-centered design – meeting your stakeholder where they’re at – just cant handle a huge shift after 30 years of working a diferent way – your job is not to be an agile – its to build great products

Wagile – blend of waterfall and agile methologies – agile ideals and waterfall reality
Building a culture of stakeholders and customer engagement, accountability

Identifying the internal agile team and the external waterfall team

Agile ceremonies and culture with the scrum team
Engineering sprints, stories, test-driven , xp – whatever is part of your culutre
Defined structure phases for external stakeholders
Set release dates and specific time periods for external stakeholder feedback, testing and input

Technical documentation for clients to meet expectations for training their own sales teams
Internal team – technical writer – involved in planning
Meeting every sprint to review release notes and integrate updates to documentation as much as possible

Internal roadmap/release review
Internal stakeholder involvement – engineering, marketing etc
Plan multiple features
Select a few to be externally facing

Client roadmpa review times
Bring major stakeholders together in clietn council of possible
Have them organize your roadmap – manage to their expectations
Just review the external facing and put those on a release plan, talk around other stuff that’s not the main list

Aha!

Set releases – deliver on a release schedule – set date as you get closer, frequency up to your business needs

Theme will help focus value on the externally announced feature – release other features to ensure the success of hat for maximum impact
Ensure all internal stakeholders are involved continuously throughout

Integrations and go to market will make or break your product

Internal – consumers, end users
All your user testing tools still apply

External validation
Initial validation – roadmap
Client council
Sales cycle opportunity for validation
mid release, feature validation -

End of release testing opportunity for validation – hopefully you’ve done enough ahead of time

Talked about enterprise and transitional organizations
Wagile may be a first step to being fully agile, but maybe not

Agile insistent that you cant know the future – the best way to ensure success is to accept the uncertainty
Stll provide a structure thye can work around

The details and exact needs may vary based on the business and client needs – have created

Wagile Product Development - Being Agile with Waterfall Clients

Jeremy Horn

Wagile Product Development - Being Agile with Waterfall Clients