An Observer’s Log of an Agile Inception Workshop

This journal entry is an attempt to chronicle some of the processes from an inception workshop I personally participated actively as a Product Owner. I hope this will be helpful as reference, not only for Agile practitioners but also people wanting to look into how Agile cycles get started. Due to sensitivities related to corporate strategies, this write-up is kept highly generic, with minimal references to the company, initiatives and personnel in question. Also, it is a relatively long write-up. After all, this is a chronicle of almost 2 weeks worth of intensive workshop participation!

1. Pre-Workshop

There are some very necessary preparation that must be done before any kick-off session. In fact, some very good suggestions on the conduct of the workshop were gotten in pre-discussions I had held before the actual workshop. Prior to any workshop, the facilitator must first identify the key personnel and communicate the agenda so that the correct groups of people can be invited. One learning I had was that the sessions must be kept to ideally 10 people or less to be effective. Therefore, we had conducted a very comprehensive trimming list to keep participants to a minimum. This may be highly sensitive, but is necessary to ensure a productive workshop.

2. Team Intro and Sponsor Speak

As with all workshops, it is always prudent to introduce everyone present at the workshop, and especially their scope of work and where relevant, their purpose at the workshop. In addition, executive sponsors should always be given some time to set their expectations and desired outcomes from the collaboration. For any large scale endeavor, especially in a domain as complex as software engineering, strong executive support is definitely paramount.

3. Inception Kick-Off

After the formalities are concluded, it is common for the Business Analyst to kick off by setting some ground rules by which the workshop will be conducted. Our BA gave a really succinct and effective delivery of the rules of engagement and desired outcomes and behavior from the participants.

What follows will usually be the Product Owner presenting his strategic vision for the product. While a large portion of it should be the shorter-term vision that should be immediately realized in the upcoming 2–3 months (i.e. the inception workshop time frame), the PO should also keep in mind the larger vision and strategy, something which sets the direction beyond this inception into the subsequent inceptions.

I specified my high-level prioritization principles for the work to be done at this inception and its accompanying sprints. These principles precipitated into a clearly ranked list of initiatives and features to be delivered by the team. With a clearly defined vision, it is easier for the team to structure arguments for and against the PO’s stated vision, and tough questions need to be asked at this forum to allow the PO to further refine the vision where required.

A very nervous PO presentation

4. Stakeholder Mapping

This is an exercise to create a visualization of the Impact vs. Involvement matrix by which the facilitators are able to ascertain who should or should not be involved at different stages of the inception process.

There are a few simple steps to follow:

i. Identify the key groups of people and label them with different colored Post-It notes (e.g. Business People using Blue, IT folks using Yellow, and so on)

ii. Write down all stakeholders’ names on individual Post-It notes (including what their role in the project is). Write their names on Post-It notes color-coded according to their defined groups

iii. Draw an Impact (y-axis) vs. Involvement (x-axis) chart and proceed to discuss as a team where each individual should be placed in this chart

Our final stakeholder mapping chart!

5. Agenda Setting

It is highly important to commence every new day with the customary agenda presentation. It is paramount to align all participants on the day’s objectives and timings to properly set the expectations.

Nothing like a clearly defined agenda to kick-start the day

6. Hopes and Fears

In this segment, we documented all of our hopes and fears from the immediate 3 months. Using color-coded Post-It notes, we wrote down our greatest hopes from the next 3 months’ collaboration, and also penned down our worst fears. It was an extremely refreshing introspection into our current state, and where we would like to be in the future. The facilitators then categorized all of the Post-It notes into “Technical”, “Business”, “Experience” and “Team Work and Collaboration”. As you can probably tell from the picture below, the group is generally more hopeful than fearful about where we are headed — an extremely encouraging sign!

Plentiful of hopeful notes!

Some fears outlined to keep us on our toes

7. Product Vision

Although I had presented the high-level product vision earlier, it was always going to be useful to flesh the product vision in greater detail. Therefore, the facilitators drew on the board various broad categories, namely (bold items were identified as the focus for this workshop):

