Hello tired Jira manager. Hello never-listened-to scrum master. Hello ignored project manager. Welcome to the world of project management. Did you read all the articles about creating a risk log, managing tasks or using Excel to generate Gantt-charts?
Let’s talk about examples from real-life projects. Product owners not attending sprint reviews. Scrum teams seating on three different floors without a single conference room to meet. Conference calls when you can barely hear your client. Busy teams that never have time for retrospectives. Half an hour standup meetings.
Your client (in this article “a client” means a product owner) assured that he is a big fan of agility. He attended the first demonstration (well, it was nothing to show, but you know, this was the first one). Then he was late. Then he asked to move the ritual by one day. Has it ever happened to you?
How is it possible that someone who usually pays for your work is not interested in the results? Well. If your client is not attending demonstrations then either your project is unimportant or your demonstrations suck. Usually you can’t do much if you project is unimportant. Let’s focus on the latter.
Think about your past demonstrations. Were they really attractive for your client? Was your client getting a condensed summary of what happened during the last sprint? Was he satisfied?
Here are some tips and ideas from my experience on how to make your demonstrations better:
Have you ever heard about “the demo effect”? The fact of something working perfectly always except when demonstrated for an audience. There is a dead simple solution for that. Make a trial run before the real demonstration.
Perform a fake-presentation one day before the real thing. If your sprints are super short do it a few hours before. This allows you to check whether the product components your team was working on are ready. This is a perfect time to spot missing features.
Check your props. Spend some time on preparations. Double check all scenarios. It’s a nightmare when the client sees a stressed developer frantically typing the password on the shared screen. Use more devices (browser tabs, mobile phones, whatever). Have them already prepared to present a specific scenario.
Balance your demonstrations
During a demonstration the team tends to focus on the topics that consumed most of their sprint-time. Whereas the time spend on development does not equal the business value for your client. Don’t elaborate 20 minutes on a low-level refactor just because the team spent 80 hours working on that. Your client will be more than happy to hear that the app startup is shorter by 1.5 second and a new application launch icon was added. Even though it took half an hour to implement it.
Your team will understand it better after a pre-demo. People often realize that some parts of the demonstration are not as interesting as they thought.
Have one speaker
It is a common practice to ask all the team members to present what they achieved. When many people perform a presentation it is really hard to make it interesting, focused, short and easy to follow. If you are lucky to have your client on-site, you speak the same language and lead a small team then sure — do it. In other cases it is usually better to choose one speaker to present everything.
It could be you to present all but it doesn’t have to. Testers are proven to perform great demos. They are good at (and not bored with) following a scenario in an efficient way. They also know how to automate the boring/repetitive parts.
Record your demonstrations
Your client works in a different timezone and has to wake up at 7am to attend a demonstration? Sounds hard.
Record a 15 minutes video summing up everything your team did. As always remember to briefly describe what was planned, present what was delivered and give a short insight on the plan for the upcoming sprint.
Keep it short
If you manage a single-stream project (a website, mobile application for 1–2 platforms or so) then fifteen minutes is really enough to present what was delivered in two weeks. If your project is more complex and your sprints are longer you can waste an hour of your client’s time but really not more. In my the most extreme example — 25 people building an operating system and a set of applications in a six-weeks-long sprints the demos took up to one hour.
How to do it? Do pre-demos, balance your presentations and have only one speaker. That’s usually enough.
— I can’t understand my client
First — before complaining about your client’s accent double check if your English is any better. After that you can:
Buy a microphone and ship it directly to your client. Shitty microphone is the most common reason of a bad audio quality.
Stop using build-in laptop speakers. Buy Jabra (or something similar). Or use headphones. In one of the most radical cases I was leading a team of four and we were creating four separate Google Hangouts sessions. Each of us used his own stream. Of course only one microphone was un-muted.
Triple check the internet connection on both ends. The best way to do that is to join one of the meetings from a third location. This also gives you a perspective on how your client hears your team. If you are sure that it’s all good with your bandwidth ask your client to connect from another location. It happened to me that one of my clients had a better calling abilities at home than at the office.
— I am running a fixed-price project
Fixed-price project clients are not easy to convince to attend a demonstration. What they usually believe is everything is written down in project requirements and they need to simply wait for the final result. We all know that there is nothing more untrue than that in a software development world.
Push the demonstration down your client throat. Apply all the points mentioned above. Your demonstrations has to be perfect. And a very nasty trick at the end — call it “project status” instead.
— I am at the beginning of the project and there is nothing to present :(
You want to tell me that you did nothing in two weeks? Yes, I understand that there are no designs yet. I know that the scope is blurry. I know your client is still thinking whether he wants a new-Instagram or a new-Tinder. And I really understand that it is not easy to present “setting up the environment”.
But there is always something to present. In one of my projects after the very first sprint (5 days long) an application able to… display a splash screen was presented. Sounds silly? It wasn’t. This application had its launch icon, showed the client’s logo and proved that our continuous-integration system was working. After the demonstration a copy of this great application was installed on a client’s phone and we taught him how to install updates. On the second demonstration he was able to play with a login screen on his own device.
— I am in the last stage of the project, only bugs are being solved :(
Your beautifully performing development team of eight very motivated people slowly converts into a frustrated group of three engineers stuck in an endless bug-fixing project?
Most of the (successful) projects convert from an active development stage into a maintenance. These are very different stages and so different practices should be applied. This is especially difficult as there is fine line between them. Even if there is a formal milestone, these phases usually overlaps.
Once your project comes to this stage stop doing demonstrations. Yes, just stop doing it. You are the one to shape project rituals. Don’t just sit there and look as you demonstrations slowly deplete.
It is perfectly OK to say that the development stage is done and we are moving to support where instead of demonstrations only bug statistics are presented. Don’t paint the grass in green, and don’t do demonstrations forcefully when it has no value.
Finally — think!
I will be more than happy to hear that some of my ideas were useful for you. However please note some of these hints could make your situation even worse. Each project is different and there are no golden-rules.
Keep an eye on you client. Try to find a real cause of his behavior. Take an honest conversion and understand his needs. Both business and personal if it’s possible. Perform frequent but short retrospectives to improve your project management process. Shape the environment. Think and react.
This is a digital PM’s blog. I am not an architect nor a Plant Manager. Each time I use the word “project” it refers to a complex collaborative activity with minimal repeatability, where requirements are hard to specify and workload difficult to estimate. Many times it is more expensive to describe all requirements precisely than to deliver a draft of an expected solution.