Focus on Delivering Exceptional Value and All Else Will Follow
Working with software teams is an exceptional challenge, and it can be a heck of a lot of fun. Software is fun to work on when the team is winning, the client is happy, and the users love the product. If you have all of those things, you hopefully can make a decent living too.
Building high-performance teams are not that complicated, but it takes discipline. You need the right mix of talent. The team needs the right direction. It Takes Trust. The team can only operate as well as its weakest links. We aren’t football players, and we don’t need the likes of Bill Belichick to get our teams performing at a high level. What we do need is a profound commitment to our teammates to Always Be Delivering Exceptional Value.
We’d love for life to be more straightforward, but just because you work some hours doesn’t mean you can bill for them if you don’t create value.. Software is all about change, and things take time to complete. There are continually changing dynamics on a software project: from the state of the industry, customer needs, client demands, or toolkit changes. Workflows can usually be improved to add even more value to the team’s ability to deliver working software more reliable and faster.
If your team is five people with different knowledge and expertise, consider who is the weakest link, based on:
1. Skills and experience?
2. Team Dynamics?
3. Client Dynamics?
It may be that three out of the five teammates are weak for this project, all for varying reasons.
Faced with the possibility that over 50% of your team is weak, you might imagine they must not be delivering value. However, this very well could be a highly performant team. The team needs to be nurturing its weakest links, not ignoring them, hoping they’ll somehow improve.
Hope is not a strategy
What is Value Creation?
Value creation is the primary aim of any business entity. Creating value for customers helps sell products and services, while creating value for shareholders, in the form of increases in stock price, ensures the future availability of investment capital to fund operations.1
What is the Definition of Done?
The definition of done will vary slightly from team to team. Typically, we recommend that Shipped to Production means the task is done.
shipped === done
That’s all, nothing to see here, move along.
How long does it take to move something from Todo to Done? How many steps are there? How can we reduce friction for the team to be able to move things from todo to done even faster than before? Are we getting better at completing things more quickly? What is the constraint on the value pipeline — is it that no one is quick to do code review? Is it that the client is slow to do acceptance testing on the staging environment? Are there too many changes in each pull request, causing painful migrations and merges, blocking the team from being able to ship their pieces to Production?
There are fewer than a million ways that things go wrong on software projects on a value delivery level. Most problems smell like the ones listed above, and they are all resolvable.
-If the team goes a week without shipping anything to production, you have some explaining to do.
-If items take than 24-48 hours to complete, you need to reduce the complexity of each work item, to deliver the pieces more quickly.
-Team members must feel that they are able to win.
– Team members must be able to work through the process quickly and efficiently, delivering their value additive changes to production in less than a day’s work.
It Should Take Less than 8 hours to get something to production.
The “soft” skilled members of the team, such as Product Managers or Designers are not that different. The product manager delivers value by keeping the team fed with well-articulated work items that they can complete and quickly move through QA. The designer creates artifacts and iterates on them by working with the team. “Done” doesn’t mean shipped to production in these cases, as the end state is a work item that can be delivered by the dev team.
How does an Agile Coach Deliver Value
Agile Coaches or Scrum Masters are a meta value add. They’re there to ensure that the team is staying on track and is capable of completing it value delivery in a reasonable manner. The Agile Coach is there as a safety net to surface any apparent process related issues that the team would heartily proceed to ignore due to their inherent conflict of interest.
In more disciplined and experienced teams (meaning that this team has worked together, effectively, for an extended period), an Agile Coach won’t be necessary, because the team has grown in their shared discipline. If this team is capable at this time of operating a regular Sprint Cycle without a Scrum Master, they may be ready to graduate from scrum to kanban.
The value added by the Agile Coach is keeping the team on the rails. In sporadic cases are problems not foreseeable or preventable. It’s the Agile Coach’s job to keep the team on track.
Conflict of Interest
There is a pure conflict of interest that each developer faces on a software team. Their work is already challenging, and it’s in every developer’s best interest to make their job easier. Many of the technical debates that take place on a software team stem from this simple fact. If you have two approaches to a problem, perhaps one places more workload on the backend developer, and another puts the workload on the front end developer. How do you determine what the right call is? The answer, as many CPAs will tell you, is “It depends.”
Enter the Agile Coach. Having this person around to assist the team from a non-partisan perspective is where they add their value. The developers are not only trying to identify the most value-additive way to deliver their work, but they are also subconsciously optimizing for their workload. If the “Easy” way sacrifices user experience, developers will go unchecked if the Product Manager or Designer are not advocating for Great Ux*.
What’s the Value?
All of the technical minutiae of a software project boils down to this: What value is this pull request delivering?
- [ ] The client asked for it && it makes sense
- [ ] It satisfies a technical requirement from the client && that technical requirement makes sense.
- [ ] It makes our users happy
- [ ] It’s necessary to reduce the Technical Debt && Reducing the Technical Debt is the most important thing to do right now
- [ ] It meets the acceptance criteria
- [ ] It’s an objective improvement to the system
- [ ] It will improve team velocity
If you can’t say yes to any of those checklist items, we’ve got problems. I don’t know how we’re going to be able to expect the client to pay for that.
That’s how we think about providing value for our clients. We know that as long as we are delivering exceptional value, then all else will follow.
* This is, in no way meant to shame developers. We used to be there writing code alongside you.