User Stories - Rachel Davies
Philosophy, stories and lifecycle of agile covered as an introductory session.
Agile aims to satisfy the customer - this does not mean that it is somehow cheaper or needs less developers.
Rachel made a very interesting point that traditional requirements documents are based on the traditional model of knowledge transfer - a model which was exemplified in teaching with lectures where the expert can pass knowledge directly to a student (who will then retain it). The view is that knowledge can be poured out, captured, recorded and then delivered on to other people without a loss. This view has changed, with increasing education activities focussing on reflection, group activity and tacit knowledge. The same change could be seen in the shift from requirements capture to user stories.
User stories are a way to work with other people, and to encourage communication. If you haven't had a conversation about the contents of the cards then something has gone wrong - they are promises for discussions.
The Ron Jeffries three C's:
Card - Facilitate
Conversation - Discuss using agreed language
Confirmation - Acceptance Test
Traditional Form:
"As a <User Role> I need <Capability> so that <Business Benefit>"
It also helps when the story has a name.
Development Cycle:
Exploration -> Release Planning -> Iterations to Release -> Production
Create a roadmap of deployable releases - all iterations should be deployable but it may not be possible in the business case that it can be deployed each time.
Each iteration has the stories and features planned - generally estimated in story points. There is normally more detail in the plan for the closer iterations. At the end of each you review and refine the plan, adjusting and adding detail accordingly. However the release dates are always fixed.
Generally in an initial planning meeting the business sponsor will present the case, allowing the development team to ask questions. The development team can then go on to have a more detailed technical conversation.
Business people and developers must work together - and welcome changing requirements.
---
Steve Freeman - Test Driven Development
The motivation for the talk was to encourage people to go away and try it out.
So, why use TDD? - arguably because you end up with half the defects but similar productivity. It helps to give the confidence to get the job done, and you don't need to worry so much about side-effects.
" Write a test
" Make it pass
" Refactor
Tests are best named after what they will do for us and not the methods that they are testing.
Never stray far from the green bar. This ensures steady continual progress (real not illusory), focussing on one thing at a time. It also encourages neat, clean simple code and modular design.
Listen to the tests, analysis effort can be put into tests. Refactoring supports design aspect by removing duplication and helping to express intent.
Code is more reliable, needs less debugging - and shorter!
Encourages test-driven management.
---
Boris Gloger - Heartbeat Retrospectives to Amplify Team Effectiveness
The idea of a retrospective is to tell a tale - the history of the team or a project.
Why retrospectives? We would like to improve what we have done in the past.
Disappointment of expectations stops learning. Retrospectives need to occur after events to encourage learning.
6 step process
- security first
- collect facts
- ask: what went well?
- ask: what could be improved?
- who is in control?
- Prioritise activities
Security first: Prime directive - everyone has done the best job they can given their knowledge of the situation at the time. What happened was the only thing that could have happened.
Collect Facts: Create shared team history or story. Each person writes important event on post-it and adds to timeline on the wall, while briefly talking about it. Only tell about your own story when you put it up, but once it is up there it becomes a team event and part of the team story.
What went well? (Creates positivity)
What could be improved? (no manager enforcement, all ideas come from the team)
Who is in control? (who can make this happen? The team? The organisation?)
Prioritise activities: Create team backlog and impediment backlog. The latter is hard, but important to make visible. Important but hard to do and takes bravery.
Heartbeat retrospective can last 10 to 90 minutes. Use a dedicated room, not a project room, preferably in a secure environment that is not the team work area.
Some say project retrospectives should take at least 3 days - these are longer, more details as they cover a longer project in its entire history. They also try to create solutions. Heartbeat retrospectives are more designed for iterations.
Make conflicts visible, don't try to hide them. However, safety is built over time as the team is built. Hard to deal with highly charged situations in such a short time frame. Talk about things on wall and not about each others.
By telling the story you
