Demonstrating A Platform

Demonstrating a platform can be difficult.  When you reach the end of a sprint there is a great desire to show off what you have achieved over the period.  I have made the mistake in the past of rushing into an unstructured demonstration of the features and functionality.  This can lack direction and become confusing to the product owner/stakeholders.

Like so many things in life the sprint review is a sales excercise.  You are selling the base product and your scrum team’s achievements over the sprint to gain sign off so that you can move on to new user stories.

Plan the demo
Plan what you are going to show and in what order you will show it.  Think about the questions that you would ask if someone was demonstrating to you.  Prepare answers for those questions.

Think about your audience
Who are you running the domonstration for?  Can you see any obvious issues for those people that you can pre-propose a solution for?  What do your audience want to see, is it features, reliability, intutitiveness.  Sculpt your demonstration to cover these factors.

Pre-load content
No platform looks good without content.  The first bite is always with the eye.  No matter how good the functionality if the audience doesn’t like the way it looks they will not be able to see past the skin.

Pre loading test data is a great idea, but know your audience.  I loaded some copy for one client using Lorum Ipsom…their only comment…”Can we have our version in English?”

Most importantly pre-load enough usable data to effectively test the site.  Construct your data requirements around the demo plan and what you hope to achieve.  Make it look ‘full’.

Back up plan
Test your demo before you go ahead and show it so that you know it works.  Think about contigencies for if aspects of the demo are not successful, can you show something else to achieve the same result?

If technology fails on the day, which it often does, it is worth being able to speak about the platform with nothing infront of you to discribe the features and functionality whilst the team fix the error.


Planning and Agile are they mutually exclusive?

Agile is often seen as the excuse by clients.  The client thinks that the PM is using ‘Agile’ as an excuse not to have reports or controls.  This need not necessarily be the case.  Whilst agility is important in all of the projects that I am currently running the need for tracking and planning is also paramount.  I tend to work to the controls that the client needs.  In order to produce these it is vital that the PM sets out the planning and tracking requirements at the beginning of the project.

Get the client to scope the required tracking and planning documentation and then ask why each is required.  It could be vital for the business or just for the clients own personal requirements.  If a report is vital for the business it must be produced, however if the report is purely for personal requirements then an exercise in confidence building is clearly needed.

Every project needs a plan of some sort, it doesn’t need to be ‘the plan’ you just need to start with something even if it is very high level.  I find it good practice to baseline the plan early but to set both the client’s and the team’s expectations.  I would certainly not suggest that you commit to your plan until the scope of the project is fully understood.

Get your team and the client involved in the planning.  Teams are more likely to stick to a plan that they have been a part of creating.  Be sure to manage change in the planning process and show the consequences, point out that it is not you that will be thrown off course by a late or non-delivery of an item, it is the other team members who are relying on that part of the product.

Discuss the Project Management Triangle with the client; there are three main areas where movement is available in a project. These are Quality, Time and Cost.  Find out which of these you have the most leeway with.  This will give you a basis for future discussions.  If your planning is measured by the achievement of business objectives (which it should be) rather than specific deliverables you will have the opportunity to sacrifice functionality rather than deadlines.

Create you plan to the appropriate level for the information that is available.  You will normally find that different audiences need to see different levels of the plan and it is the job of the PM to keep the plans and reality in synch.  Remember that the right level of plan is always driven by the needs of the team rather than the need to use specific tools or software.