• Target group (E.g. Parents, Aged, Students, Merchants)
• Channels (E.g. App, Web, In-App Purchases)
• Value (E.g. Value-Added Services, Instant Rewards)
• Unlike (E.g. Any competitors)
• Differentiation (E.g. Reputation, Familiarity)
• Business Goals (E.g. Transactions, Data, Branding)

This was the first step in defining the items that truly bring value in the immediate 3 months. In fact, this list is supposed to be used at the next inception as a baseline for discussion. It was worthwhile to note that the facilitators were extremely “brutal” in the culling of ideas that are less relevant to this inception. While initially uncomfortable, this brought about a razor-sharp focus in our subsequent discussions — an outcome that is very much desired.

8. Success Metrics

At this stage, it is important for the Product Owner to properly define the metrics by which success of this project will be measured. Therefore, I gave a very brief outline of the measurable KPIs my team is assessed by management on, and the Ops and Back-end teams also shared some metrics they felt were relevant to the project. This exercise gave us strong clarity in terms of which areas we should really be focusing on for this inception.

9. Business Process Mapping

As opposed to user journey mapping, business process mapping is very much driven from a project management perspective. The first step in this process is to identify all internal and external stakeholders in the product delivery and management process. After identification of the stakeholders, we will need to identify the roles of each party, for example, that Business Development (BD) is in charge of identification of market opportunities and Products is to make product decisions as well as manage the prioritization process. Thereafter, we were supposed to identify the pain points with all of these stakeholders. Keeping in line with the example above, we defined BD’s pain point as the gap between demand (of business leads from BD) and the supply (of product features to satisfy these partners and business leads), while for Products, the key pain point was in terms of managing expectations between BD and IT.

10. User Journey AS-IS (Business Track)

This portion of the workshop was related to existing user journeys. In fact, we were split into both business and technical groups to perform this exercise.

First, we were told to identify steps along the user journey, especially for flows that were especially related to the inception agenda. After identifying the steps, we were instructed to go deeper into specific actions required for each step. For example, for “Registration” (in our case the product is a mobile app), we had to say what exactly the user has to do — for example submission of information, phone number authentication, marketing consent toggling, etc.

Thereafter, based on these specific and granular actions, we had to detail which actions were bringing about the biggest pain points. For example, for “Registration”, we identified the excessive number of fields, as well as a slow OTP system, as being key pain points for customers in today’s AS-IS flow. It was hugely insightful to structure all of the varied pain points we experience in our everyday operations in a large flow chart.

11. User Journey AS-IS (Technical Track)

The session was geared largely towards understanding the current architecture. We took the opportunity to classify which are legacy systems, vendor systems as well as 3rd party services.

Next, we embarked on a comprehensive review of the enterprise IT architecture as a whole. Here, it is important to identify and classify which are critical systems. It will be useful for internal IT architects to show some of the architecture diagrams with the development team, and how adapters are being used to serve different applications and vendors.

Depending on which process is of interest at the inception, the technical folks should revisit the entire flow to make the team understand and appreciate the end-to-end process.

Finally, we dived into the world of DevOps & Logging, wheremy Tech Lead gave an overview of the current logging system status and what we intend to do to facilitate investigative processes in the future. He highlighted the urgency of having CI/CD pipelines, for all the new services. This will cut down the developers’ time and allow us to develop automated tests. We also discussed about the monitoring framework, an area which is critical in supporting the provision of 24*7 services to app users.

12. Pain Points Mapping

This section is a pretty “glum” exercise in pain points mapping. The purpose of this activity is to match the technical pain points identified from the earlier technical track, to the business pain points identified by those from the business track.

Next, we had to perform our favorite action — prioritize! With an avalanche of matched pain points from the business and technical folks, we had to again mercilessly cull the less critical items — leading us to a few top priority items.

13. Trade-Off Slider

The team had lots of fun with this one. Essentially, we were supposed to vote for the least negotiable items in the following list. This was how we eventually ranked them.

1. User Experience (e.g. ease of use)
2. Time (e.g. committed deadlines)
3. Security (e.g. L&C requirements and other items that might compromise company reputation)
4. Scope (e.g. how much should be covered in a single sprint)
5. Cost (i.e. $$$)

