40 mins (20 mins slide deck / 15 mins break out /5 mins questions & close)
To help trainees learn about the importance of Agile
To help trainees identify their current coping habits
To support trainees in developing resilience strategies
Why project management is and what we “used” to do
What Agile is and (briefly) what Agile is not
Where you’ll see Agile in the real world (i.e. job ads, day-to-day life etc.)
Overview of Agile (SCRUM) in practice
Understand Agile and why it’s important
Understand the link between the workload management and the framework Agile gives you to cope with workload, stress avoid burnout etc.
Show practical steps of why Agile framework gives you the tools to be resilient
Intro. Talk through the aim and learner outcomes (see above)
Context. Talk through that paid professional software development comes with a raft of related activities and commitments for any business (mention Sales, Marketing, Finance teams all working on the expectation of a release/new product). Therefore a structure is needed > project management
Project managers saw large software projects as complex delivery for consumer (user) facing products. They borrowed from what worked well elsewhere at the time (e.g. the car industry). Mention “Waterfall”.
But: Software is different. It’s immature. It’s not constrained by the same limitations as manufacturing. The tooling isn’t as precise. This leads to problems (lack of early testing, user ability to articulate) - focus on time. Length of projects easily 12-24 months.
Enter the Agile Manifesto. Discuss quote. Uncover the ‘hands-on continuous improvement’ ethos. Mention it’s there on the web to go and read.
Review the four values. Mention the some/all 12 principles
Customer satisfaction is P1
Deliver little and often (hammer home 2 weeks vs 2 years)
teamwork; empowered teams
conversation over documentation (link to PD skills)
Sustainable development (links to resilience)
Continuous technical excellent & design agility
Simplicity (we’ve mentioned this in a number of PD areas)
Reflect (continuous improvement, coping)
Describe broadly what this will mean in the real-world of job ads (see slide). Drumroll into the most popular and today’s deep dive:
Talk through the process and the timelines
PO creates user stories (requirements) on the product backlog (“to do list”) (mention they need to know these terms)
Team plan ahead of sprint. Team agrees on a goal, builds it and ship it.
Mention daily SCRUM. Retros/Review
Talk about similar processes they’re doing now. Link the resilience/coping baked into the process and the values again
Benefits - talk about working on the right things at the right time. Re-mention speed, customer satisfaction, reiterate benefits over waterfall.
Focus on what this means for them as a professional software engineer. The five stages of the deployment that are expected to be involved in. They won’t be isolated from the world around them, they have to engage and the PD skills they’re learning will all be used.
Mention Agile is not an excuse for chaos. Each team is slightly different and teams change so: some process, some docs. Pros don’t build what they want, they work to customers' instructions: dont; work unless paid, so what’s asked. (mention fail fast here if appropriate)
Intro hands on breakout; Planning. Estimates.
Talk through the example and how it’s going to work. (see slides).
Talk through you thinking in making different estimates per person (i.e. Jamie’s a runner, Mubean and Joel are slow etc etc.)
Reiterate that they all UNDERSTAND what it takes to walk a mile
Emphasis on teams having to post their estimates in reply to the Req posting BEFORE they move onto the next requirement.
Games rules: see slide. Post the first requirement (Slide_Req1 below) us (same as the walkthrough)
Wait for teams to post the individual + team estimates in the channel (Or wait 3-4 mins N.B. adjust to time constraints)
Post Slide_Req2 - wait 3 to 4 mins again
Post Slide_Req3 - wait 3 to 4 mins, bring room back
By the end each each should have individual & team estimates posted in reply to the Slide_Req* images in Slack.
N.B. The teams are allowed to ask questions and get clarification (as you would in real world) but don’t offer it at it’s a talking point after
Talk through the team estimates. Highlight wild variances. Ask about reasoning from teams. You should uncover some common issues with estimating that they need to be aware of (see 32).
Extra if time:
Invite ideas of things that might change estimates):
Changing Requirements. ...real world problem adding ‘risk’
Not Enough Information. ...this is assumptions
Testing failures ...redo = more time
Technical Skills. ...carrying 3 suitcases easy for some?
Lack of Communication. ...Did anyone ask questions?
Definition of done… how did people know when they’d reached a mile?
You might also mention that estimate essentially contains 3 things:
Amount of Work
Risk and Uncertainty
Mention that estimates are relative and in the real world we consider relative effort, not time as a better measurement but this is not for today
Close. Reiterating what we’ve talked about with Agile is the tools to cope with the reality of real world professional software development. This is the foundation of coping & resilience plus it guides rapid development with high customer satisfaction.