During my Agile 2012 session with Don Gray, one of the disgruntled participants, who was appalled that we were making them think, wanted to know what the Agile best practices are.
Don and I both replied the same way.
It depends.
If you’re in a 20 person organization, your people go out for team lunch every week, people in the organization are friends outside of work and you have one product to develop, your best practice is Scrum. Maybe. Given the scenario I described, that paints a picture of a collaborative organization, not much conflict with a simple structure and low complexity as far as managing products/projects since there is only 1.
If you’re in a 300 person organization with strong functional silos, tall hierarchy, have people working on 3+ projects at a time and are in a highly regulated industry, Kanban is your best practice. Maybe. Given this scenario, I see an organization that frowns on change, visibility and too drastic of a shake-up of the status quo.
Let’s take a look at best practices in another industry, HR. According to this article, there are the 10 HR best practices:
- Safe, Healthy And Happy Workplace
- Open Book Management Style
- Performance Linked Bonuses
- 360-Degree Performance Management Feedback System
- Fair Evaluation System For Employees
- Knowledge Sharing
- Highlight Performers
- Open House Discussions And Feedback Mechanisms
- Reward Ceremonies
- Delight Employees With The Unexpected
I’ll cherry pick a couple of them for argument sake. After all, I’m hacking best practices.
Performance-Linked Bonuses: The article describes the danger of bonuses and does say that when implementing bonuses make sure they are tied to company performance. It then mentioned in addition to that team and individual criteria can be considered.
The problems I see in organizations that have implemented performance-based bonuses is when they are individual based. Worse yet when they are tied to metrics like resolving defects. A testing manager who is incentivised by way of raising defects can do more harm than good in projects and that can reinforce the wall between testers and developers.
While this is a ‘best practice’, much like any performance-driven program, there are consequences.
Knowledge Sharing: The article talks about creating a database of knowledge through a knowledge sharing platform. The intent, again, is great. People love documentation and tools, it gives us a sense of safety. Unfortunately it’s not as effective as most folks hope it will be. Data becomes stale and generally speaking, people are more likely to ask a co-worker a question before looking something up in a knowledge management system. I remember seeing a stat that people are 6 times more likely to ask a co-worker a question over looking up information in a tool, but I can’t find the reference to it. Please add a reference in the comments if you’ve seen the same study.
Again, this ‘best practice’ is put in place with the best intentions, unfortunately it doesn’t work out the way it’s intended.
What’s the Alternative?
In the case of knowledge sharing, a pairing program is an alternative. That’s what I like to do. Often new employees are directed to an outdated knowledge repository, I prefer to pair with a new employee for a couple of weeks and let them create their own documentation. I’m sure that may sound in-efficient to you. It’s not.
In the case of performance bonuses, allocate a bonus to a department or team and let them choose how to divide it up. Another alternative is to stop giving executives bonuses that aren’t available to staff members. It creates resentment. Also think of better ways to measure performance such as using NPS (net promotor score) for teams and for individuals. I did that once. My NPS as an employee was 71%. As a reference, Apple’s NPS in the UK was 68%. NPS is a measure that asks customers the question that on a scale of 1 to 10, how likely are you to recommend a product or service.
Hack, Hack, Hack Away!
So how do you hack best practices? You hack best practices first off by not calling them best practices anymore. Take these ‘best practices’ from various sources and morph them into “Contextual Common Sense Practices“. There, that’s 2 buzz phrases in one post. Hacking Best Practices and Contextual Common Sense Practices. I feel very cool now.
Agile Contextual Common Sense Practices (ACCSP)
I need a better acronym for that. ACCSP is simply the practice of experimenting with Agile practices and learning from how you’ve applied them in your context. Given my first scenario I talked about (20 person organization), if you start with Scrum and don’t see any business benefits, change your implementation of Scrum. Sure you’ll get chastised as doing “Scrum-but”, but who cares? If your adaptation of Scrum works better for your context, it’s the right best practice….er, Contextual Common Sense Practice.
I’m working with a team right now who is visualizing and work and doing standups only. The standups are “run” by the PM…ooh, that’s a hard-core sin isn’t it? The difference is the customers are happy because of the visualization and frequent touch points and we’ve collected evidence that simply by using these 2 techniques the relationship between the team and stakeholders is much stronger. Who am I to tell them “they’re applying it wrong?”. They’ve adapted what makes sense for their context and I’m proud they’ve taken ownership of it.
The moral of this post is that people who don’t know any better want best practices. Instead of telling them they’re wrong for thinking that way, draw out what they are trying to learn through better questions and help them solve their problems. If that doesn’t work, we have an Agile stick in our team room you can use to beat them with.