Essentially, this allowed us to understand why the working team prioritized some features over others, and is a good benchmark from which to base future prioritization and decisions on.

Our beautiful trade-off slider!

14. To-Be User Journey Design

Zeroing into the top priority items, my Tech Lead started this discussion with a clear description of how the existing user journey works from a technical perspective. This allowed us to identify clearly where the biggest issues lay in the entire process, and hence set the course for the subsequent discussions.

In fact, an extremely critical pain point became extremely clear to the team. However, while the problem was clear, the solution was less apparent. To come up with more solutions, we were split into 3 teams to brainstorm and then present ideas to overcome this specific problem. Indeed, nothing like a good old-fashioned group brainstorming to come up with interesting ideas to solve existing pain points!

The group then engaged in a very lively debate about a new flow that we agreed is critical to our key customer group. With that, the BA led us to define the steps in this flow. With the high level steps defined, we then had to break it down into task level.

This exercise allowed us to focus our discussions on specific tasks, and to debate about the issues and implications of following certain paths. We found ourselves having to ask some tough questions and weigh potential trade-offs (e.g. security, speed).

Hence, this was an invaluable opportunity to thrash out problems with key stakeholders before locking down new features and user journeys. Involve varied functions as they are always able to surprise you with insights you would have never thought of!

15. Dependency Mapping

Following that, we had a quickfire dependency mapping session for Ops and L&C, who will always contribute great insights from their respective domains with regards to dependencies that could potentially derail the project or extend the timeline. This was also the forum where we discussed in depth the security and safety concerns mentioned in the earlier segment, and some mitigating solutions.

16. User Journey Flows

With the key features prioritized, we proceeded with the detailing of the user journey for the surviving new flows. This should be a detailed step-by-step chronicling of every single step and decision points a customer will face when he/she uses the app.

For this purpose, there is an excellent tool, called Real Time Board — a simple visualization and white-boarding platform , or digital Post-Its for the uninitiated. This is a typical SaaS product that has a basic free version (which allows for 3 users), and the scalable paid version.

17. Dependencies Mapping

With the key user flows mapped out, we had to, again, generate a list of technical and business dependencies, or in other words potential showstoppers. The person to follow up upon these items should also be explicitly identified and documented.

18. CFRs (or non-functional requirements)

This was an exercise to classify different aspects of development into “Must Haves”, “Should Haves” and “Meh”. Caution should be exercised here, as items not under “Must Haves” are not unimportant. They are just not fatal to the company’s reputation and mortality. In terms of practical application, for example, if Reliability is labelled as “Must Have”, it means more development effort in the form of additional safeguards will be put in to ensure that the app does not crash frequently and performs without hiccup.

Must Have

• Deployment
• Auditability
• Availability
• Usability
• Scalability
• Reliability

Should Have

• Configurability
• Authentication
• Monitorability
• Reusability
• Continuity
• Data integrity
• Resilience and Fault tolerance
• Security
• Legal
• Latency and response time
• Multiple environment support

Meh

• Authorization
• Integrability / Interoperability
• Recoverability

Our final decision!

19. Technical Review

The technical team then split out for an in-depth discussion on some of the features discussed earlier. This stage is an extremely important aspect of the user journey planning as it allows us to understand key technical bottlenecks, as well as have an appreciation of the magnitude of the work involved.

20. Estimation

For the estimation phase, the key outcome is to quantify the technical effort required for all of the key user stories listed from the previous sessions. The conduct of this estimation was highly interesting, and it was fantastic to see and learn from how the BA managed the entire process.

First, the BA gave a quick introduction of how this session will be conducted. She then passed several cards numbered 1, 2, 3, 5 and 8 (Fibonacci numbers) to all participants. Next, she scrolled through the list and got all technical participants to agree on a story in the list that they feel should be ranked as a medium effort task (i.e. rate at 3) to set a benchmark.

How the team derives the estimation number (or score) is that the BA will run through each story in detail to let all the technical participants have a good idea of the story/feature. All the technical contributors will then have to make an assessment at story level, and raise one of their cards to indicate their estimation of the effort measured against the baseline. If there is someone showing a different number to the rest, he/she has to justify his/her decision and the BA will have to facilitate subsequent discussions with the other participants to drive towards a consensus on the effort scoping.

