Whether you are a bleeding edge startup or a large corporation running agile teams, here are four ways that you may be abusing agile concepts and letting perfection kill your chances of success.
Product Owner Perfection
In an agile team, the Product Owner (PO) is the “voice of the customer” to the development team. They play an incredibly important role in the success of the project. The PO will end up writing most of the user stories that describe the features the team will work on next, and equally important, the PO sets the priority of what to work on next.
Implicit in this prioritization duty is that the PO is also the person who says “go” and approves the deployment of new functionality to production. So what happens when your product owner keeps saying “just do this one more thing and then we’ll deploy”?
For a startup, this sort of “all or nothing” attitude will not just kill your project, it will destroy your business. It will take you so long to satisfy that perfectionist Product Owner that you will end up missing your window of opportunity with customers. Somebody else is going to build a less perfect version of your idea first, and they will win the customers before you even have a chance.
For a large company, Product Owner perfectionism is still bad. It means that your schedules are going to slip, major initiatives will not be completed on time, and your agile team is going to look a lot like a very slow waterfall team.
Developer Perfection
Good developers are an essential part of a successful project, and so it’s easy to go overboard and hero-worship their technical prowess. But sometimes that desire to be the best developer out there can kill your project.
Developers (in general) are very creative folk who take immense pride in their work. The best ones also really enjoy playing around with the latest technologies and trying new things. But even if you’re a non-technical leader, you can’t give them free reign or they will have so much fun building shiny objects that they will never get the project done on time. I’m a developer by training … trust me on this.
Even if you can’t debate the details of technical decisions being made, you need to set clear boundaries for the team to work within. If there is a fixed date you must have the functionality done by, communicate that from day one. Make it clear that meeting that date is the most important thing, and you are willing to compromise on anything but that date. The same is true for other project constraints such as budget or feature sets. You can’t have everything, so pick one constraint at the beginning, and make it clear to the development team that is the constraint that must be met above all else.
If you’re project has no constraints (yeah right), then make one up. You need to give the developers those guardrails.
Scrummaster Perfection
Are you agile enough? I mean, are you truly Agile? If you hear this a lot from your newly minted and Certified Scrummaster, then you are at risk of Scrummaster Perfection.
It doesn’t have to be agile methods like Scrum or Kanban, or even the Scrummaster as the culprit. Perhaps we should just call this Process Perfection instead.
Any process should be judged by the results it produces. Not the process results (aka documents and meeting rituals), but the actual value delivered to customers. Are customers happier with us than they used to be? Are they getting more value from us than in the past, and are we delivering that value more efficiently? Than our process is working. That’s all that matters.
It just so happens that agile methods tend to do the best job of delivering more customer delight more efficiently. That’s why agile is popular. But they can be abused and if you spend all your time worrying about adhering to some agile book you read, then you will not deliver much customer delight.
Please remind your Scrummaster and team that agile methods are not meant to be prescriptive – they are a set of guidelines and principles. You can (and should) constantly change your process in order to better serve your customers. As long as you are still adhering to the basic tenets of the agile manifesto, you can declare yourself agile.
From your customers’ perspective, they don’t even need to know you’re agile. They don’t give a rip. You should just be doing a better job for them than you used to.
Quality Perfection
I’ve already complained about perfectionism from our product owners, developers, and scrummasters, so who’s left for me to alienate? I know, let’s pick on testers for a moment!
I am all for testing, both manual and automated. I am also all for high quality software. I hate it when a bug keeps me from doing something important on another company’s web site, so why should I accept anything less on my own?
The thing is … all bugs are not created equal. If I can’t accomplish core web site functionality on the most commonly used browsers, then yes, that bug has to be dealt with quickly and should be caught before it’s deployed to production.
But should bugs in older browsers keep you from deploying software now? It depends on your customer base, but probably not. You can probably live without a fully functional site in IE 8. Or you can change the code for that browser to be simpler and not have as rich functionality.
If the bug is in an obscure part of your administration console that very few users notice, then maybe it doesn’t need to be dealt with right now.
The point is, many testers have a problem with perfectionism. I find this to be particularly true with testers in large companies because in the past they were judged by the wrong metrics.
A tester should not be judged by how many bugs escaped the test environment and made it to production. A tester should be judged the same way as the whole team – are we making our customers happy by getting them the right features at the right time with an appropriate level of quality?
Unless you’re building safety-critical systems, you don’t need to deliver perfect quality. You only need to deliver just enough quality, focused on the right areas.
Is your perfectionism holding you back?
What is keeping you from deploying that code today? What is keeping you from making that deadline next week? It may just be endemic perfectionism in one or more parts of your team. Go find that person right now and reset expectations with them before it’s too late. You can still save that project if you act now!
