Project Planning Archives

Waltzing with Bears is one of my favorite reads. It has become essential reading for anyone leading projects. It’s honest and pragmatic, providing evidence for the need and power of good risk management for project planning.

Rating

(Higher is better, 5 is neutral)

Would I recommend? 10 / 10
Did I learn anything? 9 / 10
Did I learn anything I can apply? 9 / 10
High Information density? 10 / 10
Would I re-read? 8/10

Buy Waltzing with Bears on Amazon

Waltzing with Bears Overview

Waltzing with Bears takes us through the journey of Managing Risk on Software Projects. It starts out analyzing what Risk really is and why it matters. Then it transitions into demonstrating what we can do about it, how to talk about it, tools we have, mitigation methods, and common pitfalls. It shows how analysis of risks & their probabilities can inform the probability curve of delivering a project

Ultimately Waltzing with Bears advocates for being open & honest about what on a project we can control, thinking about what risks we can mitigate, and how we can more realistically plan projects while including uncertainty.

Who should read Waltzing with Bears?

Every Project Manager, Product Manager, Head of Engineering, and Senior Engineer. It will shift how you think of projects and give you the tools to stop guessing about projects and start projecting realistic projects.

My main takeaways

Don’t ignore project risks. Risks make us more self aware and not count on ‘luck’ or ‘stars to align by chance’. We can eliminate a good portion of guess work.

We can use math to quantify risk asses its probability of impact on a project delivery dates or outright failure.

Deadlines dates are a bit of a myth. Instead a distribution confidences for completion is more realistic when Planning Projects and Road Maps.

Just because you wish / hope / believe that things will go perfectly, doesn’t mean they will.

If you did no diligence in checking for risks, and a project goes perfectly, you are just as guilty as someone who knew of risk and did nothing about them. See Ethics of Beliefs.

5 most common items that impact software project timelines: Scheduling Flaw (ill informed project timeline), Requirements Inflation (additional unplanned work), Turnover (staff leaving), Specification Breakdown (ignoring agreeing upon what/how key items are built), Under Performance (low/high throughput by team).

Riskology Worksheet is a great way simulate these risks impacts on a project.

If you liked this book, next I’d recommend

On team culture: Debugging Teams

You know how 2 week sprints are the de-facto go-to pattern for many teams? I don’t believe they are the best for teams and we should all consider 1 week sprints instead, and I’ll tell you why.

The Downfalls of 2 Weeks Sprints

Longer meetings to plan for 2 weeks
Need more Context
Hard to estimate how much work can be accomplished
Over commitment is easy
Doesn’t accommodate changing requirements
Doesn’t accommodate newly discovered scope as well
Doesn’t accommodate surprises that pull for attention away from the team (support, external teams)
Can create anxiety when falling behind, especially considering work remaining
PMs have less certainty on sprint progress
Slow feedback cycle

The Upsides of 1 Week Sprints

Tighter feedback loops
Shorter meetings
Allows team to be more precise in their commitments
Forces team to think about the now (highest priority).
If scope or focus change occurs, only interrupts 1 weeks worth of work.
If over commitment occurs it is smaller and easier to correct.
Generally feels more exciting, each week starts anew.
Weekly routine lightens the mental load

Won’t 1 Week Sprints have more meetings?

Since we have only one week to plan for, we must have more meetings, and this take more time right? Surprisingly you’ll spend less time in meetings!

Touching base on a weekly basis there are fewer surprises and thus fewer ‘new’ topics that need to be introduced.

For instance, when we are driving a car, it’s natural to drift a little side-to-side within our lane. But, instead of large jarring adjustments every minute, we make many frequent little adjustments keeping us centered on the road and therefore moving smoothly around every turn along the way.

Similarly, frequent touch bases are simpler and shorter, and therefore also keep the team in sync moving smoothly through their work.

Now let’s take a look at what a 1 week sprint schedule might look like.

The 1 Weeks Sprint Schedule

Here is what a possible 1 week Sprint Schedule could look like.

Outside of this schedule there still may be additional team meetings such as Project Planning, Project Kickoffs, or Planning Quarter Roadmap.

A week calendar view showing the meetings on each day including standups, grooming, retros, and demos. There are only 6 meetings displayed in total. Standups shown every day at 10am, three of which are longer in length because they include Scope, grooming, and demos. Retro remains it's own meeting. — A sample 1 week Sprint Schedule

Standup (15min) – Everyday at the same time, occasionally bundled with other team meetings.

* Touch base to talk about work in progress
* Update team members of any changes or needs

Week Scope (30min + 15min Standup) – The kickoff for the week.

* Review Previous Sprint metrics, work completed
* Review Previous Sprints remaining stories that will cary over to this weeks sprint.
* Define the weeks big picture focus for the team
* Pull in new stories & Prioritize them
* Pull in/out stories until matches teams throughput (don’t compromise and over commit!)
* Confirm the scope committed to
* End with Standup

Grooming (15min + 15min Standup) – Looking forward to future work and estimating stories

* Start with standup
* Introducing upcoming work & projects
* Breaking down, defining, and estimating stories
* Delegating project leads for spike work

Retro (30min) – How can the team improve

* Depending on how well the team is running this can be every 2 weeks instead of every week.
* Retros should always focus on how the team can improve to become the best team.
* Retros can be sometimes heavy. Therefore Thursdays tend to be best to avoid ending the week with any weight.

Demos! (15min + 15min Standup) – Celebrating the weeks wins!

* Start with Standup
* End the week with great for team morale
* An open form where any team member may share work (in progress or completed) from the week
* Great for knowledge sharing
* Ends the week on a high note.

(expand each section above for a detailed description & structure)

Bundling Team Meetings with Standup

Folks tend to prefer fewer meetings. A clever tool to utilize – combine meetings together that have the same or similar attendees.

In the sample 1 week sprint schedule above, we’ve combined Weekly Scope, Grooming, and Demo meetings with standup. This takes 9 meetings down to 6. Everything is simpler and lighter.

Summary

It’s worthwhile to consider switching your team to 1 Week Sprints. They will give your team more energy and more accurate commitment to their work. 1 Week Sprints will set your team up for even better success.

What does your team use? Would you ever switch?

(cover photo credit: Jonathan Stassen / JStassen Photography)

Thoughts

Tag Archives: Project Planning

Waltzing with Bears – Book Review