These are just some notes I jotted down while taking an online course, primarily to help me remember the key ideas and valuable takeaways. They’re not meant to cover everything or act as a full summary. If you find them interesting or helpful, maybe they’ll nudge you to check out the course too.
The Agile Project Management course is one of the six courses in the Google Project Management – Professional Certification course offered on Coursera. The Agile Project Management course takes 4 weeks to complete. You can take the course for free but will have to pay the course fee to obtain a certificate from Google.
If you have project management experience in an engineering design or construction company and would like to learn about agile project management, this course can be valuable. If you are working in a software company and have already worked on projects using agile concepts and work management platforms like Asana, then the course can be a good refresher or help you reinforce your understanding of agile project management.
The course is well-paced and the instructions are clear and easy to follow. The course uses a scenario where you have to help an example company apply agile and scrum concepts to develop their product and sprint backlogs. These exercises help you learn and remember how to apply agile and scrum. The course also introduces you to using Asana.
The case study example on how Spotify has implemented agile is very interesting. Videos on how Spotify has implemented Agile are available on Youtube. The course also includes a few interviews with agile practitioners.
A few notes
- Note 1 : Agile and Waterfall – Agile was created in response to the Waterfall process in order to embrace the reality that business needs and user requirements are often uncertain and unpredictable. The Waterfall approach is linear and sequential and does not encourage changing up the requirements once design and development are started, whereas, Agile, is iterative, flexible, and incorporates necessary changes throughout the design and development process. If your project environment has high levels of VUCA – Volatility, Uncertainty, Complexity, and Ambiguity, then it’s a good sign that you should consider an Agile approach.
- Note 2 : Project Aspects – Waterfall and Agile handle the three important project aspects – Requirements, Documentation and Deliverables differently. Requirements are fully defined for waterfall and approved formally versus more dynamic and expect to evolve as the project progresses for agile. Documentation is exhaustive, covered in large quantities and passed down to different teams for waterfall versus fewer documents focusing on tasks with an emphasis on regular discussion within the team for agile. Deliverables are released at the end of a project phase for waterfall versus smaller and more frequent releases of deliverables for agile.
- Note 3 : Agile concepts – The Agile method manages a project and the project team using the Agile Manifesto as a guide. The manifesto is a collection of 4 values and 12 principles that define the mindset that all Agile teams should strive for. The four values are
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- Note 4 : Scrum – Scrum, the most popular Agile framework that brings the Agile philosophy and mindset to life. The Scrum Guide defines Scrum as “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
- Note 5 : Scrum concepts – Scrum has three pillars – Transparency, Inspection and Adaptation and five core values – Commitment, Courage, Focus, Openness and Respect. Successful teams follow these pillars and core values. The three Scrum artefacts are – Product backlog, Sprint Backlog and Product Increments (also called sprints).
- Note 6 : Scrum Teams – Scrum Teams are self-organising and a scrum team consists of three defined roles: a Scrum Master, a Product Owner, and the Development Team. The Scrum Master manages the scrum team and is responsible for “building the thing fast” and defining when a team will complete a product release. The Product Owner is responsible for what a team builds and ensuring that the team “builds the right product”. The Development Team is responsible for “building the thing right” and delivering the product.
- Note 7 : Product Backlog and Product Goal – The Product Backlog is an ordered list of tasks for the team to improve the product and meet the long-term product objective – the Product Goal. The product backlog is owned and managed by the Product Owner.
- Note 8 : User Stories – User stories are used to capture and manage product backlog items. User stories are made up of three different elements: the user, the action they will take, and the benefit to them. A collection of user stories is called an Epic. User stories should meet the I.N.V.E.S.T. criteria: Independent, Negotiable, Valuable, Estimable, Sized and Testable.
- Note 9 : Effort Estimation – To estimate the effort required for each product backlog item, Scrum uses relative estimation (comparing different tasks), instead of absolute estimation (time and resources for each task). There are two popular relative estimation methods – T-shirt sizes and Story Points.
- Note 10 : Sprints – All the activities that have to be performed to move towards the Product Goal happen within Sprints. Sprints are fixed length events – typically one month or less, to reduce complexity and effort and mitigate the risk of the sprint goal becoming invalid. The Sprint is one of the events in Scrum and contains the four other Scrum events – Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective.
- Note 11 : Sprint Planning and Sprint Backlog – For Sprint Planning, the entire Scrum team meets to confirm how much capacity i.e. time and resources are available during this Sprint and identify what items from the Product Backlog will be done during the Sprint. This becomes the Sprint Backlog for the Sprint. The consolidated view of the sprint backlog items that align with the objective of the Sprint is the Sprint Goal. “Definition of Done” refers to an agreed-upon set of items that must be completed before the sprint backlog item can be considered complete.
- Note 12 : Daily Scrum – This is a daily face to face meeting of the Scrum team and is facilitated by the Scrum Master. The Development team discuss priorities and synchronise activities for the day during the meeting.
- Note 13 : Sprint Review and Product Increment – The Sprint Review is a meeting held at the end of the Sprint with the entire Scrum Team and facilitated by the Scrum Master. During this meeting, the product is demonstrated to the Product Owner to determine which aspects are finished and which are still work in progress. The Sprint Review is also when the team members unveil what is called the Product Increment. Only items that have met the “Definition of Done” are considered part of the Product Increment. Anything that is not done goes back to the Product Backlog.
- Note 14 : Minimum Viable Product – A Minimum Viable Product is a version of a product with just enough features to satisfy early customers. A product is releasable when the team has developed a Minimum Viable Product.
- Note 15 : Sprint Retrospective – This is a meeting held with the Scrum team and facilitated by the Scrum Master at the end of the Sprint, to take a step back and reflect on what’s working or not working in terms of people, processes and tools and identify improvements that can be applied to the next Sprint.
- Note 16 : Coaching vs Managing – A Scrum Master has to be able to adapt a Managing style – characterised by one-way communication to assign tasks OR a Coaching style – that uses open communication in both directions to help develop each team member’s skills. .In Agile and Scrum, a coaching style is usually the best initial option and when done right, will help the team become self-sufficient and hence more agile.
- Note 17 : The Influencer Change Framework – The three keys to influence in order to change behaviours and achieve measurable results, as researched by the authors of the book INFLUENCER: The New Science of Leading Change , are to clarify measurable results, find vital behaviours, and use the six sources of influence – Personal motivation, Personal ability, Social motivation, Social ability, Structural motivation, Structural ability.
- Note 18 : Agile Scaling Frameworks – The course covers five frameworks that can be used as guides to scale the Agile approach to address the needs of large projects. These are Scaled Agile Framework (SAFe), Scrum of Scrums, Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), and the Spotify Model.