Agility is the answer: Woes of a web warrior 3
This blog post is more than 4 years old, so the content may be out of date.
So, you want a new website? What do you think the odds are of getting a site that you're happy with…a near certainty? 1 in 2? 1 in 6? I can't say that I have all the answers, but I do have some stories to tell - and I hope these tales will help you beat the odds.
So, why did I write this series? I'll admit it is partly a rant, and partly a sales gimmick…On the one hand these tales illustrate some of the risks of building websites. On the other hand, I am a busy guy, I can't help everyone, and I do like to see websites built right, even when I'm not involved. After all, I never know if I might end up using them! Whether you're working with me or not, I hope these tales will help you avoid some of the pitfalls that await even the wary.
- "We know best"
- If it's worth doing once, it's worth doing again and again and again
- Agility is the answer
- "The Grid"
- I can haz environments?
Agility is the answer: a tale of two screwballs rolled into one.
Client comes to the company, asks for a quote for a project. Company sends an expert to do some analysis, expert comes up with an approach, gives an estimate and rough plan. Client says it's too much. Company responds OK, let's do it agilely. Client comes back OK, but lets skip the setup phase of the project, as we're doing it agilely.
So I come in, day 1. Leading a team of 5 other people. Actually it's the first time I've ever really lead a team like this. Or a project like this. Usually I'd start a project by setting up a code repo, setting up environments, thinking about deployment. I'd also recently started getting properly into fully automated deployment, CI, and automated tests at this stage, so I'm *seriously* thinking about these issues now. So, scenario: I'm in the client's offices, I've got 5 team members with me, the client has a backlog, we're getting a quick brief then pretty much straight into sprint-planning. Only we don't have any dev environments, nor any tools set up, or anything more than a high-level idea of the project goals…yet here we are, trying to *estimate* the next sprint. Which starts tomorrow.
So we make it through estimation, we turn up the next day…and I'm desperately trying to race to get a code repository setup, to get environments built, to think about CI and test, and to think about how we're going to architect this site. I've got a vague idea, from my haphazard guesses the day before, but no real certainty. But I've got a team of 5 people who will be twiddling their thumbs until *I* make a decision, and can't get started until *I* get things set up (because I'm the only person with the knowledge and experience to do this). Rushing things? BOY am I rushing things.
So I race ahead. I make decisions. I set up the repo. I choose our architectural approach. I am - just about - one step ahead of my team members, trying my best not to become an impediment to their tasks. But I have no time to validate my hypotheses on the architectural approach, and no time to support my team with any questions they have along the way.
It shouldn't come as any real surprise when towards the end of that week, I realise the major architectural decision I made earlier on (using OG over drupal multi-site) wasn't the best approach, and that it will massively increase the development time.
So what do I do? I go to the scrum-master/project-manager on the project, and explain what I've found. The cost is that most of the work the team have done in the week is focused on OG integration, and so can't be reused if we switch to multisite.
For want of a setup phase - a week for me (and perhaps one other developer) to prepare the repo and plan the architecture - we wasted a week of effort of 5 more developers.
If that were the end of it, that would be a lesson in itself. However, when I took this issue to the scrum master, he said that we can't change the sprint plan mid-sprint. That we should press on and see what we can achieve within the context of the original sprint plan. See which of the sprint goals we can achieve, without changing architecture. And this is the first time I've lead a project like this. I head the confident voice of the scrum master saying we should do x, y, z, and so I don't disagree. And by the end of the three week sprint, we were in the same boat, and had wasted three weeks instead of one.
Unfortunately, this was part of a wider and perhaps more treacherous screwup. The scrum master didn't work for the same company as me and the other developers. He worked for another company. Who happened to be a rival. Which happened also to be a supplier to the client. In fact, we'd probably won the project over the company he worked for. But the client thought that appointing a scrum master who worked for a different company might add a layer of independence, a layer of oversight.
So when, at the end of week 1, I had spoken to the scrum master about the issues I'd discovered, he hadn't communicated those to the client. He had no interest to communicate this. There wasn't exactly a great incentive for him to facilitate the project to success, quite the opposite. All in all, the project ticked over, and in the end, all companies ended up bickering over contracts. In the end, something was delivered, and no-one was really happy. I don't think the companies involved ever ended up working with each other again.
So what did I take away from this?
Firstly: do not skip a setup phase. Called it "inception" (such as in the RUP methodology), call it a setup phase with a stage boundary (as you'd use in Prince 2), call it a setup sprint and treat it as agile. A setup phase (with a small efficient setup team) will be the most effective way to prepare to start technical development.
Secondly: Be very wary of putting rival companies on the same project, and especially of making one dependent on the other. Whilst on the one hand, it might appear you're hedging your bets and adding oversight, you might be creating incentive for the project to fail.