Over the last year I’ve had the privilege of overseeing the development of the next generation of mobile apps (iOS and Android) for the major commercial radio brands in the UK. The most amazing thing about this experience was the priorities – UX&D was #1 priority – something I’ve never had before.
Continue reading
Category Archives: Experience
Specialists are a Pain
Specialists are very useful. They are also a pain. It is great to have the experts around when we need them. But specialists are also add painful management overhead. I accept I have to do it but I wish I didn’t.
I’m going to look at three situations where I’ve had to deal with specialists and explain what I did:
- Drowning in specialists
- Front / Back end developers
- Part time external specialists
It is ALL Number One Priority / It is ALL Must Have. Not true!
If the customer claims everything on the product backlog is top priority, and by implication must have, then you’ve a bit of an education job ahead of you. You have to get the customer to the point where only one thing is top priority and even “must haves” are sorted into a priority order. There is a good chance some of those “must haves” turn into “would like to have” and in time disappear.
Continue reading
Everybody on your new team says they know Agile. Don’t believe it
Early in my Agile career I was the only person on my team who knew anything about Agile. Now everybody claims to know Agile and/or to have Agile experience. Certainly this has been true for most people on my last couple of teams. My advice to you is – don’t believe a word of it. Assume they know nothing.
Continue reading
Brakes let you go faster
Perhaps counter intuitively brakes let you drive fast. Without the brakes we would drive really, really slowly. I believe the same is true of automated tests. Something that looks like it should make you go slower actually lets you deliver code faster. As long as you’re doing the right tests.
Continue reading
No space to co-locate team – think again
I knew I had a big problem when I walked into the new programme space and found 18 desks. 18 wasn’t enough. I predicted I would have about 35 people on the team and I wanted them together. Co-location is so important to me that I will always challenge the assumption of “there is no space”. And I have found there are lots of things I can do to get my team together.
Continue reading
Avoid the Refactoring Branch of Doom
Sometimes I make mistakes. One of them was when I commissioned what I now affectionately call the Refactoring Branch of Doom. Doomed because it was never ending. The refactor was too big and, because it was done in a branch away from the main code base, the refactoring guys never caught up with the main development team. So I canned the doomed refactoring initiative and we did it a different way. One that worked.
Continue reading
User Story Dependencies are more Apparent than Real
What do I do when a User Story is dependent on another? Well, the most important thing is, to quote the Hitch Hiker’s guide to the Galaxy, “Don’t Panic!”.
I believe dependencies between User Stories are often over played. Sure there are dependencies but often these don’t require any particular management. But even more common are invented dependencies, i.e. dependencies that are more apparent than real. This means dependencies for me are a bit a of requirements smell, i.e. something to be worried about.
Continue reading
Reporting Percentage Complete on an Agile Project
What do you do when management asks for a percentage complete on an Agile project? The flippant answer is “tell them the percentage complete”. Agilists reject percentage complete when reporting on low level stuff. But for the project as a whole you can get quite an interesting metric, one that is based on real data, so why not calculate and share it.
Three Ways to Control Scope in an Agile Programme
I both embrace change and also fight like crazy to reduce scope creep. On my current programme I use three main techniques to control scope: Programme Vision, Release Goal, and Requirements Trade-off. In different ways all of these put the business in control of what is in/out of scope. But they all help me stay within budget and time constraints.
Continue reading