Question: What role does heroic effort have in an agile shop?
Take a minute and bring your favorite movie hero into mind. I’ll bet that hero sacrificed more than others to gain more than others. If you bring a few more to mind, they probably did the same thing. Whether it is from movies, books, current events, or history books, our heros have all endured personal hardship or made extraordinary efforts to get the girl, win the prize, save the world – and sometimes, all three.
Corporations love heroes. Their recognition, incentives, rewards, and promotions are based on extraordinary contributions. Every award I have received has been based on some herculean effort or sacrifice. A friend described a company getaway to a posh resort as a boon for delivering their product. The highlight of the weekend was a recognition ceremony. That ceremony recognized three people that worked nearly double time for several months to bring the product to market by the deadline. Examples of corporate hero worship are everywhere.
Heroes are American cultural icons that permeate every aspect of our lives. Project and functional managers absolutely love them, because, they are the ones the hero saves. When design and analysis take to long, when planning fails to anticipate significant work, when a project falls behind for any reason, the hero steps up to save the day. They are saving face for the managers that would be left holding the bag. In reality, they are hiding process flaws and without a bright light, those flaws stay hidden and are never fixed.
What is, or should be, the goals of an IT software shop? I think it can be captured as:
To produce predictably delivered, high quality software that delights the customer.
Predictably delivered: a constant stream of products, produced at an efficient, constant and sustainable pace. Our work continues for the life of the company – it’s not a short term goal.
High quality software: products that are well designed, easy to refactor and extend, well unit tested to reduce maintenance risk, and with good functional testing that proves the product works as expected.
Delights the customer: more than meet customer needs, we hope to exceed them by constantly engaging feedback and thinking of things they never knew they needed but find indispensible after they use them. IT is not always so glamorous, so sometimes, this is achieved by the customer never noticing the product because it always does what is expected.
The goal is not to save the world, but bring a major project in to meet a publicly announced delivery, to generate products faster than our competitors, or increase our bottom line as rapidly as possible. We don’t need a hero. In truth, these four examples are not best served by heroes either, but that is another case to build.
Corporate heroes are characterized by
Family and social life: Heroes sacrifice family and social life when they work overtime – especially in long periods. A stressful family life and lack of social diversions diminish creativity, productivity, and efficiency.
Stress: Heroes are under pressure to produce a result, either by management or ambition. Stressed out workers are not creative, productive, or creative. And, they are not fun to be around.
Exhaustion: Herculean effort is draining. Well rested, healthy, happy employees come up with better solutions, more quickly than overworked, tired, grumpy ones. GeePaw Hill cites research showing that sustained overtime actually reduces productivity below that of no overtime at all.
Sustainability: Heroic effort is not sustainable. Long periods will burn anyone out. Burn outs tend to leave companies, even if it was a self-inflicted pressure to achieve.
Demoralizing: Heroic effort is incented, recognized, and promoted which sets a standard that more well balanced workers can never meet. This is demoralizing and creates a work environment where a good, solid performer can never experience a win. This produces another kind of burn out and employee churn. When a hero is promoted, he takes his ideas of success with him and perpetuates the cycle.
Employee development: Heroes focus on the task at hand which leaves no time to learn the business, understand the bigger picture, and they miss integration and feature problems that could have been anticipated with broader domain knowledge. Overworked employees do not have time or energy to improve their skill set which is fundamental to improving their productivity and software quality.
Code quality: Heroes love overtime to give the impression of productivity. Overtime is used to produce a tangible result as quickly as possible - not to develop better tests, more innovative solutions, or improve overall quality. These shortcuts are more expensive compared to the upfront cost and the burden is shouldered by the rest of the team.
Code cost: Heroes produce lower quality code because they work long hours wich reduces their creativity, productivity, and efficiency and reduces their ability to improve their programming skills and domain knowledge. Low quality software is very expensive to operate and maintain. More resources are expended due to inadequate monitoring, more complex, risky, and time consuming bug fixes, and more costly product enhancements.
Technical debt: A shop that rewards heroes, cultivates heroes, which implies lower quality code and higher code cost: technical debt. Perpetual heroic efforts also mean that there is never time to pay for short term benefits and builds a mountain of technical debt that can overshadow all other efforts.
Customer satisfaction: Code shortcuts imply that there was no time spent trying to delight the customer. Other shortcuts are usually testing and features. Even satisfying customer expectations is put at risk.
Employee churn: Employee churn is exceptionally expensive. Teaching domain knowledge takes technical leaders away from more productive tasks. Lack of domain knowledge means less productive workers. Domain knowledge takes a long time to acquire so both productivity losses are felt for a long time.
Increased operating costs: Every one of the consequences listed above increase operating costs.
What kind of employee is best suited “To produce predictably delivered, high quality software that delights the customer” ?
Basically, an antidote to all of the consequences listed above.
Healthy, happy, well rested people under little stress, working standard hours, with a good quality family and social life:
What type of environment creates an employee that is best suited “To produce predictably delivered, high quality software that delights the customer” ?
The Agile process addresses every one of the IT software goals as well as consequences listed above. Agile projects are implemented by teams and the best agile teams will be built with employees described above.
If our social and corporate culture are mired in hero worship, how do we create an atmosphere where the team is valued more highly?
I think the answer is simple: feed the thing you want to live, starve the thing you want to die:
Implementation is much harder because it calls into question ideas that are held so deeply that they aren’t really even thoughts – they are reactions. Identities and egos will be challenged, processes and ownership scrutinized, and best practices examined.
Don’t incent. Create a motivating atmosphere and let people breathe.
Rewarding intellectual workers with monetary incentives does not work – it actually reduces performance. Intellectual workers perform best when they are paid enough to eliminate money as an issue.
Intellectual workers are motivated by autonomy, mastery, and purpose.
Management driven employees are a good fit for the waterfall process. Agile thrives when staff is engaged and engagement is highest when they have autonomy and self-direction. Giving a team and its members autonomy provides a highly motivating and rewarding work environment.
Developing technical mastery and then applying it to a significant challenge creates a subtle euphoria that intellectual workers thrive on (PeopleWare: DeMarco and Lister). Using that mastery to make a measured contribution develops a sense of purpose. Individual teams can show and spread their mastery through paired programming, group design and code reviews, and lottery learning sessions. This mastery can be shared between teams with technical presentations and agile safaris. Technical conferences allow developers to interact with other community leaders and can be offered as a boon.
Viktor Frankl, in Man’s Search for Meaning, describes service to a purpose greater than one’s self as the common thread people share in defining a meaningful life. Many thriving companies have discovered that as well and use it to create a meaningful workplace as well as attract the best talent. IT software is not so glamorous, but creating great teams from happy people drives team affiliation and helps provide that purpose.
Frequently, bonuses and pay increases are assigned to heroic efforts and accomplishments. It is much easier to tell how much time was spent in a chair than what the quality of a contribution was.
On small teams, the manager must be able to judge the quality of the work that is done. There is no other way than for them to be involved in the work and have the technical competence to evaluate it. For developers, this means design and code reviews. If you want to reward based on quality of contribution, I see no way around this.
For larger teams, or teams where the manager has taken a business track instead of technical, I think the only option is to delegate to a technical evaluator. This would involve technical leads collaborating with the manager on a rating scale across the group that would indicate a level and distance between levels. Then there is the question of wage leveling across similar groups, and then across dissimilar groups. Complex issues and I have no model for doing it well. I think the most important aspect is a shift from quantity of hours to quality of contribution AND communicating that shift in evaluation.
Promotion is a little more straight forward: define the role well, make the decision based on suitability to the role, communicate both role and evaluation and that number of hours indicates process failure and is not positively regarded.
The first step in creating a great work force is creating a great environment for them to grow. As already stated, remove hero incentives, frown on overtime, motivate, and pay according to quality. Then look for ways to improve the environment; engaged, motivated workers with purpose will tend to work too much, not too little. Spend time trying to create “geek joy”, value quality and personal improvement and then facilitate it.
Next, hire great people or people that have the potential to be great. What if we could alter our hiring strategy from filling a seat before funding goes away to looking for opportunities to bring in great talent?
Finally, develop the staff. There are many low cost ways to do this and also build a great culture. GeePaw Hill recommends “lottery learning”: A small team orders lunch, locks themselves in a room, a person is picked by lottery to project some code – any code, not their own, and start a walk through. Then chaos happens. People pick apart the good, the bad, the ugly. They play what-if with the design and alternate implementations. Everyone learns from everyone whether it is new techniques or being able to identify the pros and cons of all possible implementations. Motivated managers and leads will look for new strategies if time is allocated for it and it is encouraged.
Create a great place for the team to work. They need to be grouped where they can easily collaborate – lean back in a chair and talk to someone that can help them solve a problem. They also need sufficient meeting space where they can whiteboard analysis and design. On the other hand, they need a place where they can get away from noise and focus on complex tasks. Finally, they need a comfortable place to take a break.
Create team building activities; ones that are effective and fun instead of the perfunctory ones offered by outsourced facilitators. The real test of a gelled team is if they would happily stay for this activity or prefer to try to sneak out and go home early.
Make sure that managers that assign bonuses are able to evaluate quality of contribution instead of just time in the chair.
Don’t recognize people for working all weekend. Instead, recognize it as a process failure that needs to be fixed.
Repurpose incentive pay to fund team activities that will produce “geek joy”.
Provide opportunities to show off mastery like Google time or Atlassian’s one great day. Praise that effort.
Ironically, changing corporate culture takes a heroic effort because you have to work outside a frozen system to change it. Part of that change should include creating a flexible system so that future evolution does not depend on heroic effort.
An interesting presentation from GeePaw Hill on coaching teams http://www.infoq.com/presentations/Individual-Coach