Ways of Working
Training doesn't have to be a big bang, for example, in SCRUM the product owner decides the priority of user stories based on value, each sprint the development team take the top priority stories from the backlog and implement them, incrementally adding value to the product.
Ways of working training is designed to work incrementally too. Each iteration we work with the team during their retrospective, and decide on which training module would be of most benefit during the next sprint. We recommend that Ways of Working training is delivered on sprint transition day if using SCRUM. In this way the team is trained, pulling the most valuable training first while having minimal impact on their development days.
All modules are designed to stimulate discussion and debate. Where possible the modules include an interactive exercise or game to help learning goals. Each module concludes with a debrief.
Each Ways of working session is an hour long. Our consultant would also attend the team retrospective or engage with the scrum master to determine what training is most appropriate next.
We recommend one course per iteration, or every two weeks if using kanban.
The overall course length is open ended, we can offer training as long as the team finds it useful. We recommend purchasing six courses at a time. Typically teams benefit from six to nine months of this training.
- Scrum Master
- Product Owner
- Managers and stakeholders who want to learn more
Module Objective: to provide awareness of best practice, tools, techniques and pitfalls to help the team overcome their biggest current issue.
We have many prepared Ways of working sessions, however we strongly believe that the team should be trained and helped to overcome whatever is the biggest impediment that they currently face. When required we will prepare bespoke training.
Automated Acceptance Testing
Module Objective: to give an introduction to the concepts of Automated Acceptance testing using Behavior driven development (BDD) tools.
There are many different ways in which agile can go wrong, where behaviors that are well intended undermine the agile principles and reduce the potential benefits. This module looks at many of the common anti patterns and invites the team to discuss which if any are in play in their organization or team.
Module Objective: An in depth look at the daily standup meeting, with the objective of making everyone aware of the purpose of the meeting, roles and responsibilities and how to keep the meeting short and effective.
Definition of Done and Definition of Ready
Module Objective: To understand the objective and importance of the Definition of Done and Definition of ready as checklists that provide a quality gate for stories entering and leaving the sprint. We write or review the teams definition of done and definition of ready. The result of adhering to a good DoR and DoD will be more efficient sprints.
Getting started and estimation
Module Objective: To understand how to generate estimate the initial backlog of user stories and generate a plan for the business.
This module takes the form of a story, following a team when they are tasked with performing initial planning and estimates for a bean to cup coffee machine. We follow the planning process that may occur at a quarterly release planning meeting. As well as producing a backlog of user stories we look at how to integrate the agile backlog with a traditional or critical chain plan that includes hardware and mechanical work items.
Test Driven Development (TDD)
Module Objective: To have a high level understanding of test driven development.
This module shows the team what test driven development is and explains very briefly why it is needed and how it works. The training includes a live demonstration of code being developed using TDD.
NOTE: This module is far too short to teach TDD, the objective is to raise awareness only. To learn TDD for embedded systems we recommend, and can deliver Wingman Software's Test Driven Development courses.
Module Objective: To understand how Kanban works and the benefits of a pull system.
This module is intended to help a team decide between SCRUM and Kanban for their development process. The module explains the origins of kanban, how it works, how it is different from scrum. Learning is supported by a Kanban game.
Module Objective: Understand the reasons for regular release planning and what is involved.
Release planning in an Agile workflow happens iteratively, perhaps quarterly, it takes a longer term view then sprint planning and is setting direction. This module helps a team to understand the reasons for release planning, covers objectives and responsibilities. The module includes an exercise to help reenforce learning.
Module Objective: Improve the effectiveness of the teams retrospectives
It could be argued that a regular effective retrospective is the most important aspect of Agile and yet so many teams either don't run regular retrospectives or don't find them effective. All to often the same issues are raised again and again and little is achieved. This module aims to change that.
This module starts by listening to what the team thinks about their current retrospectives. We then share tips, resoures and techniques for making retrospectives fresh and effective.
Risk Management with Agile
Module Objective: Identify how risk is best managed in Agile development.
The modules reviews waterfall risk management techniques and also Agile risk management and questions if it is an either or solution or if a combined approach is more beneficial.
Self Organizing Teams
Module Objective: Understand what self organizing teams look like and the benefits that they bring.
The eleventh principle in the agile manifesto states
The best architectures, requirements, and designs emerge from self-organizing teams.
Why does it say this? What does it mean? This module explains the benefits of self organizing teams and challenges the team to consider if they can become more self managed.
Module Objective: Understand what story points are and how using story points can improve estimation.
Story points are a relative measure of the 'size' of a user story. This module looks at why using story points leads to better estimates and less time estimating. The module covers:
- What story points are
- Estimating in Story Points
- Planning Poker
- Story point ruler
SCRUM team guidance
Module Objective: Understand what are mandatory elements of SCRUM, and what is optional
We have observed many teams that say they are doing 'SCRUM lite' or similar, where the team have dropped some (or all) of the scrum process to develop their own lightweight version. While we believe that an Agile team should follow the agile principles rather than rigidly follow a particular framework, we observe that often teams are missing out on the benefits of Agile by dropping scrum practices and not replacing them with something that gives the same benefit.
This module goes though the ceremonies and responsibilities of SCRUM and gets the team to question if their current process gives them the benefits scrum does. We investigate what is missing and why. The team may be challenged to restart some aspects of SCRUM.
Module Objective: Technical Debt is a sore topic in many companies, what can be done about it.
In this module we explore if debt is inherently good or bad, we try to define technical debt. We consider the costs ff technical debt, the costs of servicing the debt and the cost of repayment. We look at effective strategies for repayment of technical debt.
Module Objective: Understand various types of testing and how they should be applied in iterative development.
In this module we look at why we test, what are our objectives and what are the costs of testing vs not testing. We discuss many different types of testing, Unit, Integration, Acceptance, Manual, Other. We look at common problems and discuss the agile approach to testing.
This is a challenging module that we recommend managers also attend.
Module Objective: Understand User Stories, their lifecycle and how to create them.
User stories are a key part of agile. Specifying a development in terms of items that bring user value. This is a big shift from talking about features and functions, it has a big impact on how development progresses.
This module explores what user stories are, what benefits they bring and how to write user stories. The module includes an exercise in story writing.
We recommend stakeholders attend this module.
Module Objective: Look for small incremental gains that a team can make.
The real objective of this module is to get team members to start to share best practice, our consultant will share tools and techniques that they have found make their day to day work more productive. Each team member is challenged to share one tool, technique or resource that they have found makes them even a little more productive.