Jane Dallaway

Jane Dallaway

Jane Dallaway  //  Data loving developer/leader/product shaper, storyline curator/creator, life-long learner, photographer, dog owner, reader, crafter, gardener and occasional snowboarder

This blog contains all sorts of odds and ends, from event reviews, stuff about my storyline project, bits of craft, through thoughts on learning, to photography stuff, and general inspiration things. It's a bit all over the place with no real theme, but then so am I!

Email: jane @ dallaway.com
Also at:    

Filed under

agile

See all posts on posterous with this tag »
 
Jul 25 2011

Scrum guide 2011 - The Definitive guide to scrum: the rules of the game

I've been working with a Scrum based project for a few months now, and in preparation read Planning Extreme Programming (XP) (as I'm overseeing from a process/responsibilitiy angle rather than actively developing on it) which I reviewed at the time as being

Well written, easy to follow book with great examples. Lots of ideas to try and hints and tips of common pain points. Have been adapting our current agile-ish process based on my readings so far, and will continue to do so to ensure we have a process that works for out team/product.

I stumbled across The Scrum Guide last week, and have just spent the past hour or so reading it and found it a really valuable use of my time.  It is a well-written, simple and straightforward guide and well worth a read, especially as it manages to convey a lot of information in a comparably short document (just 17 pages in the English version). I've just sent it to the rest of the team and heavily suggested that they read it too.

Filed under  //  agile  

Comments (0)

 
Jul 21 2008

Post-Implementation/Post-Project Reviews

In my almost 15 years of development, I've found little more beneficial than a well run Post-Implementation Review meeting. I find them a great to way to learn, improve and ensure that the next project goes more smoothly than the one before.

What is a Post-Implementation/Post-Project Review?


It is a meeting held at the end of a project at which people who have contributed to the project as a whole get an opportunity to discuss the highs and lows of the project.

My preparation normally involves thinking back over the course of the project and thinking about:

  • what went well?
  • what didn't go so well?
  • what we could do better next time and what lessons we can learn
  • How well the project was analysed and specified
  • how well the project was managed
  • how well the testing phase went - bugs found in testing vs UAT vs post-live
  • how well the handover to support went
  • how well the original time estimates reflected reality
  • how well specified the infrastructure was - were the original estimates on page impressions etc valid

The most recent one I attended was run in the order of the project, so feedback was made first against the Sales process, then the Analysis process etc. This worked pretty well, but did mean that the last few stages of the project were rushed to ensure that the meeting finished on time. Alternatives include asking the "What went well?", "What didn't go well?" questions of every person in the room. This ensures that everyone gets their say but does involve preparation on behalf of every attendee (no bad thing).

Who should be there?


For me, the ideal meeting should include everyone who has been involved with the project, from start to finish - in some cases this could be a lot of people but every function should be represented - so definitely Sales, Analysts, Project Managers, Developers, Support and Systems. Every person should have an equal opportunity to speak.

When should it happen?


Usually, after the project has gone live and been handed over into a support phase. In some cases a project can last too long, and if the project is scheduled to take more than 6 months, its probably worth having 6 monthly review meetings to ensure that key learnings aren't forgotten, or that subsequent projects can learn and improve quickly. These shouldn't replace the Post Implementation Review but should supplement it.

What should happen afterwards?


The final part of the meeting should be a quick review of the "What went well?" items, and of the "Key learnings". Someone should be tasked with producing a document which should then be circulated outlining the key learnings from the project, and also the highs - the lows should be kept within the team and learnt from but not circulated - it shouldn't be a shaming exercise but should be a great motivator. Any individuals charged with process review, or implementing changes to current/ongoing projects should be informed of the key learnings to ensure these learnings are escalated and implemented as quickly as possible.
Filed under  //  agile  

Comments (0)

 
Jun 24 2005

Agile Development

This morning I attended an agile development seminar in London hosted by Agitar Software and Exoftware and featuring Kent Beck and Mary Poppendieck. I'm pleased to say I've taken away some great ideas from all of the speakers.

Kent Beck concentrated on developer testing (a podcast from a previous talk can be found here and a webcast here). He has a great view on quality - quality is an instantaneous measure, it isn't an ongoing measure. Instead he prefers the idea of the health of the software - how does it perform under stress and respond to changes in stress (increased load, increased usage, team changes, requirements change, business focus change etc). Going a stage further, if individuals within a team can't respond to stress well, then their software won't either.

Agitar demonstrated two of their tools - Agitator and Dashboard - both of which are very java focussed, but gave a few ideas to take away. One great quote was "Good QA people are devious - in a good way".

Mary Poppendieck talked about lean software development. How lessons can be learnt from the comparison with the lean manufacturing processes introduced by companies like Toyota. She has 7 principles, and obviously explained those. I felt that she was a bit rushed, and didn't really get enough time for her material. I'd be interested to hear/read more, so maybe I'll take a look at her book at some point. I was particularly interested in hearing about one of the vicious circles relating to QA testing. So, the problem is that the QA team are overloaded with things to test, the result is that QA aren't available to look at development code early, which results in development getting delayed feedback (and potentially making a problem worse), which results in there being more bugs introduced, which results in QA having more releases to test...

Exoftware talked about user stories, and it was interesting to see the detail they go to, the fact that they produce imaginer users for the various roles in the system, and role play to work out the requirements - this seemed like a great, and very simple idea. He pointed out that a good use story should be Independent, Negotiable, Valuable, Estimatable, Small and Testable (INVEST for those who like mnemonics). Some of their presentations are available online.

Filed under  //  Development   agile  

Comments (0)