What Do You Value?
Sometimes I think we are missing the point.
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 need to deliver the value is 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 specific 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. This might come in the form of a sprint planning meeting and a sprint review. It might be done ad-hoc as a individual 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. We 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, and planning meetings help me get there… they are useful tools 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 to get teams predictable.
So my question… are you more concerned about adopting specific agile practices or doing what it takes to build well functioning teams?
Comments (20)
enweave
You may "get in trouble" but not from me ;~)
In a way this is like the old adage, "When the only tool you have is a hammer, everything starts to look like a nail."
Especially if you are selling hammers.
Especially if the only place you ever go is to the hammer store.
It's not really about tools or techniques. It's about results… Real quality results. A craftsman not only cares for their tools and toolbox, they know which tool to use for best results in any situation and, they keep only the best tools in the box.
Are we selling hammers or crafting high quality, Agile organizations?
I vote for the Agile organization.
John Stoneham
Mike,
I'm amazed at this blog post because you've managed to crystallize and put into words some ideas that have been wandering around my head for some time and exactly match with my experience looking at a number of successful and unsuccessful teams, both agile and not.
I will say, though, that Scrum has been proven to be a successful 'how' for a methodology to apply, all at once, right now, for the teams and management side of the process. (Let's leave engineering practices aside for now.) I think we ought to think of it that way – as a starting point, a common reference point. This explains both the fundamentalism – it needs to remain somewhat prescriptive to remain a complete and defined starting point – but also people's desire to change it – because they want the reference point but to still make adaptations.
I guess where I'm going is that it may be easier for an organization to adopt a method, and then with some guidance, adopt the values, than to start with the values up front.
noostvog
When you say "I don't think the product owner is all that important", I disagree.
When you say it is important to have a healthy product backlog and fast decision-making by the business I fully agree.
Recently I wrote down the characteristics of a great product owner. According to me, the most valuable work of a product owner is helping the team understanding the business and validating delivered features. A team can really make speed when they have a team member that can transfer the client requests in a clear and understandable way. In practice, those tasks are assigned to one physical person. Maybe that's more the core definition of a product owner to me.
Dmitry Zdanovich
Mike, excellent post!
Bad things about fundamentalism – followers consider others as doing wrong and try to force them to use their methodology. Fundamentalism prevents from absorbing the best ideas from different opinions/approaches. It stops one's development.
Of course, it doesn't make sense to start every time from scratch – ready-to-use methodology is a good starting point (as mentioned John Stoneham). But you should understand your context to be able to choose right methodology.
Values are not intagliated as well. Certainly they have wider range of situation where they are appropriate. But some principles may not work in your specific context.
I'd describe values as high-level strategy, methodology as a ready-to-use plan, practices/tools as your tactical means. And you should be able to choose what is the best (or just good enough) for a project (organization, whatever) on hand at every level – maybe, that's ok to have predefined methodology as is, maybe you need to adjust principles.
But don't assume that there is always only one-size-fits-all solution.
Mike Cottmeyer
enweave… nice comment. I use the hammer and nail metaphor quite often.
– Mike
Mike Cottmeyer
John,
I comes down to Cockburn's Shu-Ha-Ri priciple. We need one place to start… I agree. When my customers are totally stymied by an inability to have a dedicated product owner and a dedicated ScrumMaster for each team… or even shared across teams… that makes me think we are focusing too much on the dogma and not adapting to our specific circumstances. Again… is our goal Scrum… or is our goal greater business agility. I think we can have greater business agility without dogmatically applying Scrum.
Nice comment!
– Mike
Mike Cottmeyer
noostvog,
I like to have a dedicated PO when I can get one. I might even say that is the ideal. The problem is that folks let the absence of such a role prevent them from getting value from iterative, lightweight methods. There is more than one way to solve the core problem (well groomed backlog, prioritization, etc.) without sitting there frustrated because the business won't give you a PO… as Scrum defines it.
Nice comment, thanks for reading!
– Mike
Bob Williams
The one piece that has me thinking is 'teams are accountable'. In my experience, when something is at issue or goes wrong it will break the boundary of a team. In this situation we tend to start by looking for a single individual who is accountable. That could be for the overall failure of a project or it could be for missing a specific date. How many times have seen an entire team fired for the failure of a project or a task? If not a single individual then at best a smaller sub-team is held accountable.
A better way to look at it might be that team's encourage the concept of accountability because you have a group to be accountable to. The team, by nature, holds members or sub-groups accountable for the contributions.
Kevin E. Schlabach
I'll give my supportive "NICE!" since you used this post well as the appropriate sized hammer on the right nail.
Mike Cottmeyer
Bob,
That is part of the problem in corporate america right now. I the Project Manager accountable? They don't own the resources. Is the development manager accountable? They don't have the total span of control over the entire set of resources? If we are going to be accountable… we have to have the tools to deliver.
We focus on process adherence and it obfuscates accountability for results. We need to form teams around the value creating capabilities within the enterprise. When this is in place… we can start thinking about improving performance of our constrained capabilities. And… if over time… those capabilities do not delivery… maybe the entire team is accountable.
More to come on this later…. great comment. Thanks for the reply.
Mike
Mike Cottmeyer
Appreciate the "NICE" comment Kevin!
Sam Laing
Awesome post – exactly whats been going through my mind for a while now, except I could never put it so eloquently. I try and instill an idea of "if its working – stick with it, try to improve on it, if not – try something else".
When people mention the word "agile" I used to jump up and down (in my head) if they did not use the 'scrum' definition. I now find myself defining to the team the original definition of 'agile'.
… moving quickly and lightly … nimble … spry … keen and lively …
That is the kind of team I want to be a part of – regardless if there are PO's, SM's, daily scrums etc.
Christian
The reason for all the rules and ceremonies is to enforce good practices without the need to understand why it works. As a team or organization matures they probably no longer need this which is what you point out.
danossia
Great post Mike. I recently published something along the same lines (http://www.martinproulx.com/2009/02/you-are-not-doing-scrum-if-you-dont.html) where people are so concerned about WHAT is being implemented that they actually forget to take a step back and evaluate if they are reaching their objective.
Unfortunately, people feel better following recipes than achieving an outcome. At least they can pretend they tried…
Mike Cottmeyer
Thanks for the reply Sam… sounds like you are inspecting and adapting ;-)
Mike Cottmeyer
Christian…
I agree with you… but.. the idea of enforcing good practices without people understanding why they work really PISSES ME OFF!
When you do things without understanding why… you will fail. Sorry… just had to get that off my chest ;-)
Mike Cottmeyer
Martin… nice observations… I read and liked your article.
Jez Nicholson
Absolutely yes. Values are the bedrock of an Agile environment. It makes the difference between knowing why you are using a technique to doing it because someone said so.
I am motivated by my formative days as a Developer where I was under extreme pressure to keep vital company systems running, often on my own late into the evening. I don't ever want my Devs to feel this way, it is detrimental to creativity and also not morally fair.