An example of how Big Orange Square works with you and your teams
In another article, we explain the principles of agile product development (“The benefits of empiricism and teams in product development”). Since we advocate hands-on learning we here give an example of how we help you implement those ideas – we coach by doing, hands-on coaching.
Imagine you have asked us to write a proposal to help your team (of app. 25 people) to move to our agile (iterative and team-based) way to develop a product all the way from idea to manufacturing. This is an example of the answer you will get from us.
Coaching differs from both training and consultancy. Training presents and exercises the concepts of agile. Consultancy provides advice on how to improve agile skills and practices. Coaching brings an agile expert into the team, and the agile coach contributes to the project outcomes, a coach gets their hands dirty. Some coaching work is hands-on: structuring and leading meetings, owning the effectiveness of meetings. Some coaching includes theory and discussions. And other coaching activities leave documentation behind: usable documents like project structures, role descriptions and definitions of ready and done. All coaching is aimed at raising the ability of the delivery teams to deliver better products faster.
Goal of the coaching engagement
Right from the beginning the coaching, support and (incidental) training is aimed at raising the agile skills of all people involved in product delivery. We are immediately in the actual product delivery project. By raising the agile skills while working on an actual delivery, product development will show a faster delivery and higher quality. On the people side the commitment and enthusiasm of all involved people will increase, which by itself will increase productivity.
Success of the coaching work can be measured in terms of product delivery: faster delivery of working products, shorter time to market, higher quality of those products, and a better fit of products with the market needs. A baseline can be established early in the engagement. Success in terms of people will show in the mood of employees, and (if desired) this can be measured through employee surveys.
With teams and rapid inspect & adapt cycles (iterations) at the core of our approach you need to bring the complete delivery team to the implementation. All people who are needed to get a product out of the manufacturing plant are in the delivery team: designers (be it electrical, mechanical, or otherwise), build engineers (producing the actual product parts), quality people, supply chain representatives, manufacturing folks, trainers, services reps.
Schedule & Structure
Every day: The coach will be attending daily meeting with each delivery team and other relevant meetings. He will check in with team leads and the management team.
Day 1, Monday – Introductions, review of existing project implementation: people, teams, locations, product, product components, requirements, defect list, project management tools, short term plans, long term plans.
Day 2 – Agree on structure of delivery teams & requirement lists for each team. Teaching all involved on the agile principles, the structure, the meetings, roles and tools. Talk to the teams to explain the structure and the activities for the coming week. Collecting questions from the teams, determining the need for focused training sessions. The product team starts on writing the requirement in the proper format, structures requirements into features and reviews priorities. The documentation or agile project management tool gets the correct structure.
Day 3 – Overview of requirement refinement, the structure of the meetings, the goal, the participants, outcomes, duration, documentation (with all people). On a team by team base: the first requirement refinement meeting in which the list of requirements is reviewed and refinement and actions for further refinement are agreed. Short retrospective on this first refinement meeting.
Day 4 – Follow up meetings for requirement refinement, agreement in each team on which requirements are “ready” to be delivered in the next iteration. Collect information on the definition of ready.
Day 5 – Week review after a short introduction on the goal and structure of the meeting and discuss the outcomes of the review. Agree on the impact of the results (or missing results) on the next week and agree on what to do different. Weekly retrospective, in the individual delivery teams. In the afternoon, a full group review of the state of the requirements, the results of requirement refinement, the impact of the review and retrospective. Short inspection of the review and retrospective meetings. Getting ready for iteration planning on Monday.
Day 6, Monday – Iteration planning, starting with an overview (teaching) of the meeting, the structure, the goals, the outcomes. With all people define the team agreements (or working agreements), with all people agree on the definition of done – when is a requirement delivered so it is usable by others. With all teams involved, decide on the iteration goal and “what” will be delivered in the iteration, find dependencies, agree on sharing specialists and scarce resources. On a team by team basis work out “how” the requirements will be delivered, populate the iteration plan with tasks for the individual people, agree on ownership of tasks, estimate tasks. Review the iteration plans from the teams with the whole group, find dependencies, solve those. Ensure that nobody is overloaded. Populate the agile project management tool. Short retrospective on the first iteration planning meeting.
In the afternoon: work! Deliver requirements as per the tasks in the iteration plan.
Day 7 – The people in the delivery teams keep working, building product parts as per their iteration plan, collect information for other teams (like purchasing data, and assembly instructions for manufacturing). Daily meeting with each delivery team, daily meeting with 1 or 2 representatives from each team to find blockers and solutions, and monitor progress and impediment resolution. Coaching product managers on the structure of the requirement lists. Coaching on as-needed base for teams or individuals.
Day 8 – Work! Daily meetings with teams and team leads, coaching. Get the requirement list and the teams ready for estimating this list (possible training session, refinement meetings).
Day 9 – Same as yesterday. Possible first requirement estimating round.
Day 10 – Work, work, work – first requirements should be visible as product parts and can be inspected by product specialists. Daily meetings with teams and team leads, coaching. Review of results with management team, agreeing on structure and activities for the next two weeks.
Day 11 & 12 – More work! By now all involved people are experiencing how learning and change is taking place by doing it, hands-on coaching in action!
Daily meetings with teams and team leads, coaching. Depending on the status of the requirements list: coach refinement of the requirements, coach estimating. Considering release planning with the management team.
Day 13-15 – Support form (on-site or remote) to be decided based on state of the team, state of the iteration, amount of hand-holding needed.
Day 16-18 – Support form (on-site or remote) to be decided based on state of the team, state of the iteration. Make a decision on release planning (medium term planning).
Day 19 – On-site coaching, evaluate readiness for next iteration with the teams. Coaching of requirement refinement (getting to “ready”) when needed.
Day 20 – Iteration review, probably demo the results to all relevant people and discuss the delivered results. Agree on the impact of the results (or missing results) on the next iteration. Iteration retrospective, in the individual delivery teams, inspecting how collaboration went, how the process is working out and whether a different approach is needed in the next iteration.
In the afternoon, a full team review of the prior iteration, the state of the requirement list, the results of requirement refinement, the impact on the project of the review and retrospective meetings. Reviewing the definition of ready and definition of done. Getting ready for iteration planning on Monday.
Day 21, Monday – Iteration planning, with the same structure as day 6.
The coaching activities on the days after these initial weeks are to be determined – the coaching can continue if needed. Phone support is available. Likely days for coaching are:
Day 30 (last Friday of the iteration) – Coaching during review & retrospective.
Day 31 (first Monday of the next iteration) – Coaching during iteration planning.
Based on our experience we know that the above structure will give your delivery teams and management the support they need to get more productivity out of the agile delivery teams, and a better understanding of the do’s & don’ts in agile product delivery for all involved people.
The proposal for your teams, for your products will get an individual discussion with you, and a made-to-measure proposal. There is no “one size fits all” – hands-on coaching requires an individual approach, and a regular adjustment and tuning of the approach. Just like developing your product, no “one size fits all” plan, and regular inspection and tuning of the product and the progress.
Maybe you have kids and you taught them how to ride a bike. Walking next to them, making sure they don’t hurt themselves. Picking them up when they tumble over. And you stopped walking with them, you don’t want to walk till they can drive a car. The same goes for us: we don’t want to be longer in your teams than necessary. We will keep an eye on you, you will make mistakes, and we have taught you and your people how mistakes are discovered early, and (most importantly) how the mistakes are addressed.