Notes on Agile

The concepts in a nutshell

  • You don’t often get it right the first time!
  • Agile frameworks help you find the source of the problem quickly through frequent testing. And even better, it gives you to the tools to solve it because you have involved the right stakeholders continuously.
  • Agile Project Management is about embracing a servant leadership mindset. It’s about understanding self-organizing teams and the interaction between all the roles contributing to the development process.
  • In an agile project you set-up high level requirements based on priorities and value to the business
  • Deliver regularly, deliver early, gain fast feedback, identify failure fast and adapt solutions accordingly
  • It’s not about defining and getting it right up front, getting the business to commit upfront, it’s about engaging with the business throughout the project
  • Focuses on collaboration and transparency with the business through regular engagement and review getting a better solution closer to what people are going to use, you don’t end up with functionality that’s going to be thrown away or seldom used.
  • And it’s about encouraging collaboration and discovering innovative solutions.
  • Flow, automation, high technical standards and knowledge sharing in long standing teams is necessary for Agile to succeed.
  • The iterative development framework of Scrum with the inspect and adapt loop has proved to work best for ‘new’ projects where there are unknowns.

Assessment essential for any Scrum team

Courses and Open Assessment on –  Ken Schwaber (there are also very good free practice tests)
  • Scrum Open (basic scrum knowledge)
  • Product Owner Open
  • Developer Open (for testers too)

Professional assessment from – Passing score > 85%  ($150)

  • Professional Scrum Master 1
  • Professional Scrum Master 2
  • Professional Scrum Product Owner
  • Professional Scrum Developer (includes Testers)
Also similar assessment by Scrum Alliance – Jeff Sutherland

Must reads

The above can be read in an hour (this should get you to 70% of the level 1 assessments).
To understand the concepts for the assessment a two day course is ideal or alternatively you could read two or three books here  or the ones below and that should take you to 95%. 
This is obviously just the start and a real understanding will take a couple of years experience. The second level PSM2  comes highly recommended for the practitioner around the 2 year stage of their journey.

The Enterprise and Scrum 
by Ken Schwaber 

  Scrum: The Art of Doing Twice the Work in Half the Time 
by Jeff Sutherland 
Link:• Essential Scrum: A Practical 
Print & Audio book

The Phoenix Project book isn’t essential for passing the assessment but it’s such a great book on Agile it comes highly recommend.
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win 
by Gene Kim et al. 
  • Print & Audio book

Agile Concepts

  • Empirical Process Control.
  • The three pillars of Scrum.
  • Controlling flow, pull and trust.
  • Sustainable pace and empowered team
  • Definition of Ready – the ‘Approved’ to work on state – this is just enough information to start the development team work as we know detail will emerge.
  • Visualize the work flow in its entirety to manage it at the multi-team level necessary when teams have multiple overlapping projects or share BAU, Identify and monitor bottlenecks / queues (Lean manufacture), remove the columns in Kanban such as ‘In Code review’ when this column becomes empty (due to increased pair programming and collaboration and team responsibility).
  • Definition of Done – developed by the team and PO, it should evolve/improve – Done CC, Done QA/BA/PO/SH, Done (in prod)
  • Regular face to face communication, co-location and approachable team members.
  • Teams improve faster than individuals by factors of 1000 Jeff Sutherland  “Scrum: The Art of Doing Twice the Work in Half the Time“.
  • Always share ‘Genius!’ solutions with ‘any’ member of the team at ‘any’ time to constantly spread knowledge.
  • Minimize the size/impact/learning curve of every handover by phasing in parts for testers and POs to become familiar with new development a bit at a time. Always start with the three Amigos.
  • Automate the build, test and deploy process to allow for test environments to be automatically created daily.
  • Story Points: Why are they better than hours.
  • INVEST principles for user stories, story slicing use of Acceptance Criteria.
  • Minimum Viable product and Minimum Marketable Features.
  • MoSCoW – strongly encourage the POs to identify ideally 60% but no more than 80% must haves at the ‘release’ planning stage, to help guarantee the ‘must haves’. Must haves in a release might only be a must have in a sprint (as long as its not the last sprint!).
  • eXtreme programming practices, the development team should like these! TDD, re-factoring during story development, clean code, pair programming, code review and Tech huddles.
  • Remove single knowledge points
    • by pairing POs and Analysts
    • developers should document repeatable development or infrastructure configuration processes. Look for opportunity to automate everything!
    • Fix defects early in development and do this pairing a less experienced developer with a more experienced one.
    • Pair the initial and the last step of the code review process
  • Utilisation and slacktime –  aim for 65% developer utilization to make time for interruptions such as live defects and don’t forget time for process improvement, innovation and knowledge sharing – or you get much less done in the organization due to single points of failure and no time available for team improvement, you create a terrible environment for work, and, you create an environment of no innovation.
  • Keep developers diaries free in the afternoon to allow for time in ‘the zone’.
  • Effective retrospectives
  • Well defined story lifecycle encourages collaboration across the right roles at right times
    • BA/Business collaboration at Story Sign-off
    • BA/PO/QA/Dev at Story kick-off
    • BA/PO/QA/Dev at Story Volleyball
  • Team/Business at Demo
  • Scrum of scrums where cross team dependencies exist.
  • Agile QA process, high automated test coverage, continuous integration, automated deployment.
  • Agile coaching is about getting the most out of individuals or teams by raising their awareness levels, about their current environment, about the environment outside theirs, and most important of all, about their own potential. This is done mostly by asking them the right questions, and not by providing them ready-made answers. Types of coaching could be role based (PO, devs and testers) , process and organisational and leadership coaching for Dev Managers, PMs, Team leads, heads of..

