Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


The Hotness of Agile - WebDU 2010

There’s been a lot of chatter about agile software development recently. Some say that it’s little more than cowboy coding. Some say that it means no documentation. Some say it’s the silver bullet that projects need to stop wasting time and budget blowout

Matthew Hodgson

on 7 November 2018

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of The Hotness of Agile - WebDU 2010

Agile Teams
Agile Frameworks
Agile Projects
Agile Philosophy
the Hotness of Agile
Working with Kanban
Agile + UX
Matthew Hodgson, Agile Samurai
blog: zenagile.wordpress.com
twitter: @magia3e
email: magia3e@gmail.com
mobile: +61 404 00 66 95
SMS Management & Technology
Capability Lead, Web Strategy & Information Architecture
Senior Agile Coach
Tends towards:
More structure
Longer iterations
Focus on process
Less able to adapt and change
Tends towards:
Less structure
Shorter iterations
Focus on communication
More able to adapt and change
Horizontals vs. Verticals
What they were used to:
Team members work on each separately throughout the project
Complete solution at the end
Groups work on each in relative isolation of each other
What I was suggesting:
Team members work together on each, simultaneously, in parallel
Complete solutions per sprint
Solution is emergent
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The Agile Manifesto:
Ensure repeat success
Prescriptive processes
Adaptive process
Set of principles
Body of practices
Manage the conceptualisation of software
Conceptual structure
Guides & supports
While your busy building
Client collaborates to help deliver the product
We delivered something of value:
A document
Working code
Every two weeks ...
Team discussed what they learned:
What did we do well?
What didn't we do well?
What do we need to do change to do better?
Keep repeating every two weeks until:
you finish the 'to do' list
You deliver!
Agile Documentation
The Iron Triangle
Test-Driven Development
What approach to choose?
Lack of agreement on solution
Project risk
Personas & Want Maps
User requirements
Business requirements
System requirements
Use cases
Data dictionary
Logical data model
Physical data model
Scenarios & Storyboards
Features in context
Requirements in context
User Story
Priority from workshop
Feature sets
Out of scope
Final priority
Stick into backlog to prioritise next sprint
Build & automate unit testing
Capture technical issues in Jira
My experience:
Burn-down/burn-up takes time
Estimation takes too long
Move toward:
Manage work in-flow
Pull rather than push
Demistifying the end-to-end Agile software development lifecycle
Use Jira to capture approvals in-flow for audit of decisions
Auditability And situational formality
Replaces formal paper processes for decisions and approvals
Wiki stores the procedural rules, including:
Business case - what's in it
Business case approval
Gateway approval processes
Approval milestones
Final sign-off

Stored in Wiki in SharePoint/Confluence
Stored on a bookshelf to collect dust
Regression testing
The Team
Situation = Choose the right person with the right skills
Extreme Programming (XP)
Feature Driven Development (FDD)
user-prioritised requirements
fixed cost
fixed timeframes
Where I recently found myself
Waterfall projects
Agile projects
Initial plan was ‘over-scoped’ by Project Managers
Over 35 documents / deliverables
Initial 4 months delivery time reduced to 8 weeks
Still required to plan, design, code, test and deliver
Lots of #FAIL with the previous project environment
Nervous client wanted something delivered
Client didn't want to wait til the end to find out the concepts wouldn’t work

Planning my way out of hell
"Clearing the fog" for technical solution
"Clearing the fog" for the technology solution
User Stories
Data migration
Document stuff
(38 delvierables)
Data modelling
Business architecture
Go to status report meetings w/ client
Data model
Things to produce
Test plan
Communications plan
Create Kanban board
Run risk workshop
Solutions architecture
Things to do
... yes, this is really just speculation
User login/
Data entry (x2)
Public view
Project's DNA
Planned for 'skinny solution' release in 8 weeks
Sprint 1
Sprint 2/3
Sprint 4
Pairing IA/BA
Developer off-site
All done in parallel
not in serial

Things people believe ...
What some people believe about Agile ...
Isn't that
We tried it before & it didn't work
That's just an excuse to do no documentation
Another name
"Cowboy Coding"
It won't work here.
We're different
Agile is so hot!
Documentation that just ends up in a filing cabinet
Being directed by a PM who are not part of the solution
Working for ages without producing anything
Spending money on projects that never get finished
Delivering a project ‘on-time’ and ‘on-budget’ only to find out that the user's needs have moved on

Agile means I am free of:
Deliver products earlier to the market
Work faster, smarter and leaner
Adapt to and embrace change as you go
The team manages itself -- everyone works so there's less waste and overhead
It focuses the project team on adding value, not working to the schedule
Less documentation -- you compensate by doing more communication

Benefits of Agile:
Cheaper cost of change c/w waterfall


Ultimately Agile enabled me to:
Embrace change faster
Embed learnings into the team quickly
Respond to PMs changes more readily
Agile is not a fad or a scam
It's just a way of
working smarter
Iterative approaches reduce project risk
Documentation is a placeholder for a conversation
Repeatable processes between projects
Applied contingent to needs within a project
Elvis is alive
UFOs are real
Bigfoot does exist
Salmon shirts are not pink
"On time" and "on budget" = successful project
Upfront planning & design lowers risk
"Agile is hot.
Why don't we give it a go?"
"Isn't that's just RUP?
We tried it 10 years ago
& it didn't work"
But are our
actual experiences
when doing
projects the 'normal' way?
Protect the Team from risks
Identify hurdles on the horizon & remove them
Mentor the Way of Agile
Champion UCD approach
Agile Samurai
Agile Sensei
Take ownership of the team & what they do - features, products produced
Teach the team the Agile Way
Lead by example (don't micromanage)
Agile Monks
Brains of the team
Do the thinking
Guide users
BAs, IAs, UXers

Agile Ninjas
The ones you don't see
Developers, Testers
Security analysts
Agile project initiation checklist:
Chose a flavour of Agile
Worked out scope by using DNA
Prioritised DNA
Choose my roles & team

Client got to:
Input new ideas
Help reprioritise items in the 'to-do list'
I got sick
Stay & infect the team
Go home & get well
Disaster strikes!
Traditional PMs don't
think Agile is so hot
Gantt charts
Staged deliverables
Big design up-front
Directed work
It was helpful!
Project was very organised when I got back
Someone else worried about big-picture timings
Someone else to do status reports
Someone to be my 'Gmail Calendar'
The bad news
Battle between two ways of working
The compromise
Sprint planning to kick-off work packages
Two days between sprint planning sessions
Sprints in parallel thereafter
Loss of cadence
Gain production of deliverables to a schedule
We got there in the end
The Good
The Bad
'On-time & on-budget'
PM learned a little about Agile ways of working

Meeting'd to death rather than getting on with producing
Documents instead of working software
This is why I think
- Anon PMI/PMBOK Crowd
The Result
User stories
Agile is experiential
... once upon
an Agile project
Adapted to Agile fairly readily
Got a good grip on the project needs
Things we did well
Not focussing on the sprint, but on old up-front design ways of working
Documenting too much
Not using simple visualisation tools very much
Things we didn't do well
Let's try to get the Developer up here for Sprint Planning
Let's move to weekly sprints so we get used to working in smaller chunks
Things to change
your new best friend
Project flow
... so I took two weeks off ...

... but when I got back ...
Some Agile resources to follow:
Follow the Twitter #agile conversation
Get an Agile Coach to help with your first project
Read blogs on Agile – zenagile.wordpress.com
Read books on Agile – the Art of Agile Development (James Shore)
Start with a small project, then work your way larger
And …
It’s ok to apply agile principles in Waterfall

Agile is hot for a good reason:
It gave me choice for delivering the project
Faster way of working
Different way of working
Reinforced visualisation of work and outputs
Increased team communication
Decreased reliance on documentation
Created a dynamic, exciting working environment
Full transcript