Saturday, March 23, 2013
Friday, March 22, 2013
When I came on board at Hyperformix, just over four years ago, I was impressed with many things about the company, most notably its leadership (both technical and managerial). As part of the Senior Management Team, I had an opportunity to work with an amazing VP of Products and Marketing, Bruce Milne. I'll never forget the sign he had on his wall--it was a standard sheet of 8 1/2" x 11" paper printed out some time ago as it had seen some weathering. Upon this paper was the fading ink that had no small impact on my mind and life almost every day since.
Monday, March 18, 2013
Friday, March 15, 2013
I delivered this presentation at the Agile Austin (www.agileaustin.org) Leaders' SIG on June 1, 2012. This covers, at a high level, the reasons why we decided to deprecate the annual performance review when we switched to an agile philosophy/mindset for delivering valuable and usable customer software. The system we put in place was primarily designed to encourage/codify alignment of the work of all team members with the highest business priorities, while remaining flexible enough to deal with important change.
A "side" benefit was that the amount of waste avoided in the effort that allowed the team to stay razor focused on innovative product development. I talked with a few other companies in Austin that were considering doing something similar. One of them had calculated that they spent a fully month of their organization's capacity (i.e. November) doing annual performance appraisals. Once they stopped doing them, they received over 8% productivity back immediately!
Note that I am a strong proponent of putting in performance plans in place when it makes sense from an improvement basis. There are good reasons for doing so legally, in order to protect all parties (including the individual contributor).
Like all things it was a bit of a compromise as I was still against the compensation payouts, but our agile culture was a constant reminder to not implement incentives that would take away from teamwork and collaboration. Once we came into CA Technologies, this system was deprecated for a more traditional annual performance review system (I'll blog about that later), but the team was still laser focused on the top business priorities, without the need for any other extrinsic motivation mechanism.
I would be interested in hearing others' learnings in this area, as I see traditional annual performance reviews as key impediments to adopting an agile culture and enjoying the full impacts of its benefits.
Here's the slideshare link:
Another source of wisdom is Dr. Deming, the quality prophet who taught Japan to dominate the U.S. auto industry. In this video, he talks about the Five Deadly Diseases of Modern Management. Number three is: Annual Rating of Performance at 4:58. It's only a few minutes long but has a very large impact.
Monday, March 4, 2013
Why Structure Is Important in a Self-Organizing Agile Environment
An Example: The Rules of "Engagement"
|Rules of "Engagement" Poster Used in our Larger Planning Meetings|
The ultimate rule, dubbed "The Rule of Two Feet", was repurposed from the Open Space Law of Two Feet, which states: "If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, go someplace else." This would be the ultimate solution to disengagement, but I thought it made sense to have the departing team member discuss why they were leaving with the rest of the team. In this system, team members are empowered with the flexibility to leave if they feel the content is off-topic, does not apply to them, or any other reason. However, it encourages potential continuous improvement (kaizen) moments, including the discontinuation of practices that no longer serve the team.
Team Response to the Rules of "Engagement"
This is certainly a success story, but it worked within a larger framework of trust that we had developed over close to three years of working together. As with most practices, your mileage may vary.
Our Standard Rules of "Engagement"
We at CA Technologies host a bevy of Agile Austin meetings, and the poster above tends to be an item of interest. In fact, many visitors have taken pictures of it and brought it back to their teams. This is great, but it's important that everyone understand the context in which it was developed. It is critical that the team buy into this for specific reasons, understanding the why. Like other standards, rules, process, etc., the team needs to be free to change them as they see fit when there are new kaizen moments.
- Cell phones down / away (unless taking pictures of story point estimation)
- Laptops closed unless
- You're taking notes for the team
- You're presenting
- You're remote
- You desire employment elsewhere :)
- Break for 10 minutes every 80 minutes
- If you're late, you missed it
- Time boxes will be maintained by the MC
- Raise your hand if you think the discussion is off-track or the Rules of "Engagement" are being violated
- Consider remote team members
- One conversation at a time
- Consider the goal of the meeting
- "Rule of 2 feet" is justified, but should be discussed
An Aside - Freedom and Organization
Allowing for self-organization and self-management is essential for software development teams where agility is critical. Indeed, it creates an environment where team members are fully engaged in creating usable and valuable software. However, self-direction may lead away from the goal of the organization. Striking that balance is something that no "best-practice" can ever dictate--indeed it requires experience and a deep understanding of many dynamics. For those in entrusted with managerial or technical leadership positions, this can be an area of extreme benefit or dismay and thus should be a focused area of learning.