Insanity: doing the same thing over and over again and expecting different results. Albert Einstein
I recently finished another agile development project and we ran some really great retrospectives over the 9 months, along with a thorough review at the end. We captured lots of data and feedback and I decided to pick out the best and publish them in the hope of not making the same mistakes in future.
Arranged in no particular order.
For everyone
Deliver to production early and often Ideally your first version of the software should be in a production environment within a couple of weeks of a project kicking off to iron out those deployment pain points. Even if the app does nothing.
Always look to assign tasks to an unlikely first choice actively grow your T-Shaped skills for long term team productivity.
Working remotely is hard whatever anyone says about VOIP, teleconferencing, cloud platforms and the latest tool remote work is no substitute for working in person. We estimated it took 4-6 weeks longer for those working offshore to become productive and established in the team and there is a noticeable tax on everyone else. Expect to spend lots of time on the phone/screen sharing, especially in the first 8-10 weeks. On-boarding into the team takes significant investment from everyone. I measured it for one week and around up to 35% of a teams time can be spent on supporting offshore workers.
Do estimation as a team and have everyone write notes on the story We found it kept pace and engagement and the detail already there at time of implementation was far greater.
Value open and honest communication Most people need to hear about their weaknesses as well as strengths to get better (but don’t be an a-hole about it)!
Development
Mob programming early on If your team is unfamiliar, inexperienced in some way, or you just want to establish a good development culture then invest early on in a few afternoons all devs working with one computer. We found it can really level everyone up. Whether you carry it on after the first few weeks is up to you but we found a couple of pairing sessions a week throughout worked well.
Everything in your database should be under source control and continuously delivered as part of every release No excuses, it always causes issues if you don’t do it.
Leverage open source tools Don’t reinvent the wheel. This time round we used retry framework Polly, job scheduler Hangfire.IO, some OSS Http caching tooling for asp.net (which is OSS itself now), lots of UI frameworks and (shameless plug for one of my personal OSS libraries) LazyCache. Commit code back wherever you can.
NHibernate is poorly documented It caused us issues because experienced .net devs who were new to NH took a long time to stop building subtle bugs into the app. Entity Framework may have it’s own gremlins but the docs are much, much better.
The closer the developers worked with end users the better the app became You should aim to meet your users on a regular basis.
Watch out for premature optimisation Especially in architecture. A quick and dirty solution often turn out to work out just great. And you can always throw it away later.
Testing
Great unit tests allowed allow us to completely rewrite a large section of critical code Meaning a really scary rewrite was fast simple and painless.
Work hard to deliver to test throughout the sprint dropping all the code into test at the end of the sprint is a team productivity killer.
Get as much real data into the system as soon as possible Until you get real world data in it you haven’t tested it. Real people and systems do weird stuff you just don’t expect.
Invest in your test infrastructure early because the sooner you do the less it costs to build and sooner the payback starts coming.
Don’t just rely on e2e/acceptance testing Just because you have some full system tests don’t skip out on unit and integration tests. These give you faster feedback, are always more reliable, and give you the confidence to refactor it when you inevitably forget how it worked (usually the very next day).
Testing environments need love Having a dedicated place you can give someone to try and break your app means fewer bugs in production.
Integration
Systems integration is hard It always seems to take longer than you expect because system A and system B never quite line up as expected and that integration tool is not quite as its glossy promo page made it seem.
Systems integration is even harder to convey to others The complexity and current state of a systems integration project is really hard to comprehend outside the technical team. You can never have too many pretty dashboards, too much logging and you should plan to build a comprehensive system status page.
Planning and process
Metrics and data on team progress are important Allocate time to collecting data on the team so you can make informed decisions. Retrospectives become opinionated and shouty guessing games without then data to base decisions on. Done daily it costs very little to collect….
…A brief daily progress report is valuable Ideally delivered before a daily stand up - we found an simple email of the burn down chart worked well.
Regular backlog management sessions Medium/long term planning shouldn’t be ignored just because you are ‘agile’.
Estimation formula should account for 20% contingency We measured our estimation over time and +-20% was about right. Measure and adapt, it is ok if yours is different but always account for some. Vary your retrospectives to keep them interesting and ensure you continually improve.
Identify blockers daily at standup And assign someone to report tackle and report back.
Avoid single man dependencies because everyone goes on holiday at some point!
Further reading
And finally some further ‘reading’ if you were keen enough to read to the end! Agile is Dead: by Dave Thomas
And lastly… Thanks to deviantart for the image used above.