In this blog I thought it would be worth talking about an often neglected but vital part of any delivery - how do you really - practically, kick off an Agile Scrum based project. Below is an insight into how we kick off our software development projects for client’s, or what we can train your teams in how to carry out inceptions, and equally importantly how to create the outputs from an inception
At 60 Innovations kick offs are known as inceptions, they cover pre-kick off and kick off activities under one banner, and get you to sprint zero in an organised, easily repeatable manner. They provide an excellent level of clarity for the development team, they are an essential period for the team to form a working relationship with the primary project stakeholders, and they give the stakeholders confidence that the goals of the project are understood, and the high-level architecture produced will ultimately meet their requirements.
Inceptions prevent the temptation just to start coding, which while on occasion produces results, more often than not it just creates chaos and wasted effort. Tip: The fail fast element of modern software solution delivery is great but do it in the right environment, not the first week, or in production!
Inceptions are best carried out face to face at either ours or our client's offices; this is due to the opportunities they create regarding face to face relationship building with the team as they establish the project goals. It makes practical activities like use of sticky notes and communication much easier. From a more fundamental perspective, it puts everyone in the same time zone which can be a big deal if there is a significant difference i.e. some people may have had to work very early or very late. Given how mentally taxing inceptions can be this should be avoided to maximise concentration. Off site, inceptions are possible to do, but they tend to be longer in duration than on site inceptions, usually due to differing working hours and communication being slower using remote tools and conferencing facilities.
The Inception Deed the Deed covers off the following points; 1. ood personal relationships. 2. Excellent domain knowledge transfer. 3. The main aim & vision of the project. 4. Identify all key stakeholders & dependencies 5. The risks that need to be mitigated from the outset, a RAID log is produced. 6. A high-level architecture is agreed upon, and documented. 7. A product backlog is populated in JIRA/trello or similar. 8. A high-level timeline is desirable, but not always possible. 9. Identify Key Milestone Dates. 10. The drumbeat of the project is agreed i.e. what meetings when and why, expectations from those attending the meetings.
Inceptions are an intense few days, but they are rewarding for those who take part and give a great foundation for a project to start in the most Agile way possible. Below are a few points to have in mind when you become involved in inceptions. Recipe for a successful Inception:
Why do we do Inceptions? The purpose of an inception is to understand the goals/aims of a project.Inceptions are an excellent way to pack several activities into a condensed period. Initially focusing on the “What” and the “Why” rather than the how, an inception allows the team to collaborate with project stakeholders to form an understanding and gather requirements, at a high level, that should enable the team to start development work quickly.
Inception Rules. Rules should be agreed as one of the first action points. Things like bathroom breaks, only having one conversation in the room at a time, “rabbit hole” monitor, car park (parking lot), focus on the “What” and the “Why” rather than the “How”.
Requirements & Vision, The client or product team who attend the inception should share a vision, be able to articulate their requirements from a business perspective, and understand the technical domain enough to be able to provide a clear description of it. Why? Without this, inceptions are not as effective as they can be, the project may start under significant doubt regarding is what we are building anything like correct or not.
Agenda. An agenda should be prepared for each day of the inception. This should be communicated before the start of the inception to allow stakeholders of specific areas to make themselves available when needed. It also gives ALL parties the opportunity to oppose timings/order or content. If this doesn’t happen, the inception will go ahead as planned. Each morning should begin without a look at the agenda for the day; potential issues, constrictions or obstacles should be highlighted at this point by the group.
he Product Owner (PO), (in the Agile sense), is available for the majority or preferably ALL of the inception. Why?, the PO is key to delivery in an Agile project, it is essential that the team learn to communicate with the PO and form a great working relationship. It is also key as the PO will hold all of, or the majority of, the critical information about what the project is to deliver and what the business problem is that the development team will solve. They are also able to bring subject matter experts (SME’s) into the inception as and when required, to answer any questions requiring their specific areas of expertise. The PO should also be aware of all key dates for delivery and any QA & Security processes that need to be adhered to before any release into production.
All in all this role enables the team to build the most complete possible picture of what is required, when and how that will get to production, who to go to for accurate information as the solution is developed, and what the main features are of the solution. A final point on the PO, they should be the person who can say yes or no and make a decision, OR get a decision QUICKLY, if that is not the case then teams, from experience risk having to add 30% MINIMUM to estimates to allow for time taken to get decisions.
Access to JIRA, Confluence, GItHub, and any other tooling that is to be used on the project. It is essential that by the time the inception starts the team can confirm access to these systems. Why? This ensures a smooth transition from inception to Sprint 0, and project start.
Facilities, Any communications systems such as video link, etc. need to be tested by the parties who will use them before the inception starting to confirm that they will be useable as a form of communication during an inception. Why? If they don’t work the inception will either fail or be very protracted. This causes a lot of frustration for all concerned. If any of those involved in the inception are to remotely connect then a strict code of only talking about the inception while in the actual meeting room should be observed. Otherwise those remoting in will feel they only have half of the story and become disconnected with proceedings. All networks to be used & passwords to them should be distributed beforehand, so people don’t have to waste time finding them and logging in on the day.
Equipment. Sometimes taken for granted but the room in which an inception will be held should be equipped with enough sticky notes, markers and whiteboards for the team to use. This encourages a group to become more involved, to offer alternative opinions and gives them more than the power of speech to put their point across.
For an informed view of what it’s like to experience an inception for the first time, we asked one of our clients Worldline for their feedback after experiencing an inception workshop for a few days with our team, read here what Ryan Bryers, CTO Worldline UK&I had to say about the process - Worldline testimonial
