AgileSHIFT Online Learning
The course is part of this learning path
AgileSHIFT isn't designed to replace other project management methods and frameworks like Scrum, PRINCE2 or Kanban. It provides a simple, flexible framework that enables a team to work in an agile way by focusing on iterative working that delivers incremental change. This module looks at how an AgileSHIFT approach can be put into practice through the AgileSHIFT workflow. It then looks in detail at an iteration and review the activities within it.
The objectives of this course are to provide you with and understanding of:
- Key stages of the workflow – the trigger, start-up, the iteration and close-out
- The AgileSHIFT Iteration in detail – iteration planning, the daily stand-up, the value demo, the iteration retrospective and canceling an iteration
The target audience for the AgileSHIFT qualification is any employee of an organization that intends to adopt AgileSHIFT. This includes people who will become champions of the new working practice and employees from any part of the business who will contribute to the incremental improvements that will make up the wider change the organization requires.
There are no specific pre-requisites to study the AgileSHIFT course or for entry to the examination.
We welcome all feedback and suggestions - please contact us at firstname.lastname@example.org to let us know what you think.
In the last video we introduced the AgileSHIFT iteration within the overall workflow. In this video we’ll look in detail at the activities in an iteration.
AgileSHIFT isn’t about replacing other project management methods like Scrum, PRINCE2 or Kanban. It provides a simple, flexible framework that enables a team to work in an agile way by focusing on iterative working to deliver incremental change.
So, at the center of this approach are iterations, where a team works directly on a product or service, or enables that work to be done. An iteration has a fixed timeframe, fixed costs and variable scope. It starts with an iteration planning meeting to set up the work and then involves delivering the work (supported by daily stand-up meetings), before a value demo and retrospective at the end.
Let’s look at each of these things in more detail.
Once the iteration is triggered by the AgileSHIFT sponsor making a ‘go’ decision it’s straight into iteration planning. This is where the team to decide what it’s going to do in the iteration and how it’s going to do it – based on the what the sponsor says about the organization’s priorities, and the team’s knowledge and experience.
Around two hours should be spent planning for each week of an iteration. It should include the sponsor so they can describe how the value to the business should be optimized, and the coach to help the team and the sponsor work in the most agile way. However, the responsibility for planning rests with the AgileSHIFT team who must all agree and commit to delivering the planned activities.
The daily stand-up
Once the iteration has started, daily stand-ups help the team communicate regularly and co-ordinate their activities. This is especially important given the fast pace of the work and the commitment of the team to achieve the stated outputs.
Daily stand-ups aren’t designed to discuss problems and technical issues – they’re for team members to synchronize and co-ordinate their work. They ‘oil the wheels’ by providing:
A daily check-in where team members can demonstrate that they’re engaged in the work;
Clarity about the work each person’s doing and the impact it has;
An opportunity for each person to hear how the overall team’s performing; and
The mechanism to highlight any blockers to achieving the outputs, and discuss ways of removing them.
At the stand-up, each team member individually answers three questions:
What did I do yesterday and what have I achieved since the last stand-up?
What am I going to do today?
What could stop me – what blockers are in my way?
It can be a physical or virtual meeting and has a number of characteristics that make it different to other progress meetings:
All AgileSHIFT team members must attend;
The AgileSHIFT coach is an optional attendee but shouldn’t chair the meeting;
Other stakeholders can attend but shouldn’t contribute to the meeting;
The meeting should be time-boxed to around 15 minutes – allowing something like 2 minutes for each person to speak; and
It should start promptly at the same time every day.
Often, team members will need to collaborate to discuss how they can overcome any blockers and, to ensure the stand-up remains focused, these discussions should happen outside the meeting. The daily stand-up is a great opportunity for the team to come together and for a remotely distributed team to ‘meet by voice’, but it’s not the place to have a technical meeting.
The value demo
At the end of an iteration, the AgileSHIFT team uses the value demo to illustrate to the sponsor and stakeholders the progress they’ve made during the iteration. This makes the process transparent by:
Demonstrating the functionality, outputs and value delivered in the iteration;
Understanding whether the delivery meets the stakeholder’s expectations;
Finding out from the stakeholders if the context of the work or priorities have changed; and
Refining the items in the task list for the next iteration planning meeting.
The value demo should last for around one-hour per week of iteration, although some will be shorter. It will include the team members, the sponsor (who chairs the demo), the coach and any interested stakeholders.
At the end of the value demo another ‘go, no go or re-plan’ decision is taken. This follows the same approach as other decision points in the AgileSHIFT workflow where the sponsor decides whether to endorse the release of any work outputs and whether the organization should invest in the next iteration.
The iteration retrospective
Where the value demo’s about the product or service that was created in the last iteration, the retrospective is about how the team worked together, the processes they used, and what worked well or could be improved.
This meeting should last for a maximum of 45 minutes per week of iteration and be attended by the team members, the sponsor and the coach. It’s an opportunity for the team to be honest about their performance, and work with the coach and the sponsor to deliver increased value in the next iteration.
It should be a safe and comfortable environment for everybody involved and should answer the following questions:
How did the team perform?
How did the processes and tools help the team perform?
Are any changes required to any of the processes or the team?
What actions does the team need to take in the next iteration or after the work’s completed? and
Can anything learned be useful to others in the organization (or other organizations)?
Cancelling an iteration
Cancelling an iteration is a big deal and should only be done on the direction of the sponsor. The team might tell the sponsor that it’s time to cancel the iteration but the sponsor makes the final decision after consulting with the wider organization, customers and other stakeholders.
Cancelling an iteration can happen in one of two situations:
If the AgileSHIFT team no longer believe they can deliver the iteration goal; or
If a change in context means the goal will no longer add value to the organization or the customer.
The decision to cancel an iteration shouldn’t be taken lightly, but making the right decision is important – it relates to the AgileSHIFT principle of embracing change which also means being willing to fail positively.
About the Author
Tony has over 20 years’ experience in Business Development, Business Change, Consulting and Project/Programme Management working with public, private and third sector organisations.
He has helped organisations to design and create process and procedures to align ways of working with corporate strategy. A highly motivated and detailed solution provider utilising a wide range of methods and frameworks to provide structure whilst promoting creativity and innovation.
As a confident and self-motivated professional with excellent communication skills Tony is able to bring people together and get them working as a team quickly.
Tony is an Agile and Scrum trainer with a vast knowledge spanning IT Systems, Business Change, Programme and Project Management. With excellent presentation skills and a solid background, he ensures that all clients gain maximum benefit from his training. He has successfully guided those new to the industry through their initial training, helped experienced staff as they progress in their careers and worked at Director level advising on best use and practice, as well as tailoring courses to fulfil the exact needs of clients.