It has to be mentioned here that the estimation number informs the man-days scoping, but is not a direct representation of the man-days. The reason behind this is because the man-days estimate is a function of not only the complexity of the task (represented by the estimation number), but also the velocity / speed of work done of the team. In addition, although the velocity of the team may be estimated based on their previous works, every new team arrangement will introduce unknowns such as team dynamics into the picture — a complexity that means any inferred velocity from retrospection should be taken with a heavy dose of skepticism. Therefore, the team will likely need to run through several sprints and iterations before they settle upon a steady state velocity, and also a mutual understanding and calibration of complexity estimation according to the group’s baseline. Only then will we be able to scope the man-days to a reasonable precision.

21. Ways of Working

A high level flow chart on the typical Agile iteration

In terms of the cycle, a typical iteration will be approximately 2 weeks, with a series of important milestones and sessions required before culminating in a showcase and a sprint retrospective. At the end of every sprint, a sprint report should be compiled by the Scrum Master using tools like Jira. In addition, Agile teams should consist of more than 3, but less than 9 members.

Sample of a sprint report

A burndown chart from a typical sprint report

For this engagement, our development team holds a team structure comprising of a PM, a BA, a TL, a QA, 5 Developers, and optionally 1 Security SME and 1 UX designer, which are flexible and non-dedicated headcounts.

A table detailing the roles, tools and times for each major milestone within each sprint

A table detailing the roles, tools and times for each major milestone within each sprint

Next, the BA will have to populate the table above, detailing the personnel involved, the tools required, as well as the dedicated timings for each session/milestone for each iteration. This a great time to also indicate travel requirements, especially when working with geographically separate teams.

With the table filled up, the BA will have to get a consensus on the iteration start day, taking into account preferred deployment days, avoiding end or start of week, etc. Eventually, the team decided to start the first inception from Friday. Also, it is necessary to note that the business team is always 1 iteration ahead of the technical/development team, in that they are preparing the requirements for next iteration while the technical team is working on the development work for the current iteration.

Planned time-table for every sprint

With the generic time-table of each sprint worked out, the team has to agree of 2 important concepts, namely the Definition of Ready (Story) and the Definition of Done (feature). For this particular engagement, we decided that the DOR should comprise of the PO signing off against the set requirements, being design-ready, as well as being dependency-ready. In layman terms, it means that the communicated requirements, UX, as well as stakeholder requirements (e.g. from Ops, CS, Legal) are all covered.

For DOD, we decided on the PO signing off on user stories, QA tests completion in development environment, as well as push to production. This last item is interesting in that this is largely dependent on the company’s preference in the design of the delivery pipeline.

As you can probably tell, to define how the teams should work together, as well as establishing some norms and aligning expectations, is tedious work, but extremely critical in ensuring everyone knows when to do what during every stage of the iteration. In addition, this exercise also eliminates a lot of the ambiguity and potential disagreements when the real work starts.

22. Prioritization #2

To derive any meaningful estimate of the man-days required for any epic, we need to know clearly the estimated effort for each user story as well as the team velocity. While we had a clear consensus on the estimated effort for each task (represented by the estimation number), we had no clue of the team velocity — something which can be measured only after several iterations.

However, we learnt of a method by which we can come to a reasonable estimation of the team velocity. Using the defined stories from the earlier sessions, the technical participants are requested to work together to categorize all the stories into each sprint cycle (i.e. which of these stories can they reasonably expect to fit into a sprint). They will have to categorize all the cards into 3 different sprints, with the aim to ensure the load across all the sprints are similar. These cards have their estimation numbers (determined from the estimation session yesterday) written on the back, but they are all hidden from view from the participants.

Each card has the estimation number written behind it, but hidden from the participants during the categorization exercise

After a consensus is reached on the categorization, the BA will then reveal the sum of the estimation numbers behind. Thankfully, all the sprints had a similar estimation number sum and hence, we did not have to spend more time clarifying and re-conducting the exercise. For the curious, our team came up to an estimated team velocity of 25 stories per iteration, with the assumption that we have 5–6 developers.

