20 questions to determine whether your teams are mature enough

With more than 26 years of experience, as a consultant, I help organizations in the .NET space to professionalize their entire software development efforts, from idea to production. During such visits, I get to scrutinize their development practices, quality standards, design principles, the tools they use, their deployment pipeline, the team dynamics, the requirements process and much more. In this series of short posts, I’ll share some of the most common pain points I run into.

In the previous post of this series, I’ve provided you with a couple of angles that can help you determine whether your architecture, your code and your documentation are a consistent whole. And with that, I completed the more technical part of this series of posts. In this final post, I’m going to change direction and talk about the predictability and maturity of your development team(s). Here’s a bunch of questions you can ask to help you assess the situation.

• Are your development teams already working under the principles of Scrum, Kanban or a combination of those, but they never managed to achieve a stable velocity? Do you think this a problem or do you think this in an inherent aspect of software development in general?

• Are teams struggling to break down the work in appropriately-sized chunks that allow them to work together using swarming or pair programming?

• Do you struggle trying to capture the more technical aspects of software development into (functional) user stories?

• Do bigger technical changes generally fit in a user story, or do they often tend to run over the sprint boundaries? And do you see friction in the original definition of what a user story is supposed to mean? Or do you apply ideas like skeleton stories or stories with project value to capture the technical work?

• Do teams know exactly what is expected before they start developing a feature? And do they also know what is expected at the end?

• How accurate and useful are your team’s estimates? Do you see a lot of deviations and extremes? Do they still try to convert the story points back to hours?

• Do you see estimates as a goal by itself? Or are their only value the fact that developers think about the size and complexity of the work so that they can create a decent work break down.

• What about sprint goals? Are these just ceremonies with artificial goals that usually end up being about delivering the most important backlog item? Or do they really make a difference to the focus a team has?

• How often are the stories almost ready at the end of the sprint? Is it this a common thing (like in many teams), or do team members really work together efficiently to deliver what was planned?

• Do your burn down charts also look like block diagrams or show steadily increasing work-in-progress? Or do yours really burn down in a gradual and predictable manner? And do you even look at them during the stand-ups to track and adjust priorities?

• Do you often notice that your teams start to loose focus from the most important backlog item that sprint should deliver? For example by working on lesser important stuff (so they can keep work in isolation). Or one team working and struggling to get that important feature delivered, whereas the other teams mind their own business without offering help.

• Are stand-ups where people are actively engaging and offering each other help? Or do you always see the same people speak and the rest being completely passive? Do you manage to finish your stand-ups with 5 minutes or do they always linger on too long?

• Do you often see backlog items on the board that seem to be stuck? And what about too many backlog items being in the active state at the same time? And do your Kanban teams even have a WIP limit that they honor?

• Do teams have a mindset that makes them work together to get those backlog items moving over the board from left to right, even if that means they have to do work outside their comfort zone?

• How well do you manage to balance technical work, getting rid of technical debt and delivering customer value? Or is this a continuous fight between product owners, architects, developers and even managers?

• Can teams focus on the work they planned to work on? Or are they continuously disturbed by outside sources? And if it’s the latter, have you found ways to prevent and/or funnel this?

• Do development teams understand how their work contributes to the wider goals of the project or organization? And do they understand the goal of their current assignment? If it is a POC or MVP, do they realize that the goal is not to deliver a rock-solid product, but just something to open up the market.

• Do the developers see the development process and the associated ceremonies as useful? Or do they feel like it is just a waste of time that keeps them from hitting that keyboard? Is anybody trying to sabotage the process a little bit.

• Are (sprint) retrospectives just routine meetings where people mumble a bit on what happened without any concrete actions? Or are they joyful, surprising and effective meetings that really help achieve the agile mindset of inspecting-and-adapting?

Do you recognize any of the typical struggles I just listed? Do you think they apply to your organization? Let me know by commenting below.

About me

I’m a Microsoft MVP and Principal Consultant at Aviva Solutions with 26 years of experience under my belt. As a coding software architect and/or lead developer, I specialize in building or improving (legacy) full-stack enterprise solutions based on .NET as well as providing coaching on all aspects of designing, building, deploying and maintaining software systems. I’m the author of Fluent Assertions, a popular .NET assertion library, Liquid Projections, a set of libraries for building Event Sourcing projections and I’ve been maintaining coding guidelines for C# since 2001. You can find me on Twitter and Mastadon.