In meetings between IT and the business, all too often we see a clear divide with the business sitting on one side of the table, and IT on the other. This immediately turns any meeting into an “us vs them” confrontation. Be different. Go and sit right next to the business guy. This may lead to a fun game of musical chairs as they get confused at you entering their territory and try and run away – follow. Eventually, we will have people talking whilst sitting next to one another, on the same side. Better yet, get rid of the table! Go to a break out area, or even the local park (on the 3 days of British summer that we get in this country 🙂 ).
Speaking of the business, there can only be ONE product owner, that person needs to be heavily involved in the project (20% of their time should be spent pitching in) – they should attend stand ups, prioritise the tasks on the backlog. They are the ONLY person in the WHOLE WORLD who can mess with that backlog. Everyone else – hands off! If you’re in the unfortunate position of having more than one person who considers themselves to be the product owner, this is a sticky situation as everyone will inevitably disagree. You’ll be trying to get answers and each one will have their own view of the world. In this case, they need to all be sat in a room and asked the questions in front of one another, so that they can argue it out among themselves until you get a straight answer!
Even better, you should have one on site customer, rather than a product owner from IT. The person who gives feedback should be the person who is actually going to use the application. If the product owner has to go to the customer to get the question answered in the first place, that will just take more time, and is inefficient. The person who will be using the application should get the chance to play around with it at each iteration.
When planning a sprint, it is imperative that you meet your sprint goals to make the business trust you. Once you’ve accepted a story into your sprint, take it as though you’re under oath to complete it. Never take in more than 90% of your capacity into any sprint, this leaves time to support your QA/fix bugs if necessary. The more you deliver on your promises, the more weight your word carries. So then the next time Mr Important and Ms Super Important come along and ask to pull a developer out for 2-3 days to work on this new “urgent requirement”, when you say “this will cause us to not deliver on our goals”, this will hopefully be taken seriously rather than met with a scoff and a “oh yeah? well you don’t anyway”.
The Project Manager
Project managers are required in an Agile world – to deliver things like status reports, sort out budgets. There’s a misconception that Agile seeks to get rid of project managers, but there’s not an Agile team in the world that wants to take on securing a budget!
Project managers all have the same 3 concerns (passed on from the business):
- TIME – how long will it take to produce this piece of software?
- MONEY – how much will it cost me to produce?
- SCOPE – what will be included in this
These must be defined at the outset of the project, and so help you if you don’t manage to stick to it (which no one ever does).
Agile likes to change this up. A lot. In an Agile world, this is how the conversation goes:
Business: How long will it take to produce this piece of software?
PM: Give me a date. I guarantee we will release something on that date.
Business: How much will it cost me to produce?
PM: How many people do you want working on it? It’s their wages until the date specified above
Business: What will be included in this release?
PM: Not a clue! (remember that brutal honesty we were talking about?) However, we will keep you involved at every stage so that you can choose the priority of stuff going in, and we will get as many of those in as we can. We can commit to some “big rocks” but the finer detail will need some backlog refinement from you/the product owner and can’t be guaranteed.
Trying to estimate your entire backlog is like trying to predict the future – you WILL fail. What needs to be made clear is that we can fix two of those three – we can give you a date, and cost, but cannot exactly define the scope.
In this way, the product owner is involved in the process from day 1. In an Agile world, the product is developed in vertical slices (more on this later) and the product owner is shown each part as it goes along (usually every sprint if not sooner, to get super quick feedback which is what Agile is all about). They can then have a play with the software. When they’re given it, make sure you give them targets/acceptance criteria for what to do with it or they will just smile and nod and say it’s fine until it’s actually time to release. If the users are only involved at the end of a development cycle, you are not getting the most out of them.
When showing users what you’ve done so far, do it as soon as you have a full vertical slice working, however basic it looks. For example, whilst developing a UI, show them a very basic wireframe (check out mockupscreens.com) that looks like it’s been scribbled onto the back of a napkin, rather than a beautifully coloured powerpoint mock up slide. This is because the latter won’t get you good feedback:
- they won’t like the colours/details (they’ll complain even though that’s not what we want to show them)
- they’ll be scared to say anything because of how much work seems to have gone into it.
- they’ll think it’s the finished product, and ask for the finished product, they won’t understand why there’s so much more time to go.
- The Users will be much happier giving honest feedback if it looks like it’s easy to change.
Users should record any bugs directly into the bug tracking system (JIRA/Rally/…). This has two key benefits:
- The bug is recorded exactly as the user sees it – there is nothing “lost in translation” between them reporting it in an email and someone on the IT side summarising their findings in a bug tracker. Developers then actually see and fix what the user is concerned about.
- When the user sees the bug getting fixed, they see progress and feel involved in the process. The more a person feels a sense of ownership of the software, the more invested they become in it. This way, when the final product is delivered to them, it becomes less about them saying “hey, there’s a bug in the system! Fix it now!” and more about them saying “We seem to have found a bug that we’d missed before. Please fix it when you can”
Speaking of bugs, the best time to resolve a bug is right after you’ve written the code and it’s still fresh in your memory. Therefore, minor bugs should be taken back into the sprint straightaway and resolved (again, never allocate 100% of your time in a sprint, so that you leave some time for things like bug fixing). Major bugs should be added to the product backlog and prioritised as normal. The WORST thing you can do is have a separate bug list. The users need to know that this is part of the work that needs to be done, and to know that they need to be prioritised against the other stories. At the end of the day, work is work, and you are the ones who will be working on it.
In general, build bridges between your development team and everyone else who’s involved, including the DBAs, the UI designers, etc. Make THEM feel involved in the process, again, give them a sense of ownership and they will want to help you reach your goal. Ask their opinion on different aspects of the application, and make a note of it. If someone feels like they’re being listened to, they’ll be more willing to help you because it’s become their interest too. And if bridges need building – remember that food brings people together in a way that nothing else can :). Buy a pizza, get everyone in a room and have a chat. (Of course, in a truly Agile way of working these people will all be a part of your team and all silos will have vanished, but we aren’t talking about a Utopia just yet 🙂 )
Disclaimer: Again much of the material above is based on talks by Allen Holub and Phil Japikse at the SDD conference in London