This, however, brings to light a cold and hard truth. With 255 story points from our previous scoping, we expect to have at least 10 iterations to deliver all the stories we came up with. Hence, I had to, again, prioritize (I am beginning to hate this word)!

As a tip, it is usually good to start this prioritization exercise at epic level first, so that we establish some basis for the subsequent decisions.

While the write-up for prioritization is relatively short, the process is extremely difficult. As a PO, I have come to realize that the most important work to be done is not in the design of the flows but rather, the making of strategic decisions to include or exclude certain features. This takes, not only a strong appreciation and continual alignment to the company’s strategic objectives, but also firm stakeholder management to explain objectively the reasons behind your inclusion or exclusion of different features. It is definitely tough work, but one that has the ability to determine the success or failure of a company’s strategy.

23. Path to Production

This segment is catered more towards the technical folks, but their outputs will strongly impact upon the delivery dates and time frames between launches. This will likely be of strong interest to the business stakeholders, and hence, their participation and questioning of assumptions is critical.

Final production table

This exercise is primarily used to identify the stakeholders, tools required, as well as estimate the general timeline for the production process. With the help of all the SMEs present, we populated the table above. In addition, we also took the opportunity to clarify the work scope for our test manager.

24. RAID & Parking Lot

This session is a review of the items we parked aside over the past few days due to various reasons such as external dependencies. RAID represents Risks, Assumptions, Issues and Dependencies. In summary, this process was to weed out which items were no longer relevant for this inception (i.e. de-prioritized or dropped epics) and to clarify which items were to be followed-up by whom.

Final item for the day was the Parking Lot, or in other words, items we couldn’t decide on hence the procrastination to the end of the workshop. What started off as a board plastered all over with Post-Its ended up with only 3 — a testament to our marked improvement in prioritization and features-killing skill!

25. Release and Integration Plan Review

This exercise was facilitated by the Project Manager, and involved all the stakeholders going through the pre-prepared timeline for the upcoming 3 months.

I believe it is safe to say that for first inceptions, the schedule definitely starts with a week-long effort invested into environment set-ups, including the collaboration tools that the teams agree upon. Our tools of choice were Jira, Trello, Confluence, Zoom and Slack. As for the other items in the release plan, it is important to note that this should be a high-level representation of the tasks to be completed. The details in Path to Production as discussed earlier should not be reflected here. Also, the items are representative only of timeline, not effort.

This forum should also be a good opportunity for the teams to determine the administrative dependencies and who is in charge of following up.

26. Roles & Responsibilities

With the road map planned out, it was time to document (and debate) on the roles and responsibilities for every individual in the team. Below is a comprehensive documentation for the reference of other product teams as well.

Developers

• Estimates size of backlog items
• Translation of backlog items into engineering design and logical units of work (tasks)
• Evaluation of technical feasibility
• Implementation of backlog items
• Build quality in (Test driven development)
• Writes and verifies code which adheres to the acceptance criteria
• Application of product development best practices
• Set up staging, production environments (and in some cases the QA environment) in an easily repeatable way
• Post production monitoring, and troubleshooting of product/services

Quality Analyst

• Writes test plans which enforce the acceptance criteria of features
• Keeps all test plans and cases updated to changing requirements
• Continually integrates the code base with automated builds and functional-level regression tests
• Notifies when production is blocked due to errors in development
• Measuring Quality
• Defining Quality
• Improving Quality
• Enforces QA Best Practices
• Provides visibility into end-to-end product quality
• Owns QA Health status of releases/projects in SM dashboard

User Experience Designer

• Responsible for overall UI consistency across interaction models and visual styles
• Upfront user research (to help inform features/direction)
• Interaction Design specs (wireframes, user flows) which conform to acceptance criteria of the features
• Works with the Business Analyst on analysis of features conform to user’s needs and provide a consistent experience
• Ensures features are implemented as designed, and design modified to reflect implemented features
• Visual Design
• Prototyping
• Usability testing

Technical Lead / Architect

