Agile: Better Teams and Better Planning

Agile techniques in practice at the UK's biggest startups.

Transcript

1. Agile: Better Teams and Better Planning Sam Phillips MagRails Conference - 14th October 2011
2. Planning is easy • 70% of you wanted to talk about agile planning... • Accurate planning for predictability is very easy. • It’s in the Scrum book!
3. Predictability vs Performance • What is the overall goal? • How can these be achieved in practice? • ... through understanding your organisation
4. • One of the UK’s fastest growing companies • Still feels like a start-up, fast-paced as any company you can name • Strong commercial drive, run on the numbers • No established project management framework • Super efficient development with Java and MSSQL • Informal, low-structure environment - looking for performance, not process
5. The same challenges as you? • ‘Productivity’ - a lot of people, sometimes achieving less than they could • ‘Projects’ - difficult slogs, sometimes never finished What we did: got better at teams What we did: got better at planning
6. Your product is your team. ...whether you’re a manager, developer, designer, whatever.
7. What size is a team? • Organisations and departments are often too big to be teams • An individual or a pair is smaller than a team • Merge groups together to create a team
8. Typical Hut Team • Typical Hut Team: • Project Manager/ Business Analyst • Tech Lead • 4-7 Developers/ Testers
9. Work together • Owned space is crucial, but it doesn’t have to be physical • Co-location is the best - even on a micro level • Back to back vs face to face • We weren’t afraid of moving around • If not, share an IRC channel, campfire room etc
10. Stay together • People are not interchangeable; a mature team is a system - keeping people together helped a lot • What’s better - the ‘best people’, thrown together to solve a problem, or the best team - a working system? • “A system is not a sum of its parts, but a product of its interactions” - Russ Ackoff
11. Stages of group development Storming Bruce Tuckman - 1965 Forming Norming Performing A group of individuals, often told what do to Boundary testing - conflict may be necessary People understand their and others’ fit within a team If achieved, self-managing and independent
12. Situational Leadership • Depending on a team’s own autonomy and experience different types of management are appropriate Paul Hersey - 1969 Supportive Behaviour Directive Behaviour Low High Low High Managing Coaching Mentoring Delegating New teams Self-organising teams
13. Give feedback • It’s the main way people improve • One-on-ones • Appraisals, objectives • All are mechanisms for feedback - tailor to your organisation. • Listen
14. Plan every day.
15. A standup meeting is a planning meeting • We were constantly reminded of the important of this meeting • Purpose is for the team to co-ordinate
17. Card wall • Match your wall to your process • Represent analysis as a separate step? • Take photos - historical perspective • Change as and when you need
20. One project, many plans • Planning is done at lots of levels - daily, per- project and with an overall product roadmap
21. Articulate your end goal • Of course this will change - that’s the point • Build a roadmap for 6 weeks as a point of reference • What is “done”?
22. Technical Planning • Evolve your architecture incrementally • Work out how much you’re biting off in a given phase • Run new code alongside older components
23. Cut scope to create phases • Work out how to validate your assumptions and build value quickly • Our first iteration on a project was 2-4 weeks, never longer. • Come up with phases - not just the old ‘phase 2’ trick • Subsequent phases were quicker
24. Estimation • When estimating a backlog, compare work to work to previous projects from the team - velocity, without the magic! • Translate into real dates - give target launch weeks up to 6 weeks in advance • Update estimates and let people know • We didn’t estimate individual technical tasks as monitoring felt like overkill
25. Information radiation • Measure the impact of the work you are doing - any way that you can • Good for a numbers organisation • Stick it on the wall!
26. Pro-active reporting • Produce a weekly report giving a red/ amber/green status for your project, with detailed narrative • Stakeholders will read, even in a low- structure organisation like The Hut Group • Good opportunity for you to reflect on the week
27. Push for feedback • Big demos are difficult - identify key players and get their feedback first. • Let people know you are waiting for them.
28. Thanks for listening! • Thanks to the MagRails team • Find me on twitter: @samsworldofno