A very long and interesting chat with Steve St Jean triggered this post.
It’s a list of learning’s from our teams. Our journey, as a community, started a long time ago … 9 years and 11 months to be precise. We practiced Microsoft Solutions Framework (MSF), explored the CMMI Principles and Values, Agile Project Management, found harmony with Scrum and Kanban, and more recently started to embrace DevOps.
We toggled from no process to process overload, levelling out with a “less is more” mindset. We realised that it is important to create an environment and culture in which people WANT to collaborate, evolving into autonomous, self-organising, cross-functional and vibrant teams.
Autonomy gives our teams the freedom to organise and chose the best environment for themselves, within their typically less than ideal context (geographically distributed, part-time, uncommitted resources, etc.) and the rapidly evolving technologies. Vibrant teams naturally start working and planning across team boundaries … “as one”.
Sharing ideas and expectations with our teams, has proven far more effective and invigorating than telling them what to do.
Kanban has proven to be a good fit for our teams, giving them the flexibility ability to respond to change, and align themselves with the cadence of the rest of the organization.
Kanban board enables our teams to efficiently visualize, manage the flow of work, limit work in progress, and keep the definition of done (DoD) and checklists on one board.
Visual Studio Team Services, as a product, not only enable us to plan, track, and forecast our projects, but to continuously evolve our process as new features are released.
At the end of the day, however, it’s the people that make us succeed or fail as a team. Empathy encourages collaboration and learning, passion fuels the team’s energy, while motivation and time (bandwidth) enables the team members (people) to take ownership and deliver. If any of these pillars are missing, you typically end up with a stagnant board, lacking signs of ownership and progress.
Does this sum up our discussion Steve?
So, what are some of the related questions we answered recently?
- Why are we using a 3-week cadence?
We share a common cadence and “heart-beat” with the rest of the organization. It improves communication and simplifies planning.
- Why 1-3 features per release?
Based on reflection (empiricism), planning and tracking more than three features per release is ineffective within the context of our part-time teams.
- Why keep releases small?
“Ship today, make an impact and innovate tomorrow” is one of our core mantras and a product is typically split up into releases, each 2-3 sprints long.
We can always plan another release!
- Why are we (not) planning and using tasks?
For us, the planning, tracking and management of granular tasks has not delivered any benefit. Teams typically use tasks on the Kanban board cards as checklists.
- What’s SU0 and why are we there?
As one of the Canaries in the coal mine we are evaluating upcoming features, validating impact on existing solutions, and identifying potential issues before the public release.
Knowing what’s coming, helps us plan more effectively. The canary efforts ensure that we, not you, catch the issues.
Questions, ideas or feedback!
Add a comment below or ping us here.