Agile in Day SDEC – Oct 19, 2011 Take a seat: • < 6 months agile experience on the left • >= 6 months agile experience on the right • Do not sit at a table with someone from your company Look at the “What do you want to learn” questions posted on the wall: • Initial your top 5 questions Write down: • 3 things you have heard from other people on why agile won't work • 3 things that make it hard to adopt agile in your org • Discuss w/ your table
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Agile in Day
SDEC – Oct 19, 2011
Take a seat:
• < 6 months agile experience on the left
• >= 6 months agile experience on the right
• Do not sit at a table with someone from your company
Look at the “What do you want to learn” questions posted on the
wall:
• Initial your top 5 questions
Write down:
• 3 things you have heard from other people on why agile won't
work
• 3 things that make it hard to adopt agile in your org
• Discuss w/ your table
What you want to learn • How to get started.
• A better understanding of the PM role in an Agile project.
• Managing the life cycle with agile methodologies.
• How to plan an Agile project (estimating project milestones, duration, implementation date) when it is done in pieces.
• Feeding the beast…how to get information up to management (dashboards, progress, etc.)?
• What are some agile methods/practices that can be introduced in a traditionally waterfall organization for employee buy-in?
• How to sell clients on the idea of Short Planning Horizons?
• How to get Management buy-in?
• How to improve team efficiency
• Creating user stories. What level of detail?
• How to clearly identify customer needs
• Turning stories into tasks
• Techniques to drive out the requirements from users
• How to capture a user story that has lots of complex business rules
• How Agile methodology is going to help in creating better and clear Requirements and Use Cases
• How to add value to business quickly?
• How to get a handle on unpredictable requirements
• What to avoid, what to ensure that you do, how do you do it? How can you have the best chance for success?
• Applying Agile in a sustainment/support team (in concert - versus contrasting - with ITIL)
• Applying Agile within a team that has many POs
• Agile Estimating
• How do I use Agile in a legacy environment where design is somewhat restrictive and limited capabilities of the system.
• Testing in Agile (including Unit Tests)
• How to best tie requirements to test plans/test cases
Learning Outcomes
• Plan and execute an agile project.
• Explain the benefits of agile.
• List and teach someone else the major agile practices and their benefits.
– 1 Persona and it’s accompanying User Scenario • Keep technical detail out
• Minimize the steps
• Solve their problem completely
• Remember the user’s GOAL (Why?)
– (15 minutes)
• Review with your team
– (5 minutes)
Requirements Elicitation
• Show and Tell
• Discuss
Review
• User Stories
– As a [user] I want to [action] so that [goal]
– Who/What/Why or Why/Who/What
– Title; Sentence; Acceptance Tests
– Try to keep solution-ing out of it
• User Story Slicing
– Keep them as stories
• Iterative vs. Incremental
– Build your map horizontally
Silent Brainstorming
• Using silent brainstorming, generate a list of user stories.
• Remember: – I : Independent
– N : Negotiable (a single priority)
– V : Valuable (to a user)
– E : Estimable
– S : Small
– T : Testable
Finish Your Map
• Based on your vision, personas, user scenarios, and user stories, put your stories on your map.
Prioritize your stories
• Top to bottom
– Create a lane in your map that is 2 stories high.
– Taking turns, each person either:
• Takes a story from the pile and puts in the map based on the priority they think is important
• Re-prioritizes a story in the map
– Until all stories are prioritized and the team is in agreement
(5 minutes)
Estimating
• Simplified Planning Poker
(I don’t have enough cards for everyone)
• Rules:
– Read the story
– Brief discussion (cap at 30 sec per story)
– Estimate on 3
– Move into piles (1,2,3,4,5)
(10 minutes)
Inclusive Modelling
What not to do
• Large stories
– Not splitting *
• Incremental development
• Estimate in hours
• Estimate alone or w/o customers and team
• System stories as part of your velocity & planning measurements
• Cheat
WordPress sign-up
Each individual
• Wordpress.com - signup
• Create site & follow prompts
As a group:
• Pick one site
• Owner of that site, go to Users and invite users as "Administrators"
• Everyone go to yourgroupsite.wordpress.com and login
• You should all be able to blog here now and make changes.
Core Delivery Concepts
• Kanban
• Specification by Example
• Velocity
• Stand-ups
• Agile testing
• Definition of Done
Core Planning Concepts
• For each, answer these questions:
– What is it?
– Who does it?
– Why do it?
– How do you do it?
– Map it to one agile or lean principle
• 25 Minutes
– Research in pairs
– Each topic should be researched by > 1 pair
Time to Teach
• For each concept, teach us:
– What is it?
– Who does it?
– Why do it?
– How do you do it?
– Map it to one agile or lean principle
• 4 Minutes per concept
(strict time box)
VPM Setup
• Setup your:
– Kanban board (like in the example)
– Burn Down Chart
– Velocity Chart
(10 Minutes)
Other Delivery Concepts
• 3 Vital behaviours to successful projects
– Frequent delivery
– Customer Accessibility
– Co-located team dedicated to one project
• Minimizing WIP
– emphasizing kanban principles
• Continuous Integration & Deployment
– Build, Test, Deploy continuously
Iteration 1 – 30 minutes
• Is your site picked?
• Planning
– Define your definition of Done
– Choose and discuss as a team your first 3 stories
– If needed, create some quick diagrams
– Don’t forget testing
• Start
– Keep your board up to date ALWAYS
Iteration 1 – Standup
• Have your stand-up.
• Stay within the rules
• Limited/no discussion of issues.
End of Iteration 1
• Demo
• Update VPM boards:
– Velocity
– Burn Down/Up
Retrospective
• Norm Kerth’s Prime Directive: – “Regardless of what we discover, we understand
and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
• I know you were on project [X], how was that? – “It was great because…”
• “Next iteration I would do this differently…” – Vote on these
• Decide on an action for the top ‘one’ and commit to the change
What not to do
• not done
• testing phase
• working too far ahead on requirements
• incremental development
• working with large stories
• working on more than one project at a time
Conclusions
• Review questions the group wanted to have answered.
– Were your questions answered?
– Any new questions?
Conclusions
• I know you attended the #AgileInADay workshop, how was that?
– “It was great because…”
• “Next workshop I would like this to be done differently…”