What are the conditions that will help teams perform better?

  1. Stable Teams – (5 optimal size [3 to 9]) – learn there capacity predictable velocity.
  2. Yesterday’s Weather – capacity know don’t overcommit next time
  3. Swarming: One Piece Continuous Flow – reduce work in progress increase velocity for sprint.
  4. Interrupt Pattern: Illigitimus Non Interruptus – estimate all work and abort sprint when this unplanned work exceeds estimate incentivize whole company to minimise interrupting the team.
  5. Daily Clean Code – bugs fixed the same day as created take 24 times longer to correct 3 weeks later. 
  6. Emergency Procedure – sprint is going off the track – Scrum Master should abort the sprint or offload work.
  7. Scrumming the Scrum –  create a story form the No. 1 impediment and sprint plan it – “[Impediments] may deal with strong personalities, management impeding the Sprint, a variety of sticky human issues, creating better User Stories. These impediments should be treated like process improvements and should be resolved as quickly as possible.”
  8. Happiness Metric – listen to the members of the team.
  9. Teams that Finish Early Accelerate Faster – Teams running late can feel sympathy towards a desperate Product Owner, and accept more PBIs, than can be completed by the team. This compounds the problem and they decelerate. Teams can be optimistic about their ability to finish requested features. But in doing so, they fail to give themselves time to reduce technical debt and sharpen their saws. Thus they are doomed to a persistently slow pace.

Top 12 Failure Modes for Scrum

 • No stable teams or people not assigned 100% to one team 
 • Poor user stories, no clear definition of READY (bad product owner)
 • Taking too much into a sprint and failing to deliver working software
 • Daily meeting not replanting and removing impediments 
 • Not fixing bugs found inside a sprint, particular integration bugs 
 • Working on too many stories at once inside the sprint 
 • Failure to have a plan for interruptions or emergencies 
 • No clear definition of DONE 
 • Not executing improvements identified in the retrospective 
 • Overburdening team (bad management, no happiness metric)
  •  2014 Jeff Sutherland

Scrum Master Maturity


Kanbans and Story States

Less is more, the more state transitions (or stations) such as ‘In Peer review’ implies there are queues or bottleknecks in this ‘handover’, the column is required until the team start to regularly shout ‘review please’ and this review should not take longer than 30 mins. If no one is available then it can be identified at the daily standup and actioned accordingly. The board below explicitly indicated this queue. (The blocked column could also be indicated using a red sticker on the post-it or to simply invert it)
A Story board (stories move from left to right)

Vertical Organisational Transformation

  • Extend agile transformation both horizontally across teams and vertically through management.
  • Know the pinch points in the governance process  (inspect and adapt the operational model to optimise).
  • Manage cross team project dependencies ‘Scrum of scrums’ and higher level prioritisation and scheduling.
  • Product owner representation is necessary across all the portfolio.
  • Mapping the team capabilities to organisations portfolio of work.
  • Know all teams’ current work in progress and their current limits to manage.
  • Shared ‘valued’ metrics between teams, development managers and upper management.
  • Release strategy – continuous integration and deployment, release-on-demand.
  • Iterative release schedules are managed and sustained appropriately.
  • Manage cross project prioritisation and pull.
  • Shared terminology horizontally and vertically.

Horizontal (Team) Organisational Transformation

  • Visualise all BAU, Incremental development, support, maintenance, consultation and project work.
  • Shared Definition of Done for dependant teams contributing to a release.
  • Shared Definition of Ready to share a common expectation of how much detail is required before engineering can begin.
  • Standard estimation – shirt size to weeks conversion eg.
    • S = 1 week (for say 4 developers and 2 testers)
    • M = 2 weeks for the team
    • L = 4 weeks for the team
    • XL = 8 weeks for the team.
  • Standard sprint reporting to provide simplicity and transparency in the governance process.

Recommended Online Resources

Other recommended reading

  • User Stories Applied: For Agile Software Development – By: Mike Cohn
  • Test Driven Development: By Example – By Kent Beck
  • Agile Software Development Ecosystems
  • User Story Mapping: Discover the Whole Story, Build the Right Product – By Jeff Patton
  • Lean Software Development: An Agile Toolkit – By Mary Poppendieck
  • Agile Project Management with Scrum – By Ken Schwaber
  • Succeeding with Agile – By: Mike Cohn
  • Guide to the Most Popular Agile Process – By: Kenneth S. Rubin
  • Agile Software Development with SCRUM – By Ken Schwaber


• The Coin Game – illustrious small batches and flow 
• Draw a house game ( 
• Agile chair Game 
• Lego City game – 2 hours face to face

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s