- 14th October 2011 About me - Ruby chap, including being the original developer for OTB. In recent years, I’ve been “doing agile” - both with OTB and other startups as an agency technical director, and at The Hut Group Thanks to the MagRails guys for inviting me.
about agile planning... • Accurate planning for predictability is very easy. • It’s in the Scrum book! Why planning? I was looking a topics people wanted to cover - and planning was at the top (70%). But planning is easy - if you’re after predictability. The question suggests that Chapter 6 in the Scrum book has not worked for everybody :)
How can these be achieved in practice? • ... through understanding your organisation A lot of what I’m going to say is old hat management - Peopleware was published in 1987, The Goal in 1984. More recently - Google’s project Oxygen showed how they had incorrectly valued engineering talent over management skills. Here’s how we started out in my organisation.
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 Consistently in the top ten of The Sunday Times’ Tech Track 100 Founders both accountants - heavy reporting capability enables a culture focused on close monitoring Most startups are unstructured and don’t have a waterfall process in place - Scrum may feel heavyweight to them.
of people, sometimes achieving less than they could Hands up if you’ve ever been months into a project and said “What is the scope of this project? Why are we doing it?” This is ok because this is typical. • ‘Projects’ - difficult slogs, sometimes never finished What we did: got better at teams What we did: got better at planning A lot of this stuff is simpler than ‘full-blown agile’, but it was effective.
often too big to be teams • An individual or a pair is smaller than a team • Merge groups together to create a team I was assigned a couple of developers for our API, and a couple for operations and customer service - that was enough to make a team.
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 Different cultures will work at different tech - Setfire had IRC successfully (important when we split onto two floors) - but this never caught on at THG.
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 One senior dev is not the same as another senior dev Quote from Martin Rue, Ashley Moran - one of many on this subject, but a good one :) - got it from the #xpman IRC channel.
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 Just a model - not gospel. But if it’s true, how might we expect individuals to just do this?
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 The worst managers are laissez-faire - they feel they’re giving autonomy to a team that really lacks direction. A skilled manager aims to use as little control as necessary - to let individuals get on with it themselves. Give out tasks Give out objectives
One-on-ones • Appraisals, objectives • All are mechanisms for feedback - tailor to your organisation. • Listen Ask people about stuff - even if you’re not a manager, you have a duty of care to give feedback. I’d say it’s better to give feedback in a sub- optimal way than to not give it. If you wait to be great, you’ll never do it. Giving feedback is about listening - not an excuse to moan :)
others will be a constant continuum of planning and don’t need it. Standup - no point being strict as can be divisive. If it takes the team 30 minutes to co-ordinate, let it - but ask why.
column? Separated out technical tasks from stories - so could see where each tech task got us Size of story boxes depended on complexity - and done in pen so as to be easy to alter size
- that’s the point • Build a roadmap for 6 weeks as a point of reference • What is “done”? With this, you can easily see what will have to move if something more important comes up
how much you’re biting off in a given phase • Run new code alongside older components I haven’t said legacy - but even components a year old were being retired at THG
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 I got a rep as a scope cutter - but it meant we could deliver things earlier. Strike a balance with your stakeholders, and make sure you really do deliver another phase and another It sounds like basic BA and PM, but people don’t do it - I’ve sat with PMs who are happily adding stuff to scope! Quicker was difficult because of our tech and legacy (again, common) - slower was project suicide.
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 Estimates are the only way that you can decide whether or not a piece of work can happen - pushing back often means no investment. Are there any typical weeks? Bank holidays, sickness etc - ask the team when things will actually drop
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 Not sure they are? Don’t attach it to the email :)
key players and get their feedback first. • Let people know you are waiting for them. Essentially product owners - trick them into it! Again - important in a low-structure environment. BI Solider - left on your desk if the BI team is waiting for your feedback on a piece of work they’ve done for you! :)
hcrane
sue445
yusukeshimizu
ratsbane666
kevinrobot34
mhidaka
shonansurvivors
ueokande
minorun365
recruitengineers
hacomono
taka_aki
shpigford
stephaniewalter
andyhume
brettharned
bcantrill
jacobian
colly
keithpitt
3n
marcelosomers
addyosmani
destraynor