• Responsible for end-to-end cross functional system design and communication
• Works with the Business Analyst to group features based upon the Architectural Elements which support them, an influence on priorities
• Tests Architectural Elements with executable and testable design (abstract interfaces, aka the contract)
• Facilitates technical decision; incorporates feedback and emergent patterns from the team back in to the overall design
• Produces alternate Design Concepts & detailed approach
• Ensures the Design goals — Performance, Modularity, Reliability, Maintainability, Reusability, Internationalization and Accessibility — are met
• Ensures technical cohesion and helps write the technical contract in interfaces and other abstract objects and data entities
• Leads design review & provides feedback
• Review & Approve PR

Project Manager

• Manages planning process
• Facilitates Release Planning & Retrospective
• Provides access to tools and people
• Owns reporting on project status, to all directions
• Coordinates release support
• Responsible for risk assessment & mitigation
• Educates/Enforces agreed upon processes & methodology rules
• Educates/Enforces roles and responsibilities

Business Analyst

• Responsible for requirements analysis
• Responsible for long and short term product vision with PO
• Writes Acceptance Criteria, writes user stories and support delivery team
• Facilitates trade-off decisions between scope and other project variables (schedule, cost) based on value (or ROI)

Tech Lead/Architect

• Responsible for Review, Code , Pull request, System design, Architecture design
• Internal systems context sharing(Integration, Interface …)
• Chase up for the internal technical dependency

System Owners (e.g CRM)

• Solve the 3rd party dependency for other systems
• Make decision on the functional level design
• As the PO of other systems

Delivery Assurance (for vendor-based arrangements)

• Staffing support
• Company level offering alignment
• Delivery assurance from both agile practice and team capability cultivation perspective
• Company level offering alignment
• Member of CST (customer service team) for account strategy and governance model design
• Relationship Development
• Focus on the new business, relationship development and risk management

Product Owner

• Roadmap Design
• Provides vision for the solution
• Epic & Story level Prioritization
• Internal Engagement with secondary Stakeholders
• Product Requirement
• Report product KPI
• Budget management

Project Manager

• Works with teams to spread best practices, knowledge, innovations.
• Facilitates conversations with the project team “huddles”
• Achieves a level of consistency across project teams. Project Manager has the authority to make changes in tools, approach
• Provides clear transparency to compare projects across the organization (risk, progress, spend, quality, schedules and timelines, dependencies)
• Communicates effectively across the organization
• Project Manager is seen as an advisor and consulate, part of the team to help identify issues and escalate roadblocks

Infrastructure

• VPC Setup
• Network issues
• Focus on Production

IT Operation

• Account Control
• Access control
• Incident Management — VM network & Application basic log check
• Gatekeeper for Releases

Security

• Review Security

It is very important to be very explicit about each role’s scope of work, especially if there are individuals performing duplicate roles. This will prevent a lot of the overlaps and inefficiencies that may result from having too big a team. Again, the recommended team size is anything less than 10!

Inception Showcase (The Finale!)

I shall not elaborate too excessively on this segment, except that the showcase is a summary presentation of all the work done over the inception. Generally, although the showcase covers the methodology, processes, and also the tech behind the features, the forum should always be catered with the audience in mind. Since majority of the participants are business stakeholders, the focus should be on the business outcomes and benefits — especially for the technical segment. Nonetheless, for a truly Agile technology company, both the business owners and technical folks are expected to be adept at both business and technical know-how, something which requires longer term training and mindset adjustments!

Retrospective

Something which should follow all inceptions and iterations is the retrospective exercise. In essence, this is a relatively straightforward process, with all the key inception participants writing on Post-Its (yes, again) and pasting them according to 4 key categories, namely:

1. WELL: What have we done well?
2. LESS WELL: What could be better?
3. PUZZLES: I’m not sure about this…
4. SUGGESTIONS: We can do this next time!

Wrap Up

All in all, it has been an eye-opening experience to participate in my first inception workshop as a product owner. With a highly proficient partner in ThoughtWorks, me and my team were able to understand clearly the major undertakings of a typical inception workshop, and most importantly, appreciate the value of focus and prioritization for effective software delivery.