Quality is a choice: the case of the Next Generation Apps

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

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

Continue reading

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

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.

Continue reading

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