Learning Launch

Challenge

Being part of an IT&S business process design team a user interface tool to place orders from  customers to request services needed to be replaced as the existing tool reached the end of live  service and was not compatible with the cloud which is the strategic direction of the company for  customer applications. In the past, the company used for projects the classic waterfall concept  (select/design/build/deploy/support). As this was a time critical project and the results should be  achieved faster and more cost efficient, the agile approach was selected. To overcome the  knowledge gap of how to apply agile working in projects, an external consultant was hired to lead the  scrum sessions. The IT&S team was a diverse team where development activities have been  performed offshore. As product owner for the new user interface tool the business key stakeholder  was nominated.

Selection

In a first step the business requirements for the new user interface tool have been gathered and  confirmed by the business key stakeholders. The technique of learning launch was applied, prototype  the solution for the user interface solution based on understanding of the requirements in a very  short timeframe to show the product owner the developed product. The prototype included daily  scrum meetings between the design team and development team via conference calls including the  product owner to share the proposed design & design options for knowledge transfer, issues &  defects in the build phase of the prototype solution etc.

Application

One of the first steps was to evaluate design options based on the agreed business requirements.  An integrated activity between the design team and technical build team is required to exchange  functional process design and technical feasibility documented in a power point presentation. The  outcome of the agreed product needs to include the deliverables for the different sprints as part of  the agile approach.

The prototype process has been started to apply the basic/core design (minimal viable product)  agreed in agile sprint 1 into a technical solution provided by the offshore team after explanation of the  key desired functionality (i.e. log on to a customer hub, request a service based on a catalogue,  workflow functionality to agree on the contract incl price for the service and confirmation). To follow  the agile approach, no detailed documentation of the functional specification has been provided, only  the key elements on a high level documented and communicated to the technical team. As a  documentation tool visio process flows and where applicable narratives have been provided and  communicated in a Q&A session via conference calls to the offshore team. To save time and money  the technical team was not requested to provide a technical specification. The show and tell  approach was used supported by a demo of the first draft of the technical solution which was  validated by the product owner who provided feedback on expectations and usability. Questions to  the product owner have been raised to evaluate if the solution meets the needs, it improves the  process and would improve customer experience & satisfaction. After feedback which functionality  are good vs not sufficient a review process has started to discuss required changes and  enhancements taken into consideration feasibility in terms of time and costs. Iterative review  sessions have been conducted to analyse progress and issues and improve the user interface tool

step by step. Part of the technical build had to be trashed as it was not compatible with the required  fixes and enhancements.

Once the product is agreed and signed-off by the product owner in a final show and tell session, the  functional design and technical build has to be documented and stored in a central space for audit  purposes.

In the next sprint the user interface tool should be enhanced to cater for budget and reporting  capability. The same iterative approach as in sprint 1 applies which requires a final review and sign-off  from the product owner.

Insight & Approach

What I have learnt from prototyping a product based on an agile approach is that the product  specification requires a detailed description of the expected outcome clearly communicated to the  offshore team to avoid too many failures of the draft solution and iterations. In addition I feel that it is  important to think ahead of the additional requirements and add-ons to the product in the next sprint.  If the additional requirements (i.e. budgeting and reporting functionality) are not considered and  addresses, the issue arises that the signed-off product in sprint 1 requires major modifications which  can be time consuming and even require a re-design. This can be quite frustrating for the team as the  achievement needs to be reworked. Also it is important at the end of a sprint phase to provide a  proper documentation of the design, functional and technical specification. Due to time pressure to  move on to the next sprint and deliver the next milestone, documentation deems to be the least  important, but it will have repercussions in the long term in the sustain phase if a different team  (Production Support) will have to take over and don’t have enough information for know-how transfer  and reference documentation.

Reflecting the achievements of prototyping in iterative steps there is a clear benefit for the business  stake holder to see a draft product at a very early stage of the project and the stake holder can  influence the development providing feedback. On the flipside there is to mention, that the stake  holder needs to be managed to avoid that continuously additional requirement are added which  impacts time line and costs. Once the scope of the product is agreed the focus should be on the  delivery of the agreed solution. Scope creeping from the business stake holder should be avoided to  avoid jeopardising the timelines. Also documentation is important to complete at the end of the sprint  phase to have an auditable product and know how transfer to the Production Support team can be  performed.


