I just want to share some thoughts about where agile (scrum, specifically) has worked and where it hasn’t worked in my organisation. I don’t think I’ve discovered anything wrong with Scrum itself (I’d far rather be in an Agile team than in a Waterfall one any day) but more that there can be issues where the organisation outside of the dev team haven’t fully bought in to the concept.
The background is this. 2+ years ago the organisation decides to re-develop the core software product. The CTO initiates several changes, the key ones being adoption of scrum and adoption of new language/platform in RubyOnRails.
This is a cultural change for everyone. CTO has spent time explaining agile methodology at board level and the board appear to have bought into it. Development team also spend time getting up to speed with scrum, rails and TDD, first on a test project then on the real project.
Product Ownership is an issue from day 1. Ownership goes back and forth several times over the life of the project, between board, senior operational staff, CTO, appointed project team etc.
Again we go through several approaches to user stories. We start with the idea of collecting user stories from outside development, but it’s hard to get people to give us user stories for what the existing product does, they only think about the new features the new product might include. In the end we fall back on the pragmatic approach of writing most (though not all) of the user stories ourselves.
For most of the life of the project (the run up to launch dates excepted) it’s hard to get the part of the organisation outside of I.T. to get involved in what we’re doing. There’s little or no attendance at sprint reviews above those people that must be there. It’s rare that anyone wants to find out how the new product works, how it meets the organisations needs, what it looks like, or what it’s like to use it. There’s generally a reluctance from the rest of the organisation to spare time even for formally organised reviews, acceptance tests and so on.
About two-thirds the way through the project we’re aiming to launch limited functionality to one key client. There’s a fixed deadline for this, and as the time approaches it becomes more and more difficult to see how we can cope with the complexity of what we need to do within the fixed two-week sprint cycle. The complexity increases because people are now finally looking at the product and finding fault with it. In essence, we had too much to do, and should have really moved the deadline. Since that was not an option we abandoned the scrum process and on a day-by-day basis updated check-lists with new tasks and tasks done till we launched.
(More about what happened here )
Then we reverted to scrum.
So, getting on for 21 months after the first changes were initiated, it becomes apparent that the board is very keen to launch, very soon. Again, we’re given a fixed time-frame. We (dev team) spend a couple of days fleshing out the things that need to be done, debating approaches to this and that, debating what compromises can be made to meet the fixed launch date. In the end we realise that we’re again in the realms of complex, team-generated tasks. (we know that we need to load test, no user story we’re given has has told us that). It seems artificial to try and shoehorn these task lists into self-generated user stories, so again we abandon the scrum process. Because we essentially made a small waterfall project at this stage, our estimates failed to take everything into account. Also the complexity increased because again people started looking at the product, and requested bug fixes, new features and cosmetic changes. And the deadline slipped.
And it stayed that way for nearly many months after the main product launch. Only now, following pressure from the dev team, are we using agile methods again within the team, and getting the agile message out to the rest of the organisation.
Summing up the issues:
- The business wanted deliverables on a waterfall basis, i.e. two releases, both with a fixed deadline.
- Because the product was not delivered incrementally, it was only as our two deadlines approached that the dev team got any feedback about the product.
- The team implemented scrum as best they could, given that the rest of the organisation didn’t really buy in.
- The Dev Team might possibly have made things easier on themselves by forcing an approach where the existing system was replaced incrementally, perhaps going for an SOA approach, but that option has only become apparent with hindsight (and it could have raised a whole different set of issues).
So, apologies for rambling on a bit. If you’ve got this far, I’d be very interested in your comments.
