Team Philosophy

While every team make up is different and this changes per company and culture, there are a few general guidelines I follow:

• I am a team member - no more or less important than anyone else on a team.
• I am involved with the team. While I don't need to always be the person writing the stories, I do not believe in passing work over a wall.
• Everyone on the team is important and should have the psychological safety to contribute towards completing our team goals.
• Everyone on the team deserves to know the big picture of what we're working on and why.
• I have strong opinions loosely held - I am more than willing to acknowledge that I don't always hold the best ideas.
• The best performing team is a focused team. I help ensure team focus by doing the following.
  • Try to get the work to align with specific sprint goals (in Kanban, this is more represented as rolling themes).
  • Reduce the amount of work in progress (WIP) features the team is working on at any one time.
  • Protect the team to prevent interruptions.

Agile Practices and Agility

I’ve been a part of creating, releasing and supporting software solutions since graduating from college in 2011. In that time, I have seen many iterations of how to structure the process around making software. A lot of times, this manifests as an Agile™️ Practice - Scrum or SAFe or Kanban. Sometimes, it doesn’t. Lately, in the US, it’s not a given that the company follows Agile practices.

I can follow any practice, and any practice that is followed is a good practice. I can help teams introduce different things that can positively affect their transparency with the business and their ability to output more. However, I don’t have to call it Agile.

The items listed below have roots in Agile practices, and they are the most common things I introduce or enforce when working with a new team. Again, usually to positive acclaim and resulting in a more productive working team.

Ready to Start (small features/stories)

It's essential that a development team has a defined and communicated Ready to Start criteria. While I'm willing to adapt to any given criteria that a team already has, I'm a big advocate for including the following:

• At least one developer should look over a story in-depth before it enters work. This is to ensure that any prerequisites for starting the work have been met, and the story is ready to be estimated. This also encourages more ownership for the work on the team.
• Stories should be estimated by the larger team before working on in a sprint or kanban queue.
  • Estimation can be points-based (most common), tshirt sized or even rated in terms of simple/complicated/complex. The emphasis is not on what the estimation is, but that the estimation is standard and understood.
• If any story or small feature has not met the agreed-upon ready to start criteria of the team, it should not be taken for work.
  • As a product manager, it should be my job to find out how I can help to unblock stories so they can be ready to start.

Ready to Start (larger initiatives)

This, like the Ready to Start criteria for smaller features/stories, is likely to vary from company to company, team to team. It's important to have a good sense of the technology and the company culture to truly identify how and when large initiatives are ready to start. However, here are some tools I have used at companies in the past: