After initiated in the role of an agile consultant for a multinational company, I was invited to participate in a new software application failure “fact-finding” meeting.
The application was launched last month and users rejected it outright and rated it “bad”. Despite using agile software development process the application was not accepted by both critics and customers so obviously business and technology stakeholders were shocked and curious to know the reasons behind the application debacle.
Fact finding meeting started on positive note with program director presenting slides to prove his team’s innocence by highlight complex technical architecture diagram, agile-scrum process charts and continuous build framework artefacts.
Marketing team made brave attempt by justifying with financial figures and creative artefacts slides for efforts spent on promotional campaigns besides efforts spent on media and press releases.
After spending an hour and half I was restless as everybody was beating around the bush and was not interested in fact finding exercise for actual reasons for the application disaster.
Finally I could not resist my inquisitive nature and started asking questions. The question answer session is as follows:
Question to project manager: Did you capture all business requirements correctly?
Answer : Yes our business analyst captured all functional and not functional requirements using Epics and Stories.
Question: Was there any scope creep or project delay due to unavoidable circumstances?
Project manager: NO, for the first time our project completed on time and we covered all the requirements.
Product Owner made high level requirements very clears and informed us that the product MUST release on time. So we interpreted the project as fixed time and fixed featured project.
Open question to project team: Did you guys followed SCRUM ceremonies: Planning meetings, Showcase and Retrospective?
Project Manager: YES indeed we had planning meeting before initiating each sprints and showcase after sprint completion.
Now, I became more curious as project manager, business analyst and product owner’s answers were so far proving us that the project management and delivery was not at fault.
I was sure that something was missing here so to probe further I asked few more questions to understand steps followed in performing activities from sprint planning to retrospective events.
Finally the bizarre root cause was identified after marathon question answer session for 3 hours.
The identified root cause was – No working software was demonstrated during in showcase event after each sprint completion.
I was shocked but the organization culture was to do Agile showcase without product demo…!!!!!!
Initially it was unbelievable cause as the whole point of using agile methodologies was to demonstrate working features of product in showcase and shape the product based on review feedback from the showcase.
I thought in disappointed that the scrum master didn’t discharge his duties of executing scrum ceremonies and failed to prove the importance of showcase event to business and project team.
Further questions to scrum master revealed totally different picture as it was well known fact that in this company business was always driving all major decisions so product owner had the final say on all major activities of executing sprints ranging from prioritising the backlog user stories to deciding the showcase PowerPoint pack.
Product owner could not dedicate sufficient time to review epics, stories and product features during each sprint and during showcase meetings. The product owner and business stakeholders were interested in questioning the deviations in burn-up chart and total point achieved rather then focusing on product demonstration and product features and functionalities.
Consequently the product was developed with features interpreted by business analyst and project manager rather than from the perspective of business stakeholders.
Merely to prove the “achieved point’s” numbers tally with planned points for sprint, the product owner often forced project manager to split the user story points into half before showcase event.
This clearly shows that neither the project team nor the business stakeholders understood the agile scrum processes and ceremonies. Simply by following scrum processes and by executing scrum ceremonies nobody can ensure that “right” product can be build.
Roles and Responsibilities
Needless to say agile processes are “light-weight” and give enormous freedom to business stakeholders and project team however agile processes also demands judicious responsibilities and role playing for every individual involved in agile project activities.
Every agile project expect individual cadre to respect and execute the roles responsibly may it be product owner or Business analyst or scrum master / project manager.
The crux of this article is to understand what exactly is showcase event and its contribution in agile project management.
Agile team spends reasonable time working on “committed” user stories in each sprint and invest hard work to ensure working software is built based on committed user stories. The project teams is always excitement to show the working product at the end of sprint and equally the stakeholders should be excited and must have curiosity to view the working product.
Henceforth showcase the “Must have” and ideal event to communicate the journey of “time boxed” 2 weeks efforts with stakeholders. Showcase is not merely an event to display the working software, it’s an event to share strategy used to develop difficult user stories, any difficulties faced or tricks used by user experience team in designing a GUI designs, challenges to test features under development etc.
Accompanied with project team’s experience story it is equally important to demonstrate the working product features, incremental coverage of test automation besides display of forever evolving build and integration platform.
Showcasing “Under the hood” component is equally important as they contribute in building “technical” intellectual property for organization.
Showcase must include:
- Live product demo on “pseudo-production” server with end to end functional scenarios
- Live Demo of non functional requirements such as security, performance, usability, etc
- Test automation scenarios execution and overall test coverage demo
- Couple of slides or video recording of strategies used for challenging used stories or difficult work item
- Tricks, techniques and work around used for technical or business bottlenecks and features limitations
- Team members or external individuals or group members outstanding performance acknowledgement
- Sprint burn-up or burn-down charts, product velocity chart, tech spikes, tech debts, refractor artefacts, metrics, etc
- Next sprint “planned” user stories
Project Team and Project Manager / Scrum Master Responsibilities:
- Showcase presentation should be designed by project team and team should be allowed to present sprint experience to the event participant.
- Project Manager / Scrum Master must give opportunities to enthusiastic team members to demonstrate and present the showcase event to boost the team member’s confidence.
- During presentation Project Manager / Scrum Master should encourage team members to answer raised questions by participants and avoid giving “convincing” answer for cover-up exercise. Let the transparency and real facts be presented to stakeholders.
- Often few team members are good at work but are shy away in presenting. It’s the duty of Project manager/Scrum Master to encourage them however final decision should be left to team members if they wish to back out from presenting slides/demo.
- Project manager / scrum master must ensure the team work in cooperation and collaboration in activities such as drafting presentation to presenting demo in showcase and avoid “groupism” and evolving syndicates of developers, testers, etc.
- Team must also act responsibly and should avoid “loose” talks and opinion about project decisions to wider audience throughout, pre and post sprint.
Product Owner Responsibilities:
- Product owner must ensure that “required” stakeholders are present in showcase event and participate actively.
- Product owner and other stakeholders must be encouraged by product owner to ask relevant questions and contribute in product development.
- Pin pointing project teams repeatedly on selected items such as achieved points and velocity chart to ensure “timely” product delivery does not account for constructive criticism it will dilute showcase goals of “shaping” product.
- Product owner should give encouraging and supportive feedbacks during showcase to motivate project teams.
- Product owner must participate in defining goals of showcase to ensure team draft presentation revolving around sprint goals and demonstrate transparent outcome of sprint.
Finally project team and product owner must be humble enough to request feedback from showcase event participant for their opinion on:
- Product features
- Sprint goals achievement
- Clarity of communication
- Ideas and suggestion for product improvement
Again in my opinion feedback such as request for colourful and well formatted template based presentation should be given list priority.
The important point to remember is the demonstration of working software which speaks for itself is more important than glossy presentation with few pictures, jokes, and wisdom quotes.
Product showcase is NOT marketing presentation and showcase event is not for impressing stakeholders. The ultimate goal is to discuss about the product under development by presenting the transparent and clear picture of product to stakeholders and expect constructive feedback and to avoid product failure in the market.