I am becoming more and more convinced that building organizations around teams is the real secret to building agile and Scrum organizations. How we set up our teams, what we have them work on, and how they work together with other teams… all determine how well value will be created for our business and ultimately our customers.
Some things are really important about teams… and some things just aren’t. Getting straight about what we are are actually trying to accomplish with our teams will help us get past some of the dogma, methodology battles, and Scrumdamentalism that is preventing us from incrementally adopting agile practices. Is our goal to adopt Scrum or is our goal greater business agility?
Important Stuff about Teams…
Teams Deliver Value
Sometimes this means that teams work on cross functional threads of working software. Sometimes it means that teams deliver services that will be consumed by another part of the organization. Teams might be part of the business and handle billing… or marketing… or sales. I only care about teams being cross functional in the sense that the team needs to have what it needs to deliver the value it was created to deliver.
Teams are Accountable
Teams make and meet commitments and are responsible for delivering on those commitments. They are accountable for outcomes. I don’t care so much how they deliver those outcomes… assuming that they operate within moral and ethical boundaries… I care that teams do what they say they are going to do and deliver the outcomes that they promise to the business.
Teams are Predictable
Over time, the business should be able to provide specific inputs and get reasonably predictable outputs. Throughput should trend up… and we should know why it is trending up. If throughput is trending down… we should be able to assess and understand why it is trending down. If throughput is variable… it should at least have a reasonably predictable rolling average. If teams aren’t predictable… we can’t plan anything.
Teams get Better
We need to have some mechanism in place for getting better over time. This could be a sprint retrospective… or it might be a Kanban board. We can rely on the knowledge and creativity of the team to improve… or managers can use Scrum tools that help make problems visible and help the correct the problems. It cannot be okay to accept mediocrity.
Teams are Transparent
The business needs to be able to understand exactly what the team is working on and how the deliverables relate to the objectives of the business. The business needs to understand what problems the team is having so that they can help get them resolved. Team performance metrics need to be visible and explainable.
Not so Important Stuff about Teams…
Teams have Product Owners
I am probably going to get myself in trouble here… but I don’t think that the Product Owner is all that important. It is important to have a well groomed product backlog. It is important to have someone to answer questions for the team on behalf of the business or the customers. It is important that the business is accountable for making decisions in a timely manner and giving guidance to the team.
If that can be done by a single person called a Product Owner… so be it. All I know is that it needs to happen.
Teams have ScrumMasters
Again… going to get in trouble. What I really need is someone to help the team stay on track… to maintain the vision… to help remove impediments… and to collaborate with the team to help them improve. If this is a ScrumMaster, great. It might be a resource manager that fills this role… it might be a project manager. It might be a good dev lead or a product architect.
Teams do Daily Standup Meetings
What I really need is communication between team members. I have worked with teams that all sat in the same space… worked together daily… and always knew what was going on. If a daily standup meeting adds value… do it. Just remember why you are doing it and if you are getting the outcome that you need. Communication… transparency… shared accountability… those are the important things.
Teams have Planning Rituals
The team needs time to plan. They need time to get their head around the problem and coordinate the work. They need a time to inspect and adapt. There might need to be a sprint planning meeting and a sprint review. It might be done ad-hoc as a requirement is moved from the backlog into the in process queue.
Do We Care About What or How?
When folks are just getting started with agile… it is easy to get caught up in the how. How are we going to plan… how are we going to meet… how are we going to review outcomes… how are we going to ensure accountability. I need to focus on what the team is going to deliver and the attributes of that delivery that are important to the business.
It is extremely important that a team delivers something of value on short cycles… that they are accountable… that they value predictability… that they get better over time… and that they are transparent to the business. To the extent that Product Owners, ScrumMasters, daily stand-up meetings, Scrum tools, and planning meetings help me get there… they are useful and might get included.
These things could be out of sync with your organization and actually impede your ability to adopt agile. You might need to think about what you’re really trying to accomplish and come up with some situationally specific strategy to build teams… and get teams predictable.
It might be unreasonable to ask the business to take a Product Manager and turn them into a Product Owner. It should be perfectly reasonable to ask them to make sure teams have the requirements they need to build software… requirements that accommodate change… help mitigate risk… and deliver value better and faster back to the business.
So my question… are you more concerned about adopting specific agile practices, or doing what it takes to build well functioning teams?