Inception Overview Thought Works 2006 30

Inception Overview © Thought. Works, 2006

30, 000 ft View of an Inception The process Why Inception? The role of models Practicalities Business context The outputs © Thought. Works, 2006

Why Inception? © Thought. Works, 2006

Existing business relationships are often impaired • Often business and IT are separated by heavyweight processes - impairing communication and often sowing the seeds of an adversarial relationship Business • The result is can be a significant disconnection between these two - before we even consider the needs of the end user © Thought. Works, 2006 IT End user

Inception helps to redefine relationships • We are pairing with the client, enables us to rebuild this communication – Communication bottlenecks removed Business IT – Work in a collaborative manner – Shared understanding of all parties needs is developed © Thought. Works, 2006 End user

Scope © Thought. Works, 2006

Scope - From programme to sub-project • Inceptions can be successfully applied to work of varying scope - from programme level, through project level, to subproject level High level processes • The scope identified will impact the length of the Inception itself and the nature of the deliverables • The flexibility of the process also allows the team to change the scope of work (within an overall cap) in response to what is discovered Planning level stories The volume of the Inception effort is capped but how it’s expended can be flexible © Thought. Works, 2006

Nature of deliverables will vary • With different scopes the nature of deliverables and the models used will vary, however the approach remains the same • Business objectives • Business case • Business objectives • Roadmap • High-level processes • Roles and goals • Planning-level requirements • Release-level requirements • Roles and goals • Low fidelity prototypes • Iteration level requirements • Release plan • Low fidelity Prototypes Wide (Programme level) Medium (Project level) © Thought. Works, 2006 Narrow (Sub-project level)

The process itself © Thought. Works, 2006

The defining characteristics • Collaborative and inclusive Heavily workshop oriented - creating a shared understanding across the team • Time-boxed and rapid Doing just enough - and doing that quickly • Iterative and feedback driven (embracing change) Momentum is built around the highly iterative evolution of models owned by the team • Very Visual - Centred around tangible models By making the problem and potential solutions as real as possible, higher quality feedback is driven out • Business value/implementation cost focused Prioritisation of delivery by an informed and empowered group - what benefit for what cost • This is NOT upfront analysis by another name Ongoing analysis will take place within the delivery project to refine the view © Thought. Works, 2006

Collaborative and inclusive © Thought. Works, 2006

Part of a bigger process • The Inception is designed to lead to an agile development project Release 1 Iterations 0 Inception 1 2 3 Retrospective Release 2 Iterations 0 1 2 Inception 3 Retrospective © Thought. Works, 2006

Inception Does Not entirely replace analysis or design • Inception does not normally provide development ready stories • Recognize that you will continue to refine analysis and design following the Inception in each subsequent iteration Inception Key Analysis Design Iteration 0 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Test Implement © Thought. Works, 2006

The role of models © Thought. Works, 2006

Clear communication is the foundation “I’m glad we’re all agreed then. ” © Thought. Works, 2006

Get those mental models out on the table “Ah. . . ” © Thought. Works, 2006

An explicit model allows convergence through iteration “Ah!” © Thought. Works, 2006

A genuinely shared understanding “I’m glad we’re all agreed then. ” © Thought. Works, 2006

Typical Models and Inception Test Refine $ Financial model 0101001 0001101 1100101 1010001 Prioritised list Business process model Code Architectural model Prototype (lo/hi fi) © Thought. Works, 2006

Typical Inception Processes • Workshops Drive much of the process • Small group analysis Particularly at greater levels of detail Workshops • Work shadowing & observations Rapidly gain an understanding of the current context is simply to go and look • Existing analysis & usage data Provides good context Small group analysis © Thought. Works, 2006

Outputs © Thought. Works, 2006

Business won’t be getting this © Thought. Works, 2006

The Inception Team • Core team – Who: the business and implementation (IT) team members with day-to-day responsibility for defining/delivery the solution (must be empowered decision makers) – Commitment: Each workshop, daily stand-ups/retrospectives • Subject Matter Experts (SMEs) – Who: individuals with specific expertise relevant to portions of the analysis but not all – Commitment: One to four workshops as relevant • Senior stakeholders – Who: the ultimate sponsors for the project - those responsible for realising the business value and/or the implementation of the solution – Commitment: At least the kick-off and showcase workshop for each week, welcome to attend as widely as possible, some ad-hoc requests © Thought. Works, 2006

What does the team need? • A good sized room with plenty of wall space - sufficient to accommodate expected attendees for a workshop – Ideally the same room throughout the process – Preferably to serve as the team’s base outside workshops • Whiteboards, flip-charts and dry wipe marker pens • Index cards plus pencils, sharpeners and erasers • A digital projector (at least 1024 x 768) - to review / edit output • Access to a printer • Connectivity – Ideally LAN access to a network for file transfer and email • Digital Camera © Thought. Works, 2006

Week one - Workshop focused • Week one tends to be workshop focused • The whole core team should be present at the workshops in at least the first quarter of the Inception Mon Tue Wed Thu Fri Inception kick-off Morning workshop 90 mins (10: 00 - 11: 30) Consolidation 90 mins (10: 30 - 13: 00) • As well as helping to build the shared understanding • …it’s important in terms of team building, particularly where both client and Thought. Workers may not have worked together before Learning lunch 45 mins (optional) Learning lunch Weekly showcase / retro • Remember to reflect at the beginning of each workshop so people remain up to date Afternoon workshop 90 mins (14: 00 - 15: 30) Consolidation 90 mins (15: 30 - 17: 00) Stand-up / retrospective 15 mins (17: 15 - 17: 30) © Thought. Works, 2006

Subsequent Weeks - Small group analysis • Subsequent weeks are likely to be less workshop focused Mon Tue Wed Thu Fri Morning workshop 90 mins (10: 00 - 11: 30) • Time will increasingly be taken up with small group analysis… • …focusing on topics not suited to exploration in the larger workshops • Nevertheless it’s good to keep a heartbeat of workshops scheduled Consolidation 90 mins (10: 30 - 13: 00) Learning lunch 45 mins (optional) Learning lunch Weekly showcase / retro • This allows the progress made in the smaller group analysis to be showcased… • …and feedback from the wider team provided Small group analysis / Other Stand-up / retrospective 15 mins (17: 15 - 17: 30) © Thought. Works, 2006

Alternative patterns • The balance of workshops to other forms of exploration and analysis should be down to the Inception team itself • As with the content, the precise shape (types of analysis best used) for any week will depend on how the Inception develops Mon Tue Wed Thu Fri Inception kick-off Morning workshop 90 mins (10: 00 - 11: 30) Consolidation 90 mins (10: 30 - 13: 00) Learning lunch • The team should look to agree the shape of any coming week by the Wednesday of the preceding week Learning lunch 45 mins (optional) Learning lunch Weekly showcase / retro • All these weekly patterns are indicative, a starting point to be tailored… Small group analysis / Other Stand-up / retrospective 15 mins (17: 15 - 17: 30) © Thought. Works, 2006