Learning Launch Challenge Being part of an IT&S business process design team a user interface tool to place orders from customers to request services needed to be replaced as the existing tool reached the end of live service and was not compatible with the cloud which is the strategic direction of the company for customer applications . In the past , the company used for projects the classic waterfall concept ( select / design / build / deploy / support ) . As this was a time critical project and the results should be achieved faster and more cost efficient , the agile approach was selected . To overcome the knowledge gap of how to apply agile working in projects , an external consultant was hired to lead the scrum sessions . The IT&S team was a diverse team where development activities have been performed offshore . As product owner for the new user interface tool the business key stakeholder was nominated . Selection In a first step the business requirements for the new user interface tool have been gathered and confirmed by the business key stakeholders . The technique of learning launch was applied , prototype the solution for the user interface solution based on understanding of the requirements in a very short timeframe to show the product owner the developed product . The prototype included daily scrum meetings between the design team and development team via conference calls including the product owner to share the proposed design & design options for knowledge transfer , issues & defects in the build phase of the prototype solution etc . Application One of the first steps was to evaluate design options based on the agreed business requirements . An integrated activity between the design team and technical build team is required to exchange functional process design and technical feasibility documented in a power point presentation . The outcome of the agreed product needs to include the deliverables for the different sprints as part of the agile approach . The prototype process has been started to apply the basic / core design ( minimal viable product ) agreed in agile sprint 1 into a technical solution provided by the offshore team after explanation of the key desired functionality ( i.e. log on to a customer hub , request a service based on a catalogue , workflow functionality to agree on the contract incl price for the service and confirmation ) . To follow the agile approach , no detailed documentation of the functional specification has been provided , only the key elements on a high level documented and communicated to the technical team . As a documentation tool visio process flows and where applicable narratives have been provided and communicated in a Q&A session via conference calls to the offshore team . To save time and money the technical team was not requested to provide a technical specification . The show and tell approach was used supported by a demo of the first draft of the technical solution which was validated by the product owner who provided feedback on expectations and usability . Questions to the product owner have been raised to evaluate if the solution meets the needs , it improves the process and would improve customer experience & satisfaction . After feedback which functionality are good vs not sufficient a review process has started to discuss required changes and enhancements taken into consideration feasibility in terms of time and costs . Iterative review sessions have been conducted to analyse progress and issues and improve the user interface tool step by step . Part of the technical build had to be trashed as it was not compatible with the required fixes and enhancements . Once the product is agreed and signed - off by the product owner in a final show and tell session , the functional design and technical build has to be documented and stored in a central space for audit purposes . In the next sprint the user interface tool should be enhanced to cater for budget and reporting capability . The same iterative approach as in sprint 1 applies which requires a final review and sign - off from the product owner . Insight & Approach What I have learnt from prototyping a product based on an agile approach is that the product specification requires a detailed description of the expected outcome clearly communicated to the offshore team to avoid too many failures of the draft solution and iterations . In addition I feel that it is important to think ahead of the additional requirements and add - ons to the product in the next sprint . If the additional requirements ( i.e. budgeting and reporting functionality ) are not considered and addresses , the issue arises that the signed - off product in sprint 1 requires major modifications which can be time consuming and even require a re - design . This can be quite frustrating for the team as the achievement needs to be reworked . Also it is important at the end of a sprint phase to provide a proper documentation of the design , functional and technical specification . Due to time pressure to move on to the next sprint and deliver the next milestone , documentation deems to be the least important , but it will have repercussions in the long term in the sustain phase if a different team ( Production Support ) will have to take over and do n’t have enough information for know - how transfer and reference documentation . Reflecting the achievements of prototyping in iterative steps there is a clear benefit for the business stake holder to see a draft product at a very early stage of the project and the stake holder can influence the development providing feedback . On the flipside there is to mention , that the stake holder needs to be managed to avoid that continuously additional requirement are added which impacts time line and costs . Once the scope of the product is agreed the focus should be on the delivery of the agreed solution . Scope creeping from the business stake holder should be avoided to avoid jeopardising the timelines . Also documentation is important to complete at the end of the sprint phase to have an auditable product and know how transfer to the Production Support team can be performed .