I did the Agile PM course by google on Coursera... You should too!

I absolutely loved this course. I learned so much about things I already practice at work and new principles. As someone who has been in agile environments for a while, this was very enlightening & insightful. It was nice seeing things I had learned on the job in theory & also seeing that I was doing a couple of things wrongly. My favourite parts were the tips from the PMs at google. Here’s a list of 15 things I learned:

1. The Agile manifesto is based on 4 core values that value individuals and interactions, working software, customer collaboration, and responding to change. Agile is about delivering value in a world with a high degree of uncertainty, risk, and competition. the term VUCA is an acronym that defines the conditions that affect organizations in a changing complex world. Volatility, Uncertainty, Complexity, Ambiguity.
2. Different methodologies under agile: scrum, kanban, XP, Lean, Lean Six sigma. Kanban is famous for the use of kanban boards to classify the progress of a project as todo, in progress, or done. there is also a Work In Progress Limit(WIP limit) that ensures the amount of work in progress is limited to what the team can handle. Lean methodology is for improving project outcomes. You start by defining value based on what the customer wants, map the value stream, create a flow, establish pull and pursue perfection.
3. Scrum is the most popular and is founded on the scientific theory of empiricism: True knowledge comes from actual lived experience. While using scrum, one has to ensure that decisions are made based on real experience and hard data! 3 core pillars of scrum: Transparency — Making work visible to those responsible for the outcome, Inspection — always checking in on progress & deliverables to detect any undesirable change and Adaptation — Continous search for ways to adjust project, process, and product to minimize issues.
4. The scrum team should work with these 5 values: Commitment — everyone takes responsibility for the project and its outcomes, Courage — The courage to do the right thing and work on tough problems, Focus — as the name implies, all team members are focused on delivering value, Openness — everyone should be open about all the work and challenges encountered, Respect — teammates respect one another and work civilly. I work with two project teams and I think we embody respect, commitment, openness, and focus. In one of the teams, we might be lacking the courage to work on tough problems as it is a very sensitive project and everyone really just wants to avoid issues.
5. There are 3 roles in scrum: (The scrum master who facilitates and coaches the scrum team, Product Owner who ensures the team is building the right product or service & Development team who do the work to complete the product/service). I currently work with my colleague as a product owner in one project and a product owner and scrum master in another due to a lack of resources. They are both interesting roles to take on and all require a lot of people managing & organizing.
6. This point will just talk about some scrum terms that are commonly used. Product backlogs — a single authoritative source for things a team works on that is managed by the product owner. User stories: a short simple description of a feature told from the perspective of the user. User stories have a user, the action taken and the value gotten from said action. They should follow the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Personally had issues writing independent user stories. The QA on my team had to point this out to us during backlog refinements multiple times as our stories were always dependent on multiple factors and had multiple steps that could be further broken down to independent stories. Acceptance criteria — a checklist to decide whether a user story is done.
7. Some more terms: Backlog refinement is the act of keeping a backlog described, estimated, and prioritized. In scrum, estimation is done relatively i.e comparing the effort it will take to complete a task to the effort it will take to complete another task and that becomes the estimate. Examples of relative estimation methods are t-shirt sizes & story points. Not sure how to explain this further, read up on relative estimation and relative estimation methods if interested. Velocity is the amount of work the team can complete in a sprint. The team uses their average velocity over multiple sprints to find out how much work they can take on. A burndown chart measures how time against how much work is done and the amount of work remaining.
8. There are 5 core scrum events. The sprint — a short timeboxed period where the team works to complete a set amount of work, typically 1–4 weeks. Turns out you can cancel a sprint if the sprint goal becomes obsolete. Sprint planning — the team comes together to confirm their capacity for the sprint and define sprint goals and also agree on the backlog. Daily scrum — 15 minutes or shorter daily meeting within a sprint to discuss work done the previous day, todos for the day & challenges if any. Sprint review — The product is demonstrated and it’s mostly for inspection and discussion and to check completed work. Sprint retrospective — held at the end of the sprint to discuss what went well, what didn’t and how to improve the next sprint.
9. My favourite thing so far was learning about value delivery. Building the right thing, building the thing right, and running it right. This covers understanding what customers want and building that, building approved features, and thinking through how the user will interact with the product once delivered. It’s not about delivering a perfect product, It is about being good.
10. There was also an emphasis on the need for a value roadmap. A guide demonstrating where to go, how to get there & what to accomplish along the way. The roadmap has to have a product vision, product roadmap, and a release plan. In relation to my work, I think we lumped the vision in the BRD document for the projects created separate documents for our project roadmaps and the release plan. Avoid the pitfalls of letting stakeholders think the roadmap is set and unchangeable and don’t spend too much time fine-tuning delivery dates.
11. I think one of the core skills needed to be an Agile PM is leadership. The course had extensive insights on being a leader & influencing your team to achieve success. Using the six sources of influence — Personal motivation, personal ability, social motivation, social ability, structural motivation, structural ability, one can make considerable progress, form, and manage the amazing team they want!
12. An amazing section also covered agile team challenges. There could be value delivery issues, business collaboration issues, and problems with team dynamics and culture e.g excessive conflict between team members, team burnout, low morale, lack of trust e.t.c. There can be issues with managing the product itself e.g managing a stable roadmap or lack of team stability
13. Briefly learned about DevOps and Agile frameworks to address the needs of large initiatives e.g Scrum of scrums, Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD) e.t.c. I had never heard of any of these things and it was pretty cool to see how agile can be scaled especially for large corporations. there was even a reference to the Spotify model of delivering products. I’m telling you guys! this course is worth every dollar.
14. Finally, one of my favourite lines from the course: “Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. Quality cannot be inspected into a product or service; it must be built into it.” — W. Edwards Deming © Scaled Agile, Inc.
15. To wrap up, one of the PMs at google said: ‘’you are going to make a ton of mistakes. That’s okay. You can’t learn if you don’t make mistakes” This resonated with me because my colleague and I have made so many mistakes! some fatal, some not as much. what matters is we are giving our all and remain committed to delivering value to our users and all stakeholders.

Please consider taking this course if you are a newbie in an agile environment or you are just interested in learning about agile generally. This is one of the best resources I have learned from. Again, worth every dollar! Here’s the link: 👇🏾

Agile Project Management

PS: These are just highlights of the course and there were many other things covered that arent listed here.