When I read First Break All the Rules, I really identified with their list of 12 questions that differentiate good workplaces and high performers. This list helped articulate some important predictors of success and characteristics of failures I had experienced. Here, I have tried to link this list of 12 questions to what I liked and did not like in the XP environment where I used to work. Helene, Chris, and Tom, I’d love your feedback here.
From the book
The best managers are those that build a work environment where the employees answer positively to these 12 Questions:
- Do I know what is expected of me at work?
- Do I have the materials and equipment I need to do my work right?
- At work, do I have the opportunity to do what I do best everyday?
- In the last seven days, have I received recognition or praise for doing good work?
- Does my supervisor or someone at work seem to care about me as a person?
- Is there someone at work who encourages my development?
- At work, do my opinions seem to count?
- Does the mission/purpose of my company make me feel my job is important?
- Are my co-workers committed to doing quality work?
- Do I have a best friend at work?
- In the last six months, has someone at work talked to me about my progress?
- This last year, have I had the opportunity at work to learn and grow?
Q1 — what is expected?
Agile helps with this because of the storycarding process. Storycards help to atomize a big project into chewable and actionable bits. Agile practices such as co-location, stand-up, and show-and-tell promote quick feedback loops – so expectations are reinforced and miscommunications caught as early and efficiently as possible.
The formal role definitions and ritualized practices also defined and reinforced expectations and interactions.
Q2 — do I have the materials I need?
So basic, I hope any process has this….
Q3 — do I get to do what I do best?
If I match the model/process I do. Where I don’t match the model, things start to chafe.
Drawback: Formal role definitions can constrain people whose talents span traditional role boundaries (developers who can design, project managers who are good business analysts).
Q4 — do I get praised or recognized often?
Agile practices such as stand-up (where people get to self-proclaim success or get to credit others) and show-and-tell (where people get to demonstrate success) provide a forum for some of this recognition.
Yet, formal project rituals cannot take the place of actual, warm human interactions. And, not everyone likes their recognition and praise done in public.
Q5 — does anyone care about me?
The war room environment and paired work do build strong relationships among team members. People do get to know each other quite well and care for each other.
I might argue that caring relationships between team members and the management at my former XP shop were much more elusive, perhaps because of sheer numbers. Pairing cannot substitute entirely for management. This need cannot be fully satisfied within Agile/XP.
Q6 — does anyone encourage my growth?
The war room environment and paired work do foster growth. Good behaviors/good practices get modeled and can be imitated. Pairing and close teamwork as a style of work mean that people teach each other, pull each other through, as a matter of course. Pairing also allows for people to safely (with supervision/mentoring) exceed their previous experiences and expertise.
Pairing cannot substitute entirely for management. This need cannot be fully satisfied within Agile/XP.
Q7 — do my opinions count?
The war room environment and paired work do allow for people to contribute their 2¢.
Q8 — is my job important?
Even if the day-to-day work is drudgery, some people can get excited only about teaching others and helping them grow. So, close teamwork can make a job feel more important.
Q9 — does this group care about quality?
Many of the XP/Agile practices are specifically to produce quality code: pairing, test-driven development, continuous integration. Business analysis and quick prototyping are also practices that promote building the right thing for the client/customer.
Quality is expensive and a challenge to sell in a tight market.
Q10 — do I have a best friend at work?
This question is really “do I belong here?” and can also be asked as “are there others ‘like me’ here?”. Good working relationships make a workplace “sticky” (hard to leave). Agile practices do help with this. Close teamwork promotes cameraderie and promotes relationships.
Q11 — has someone talked to me about my progress?
This is really outside of Agile/XP.
Q12 — have I had the opportunity to learn and grow?
This is perhaps what Agile/XP is best at. Through the safety gained through pairing and the collaborative co-located work environment, people get to try on new tasks and new roles with the support of the team.
The Upshot
Agile practices address more of these items than I expected. Perhaps that argues well for Agile in the workplace. However, just because a specific practice addresses one of the 12 questions, does not mean that Agile alone solves it completely (e.g. Questions 4-6) or that other business/environmental factors can’t override the benefit of any specific Agile practice.
For instance, at my former Agile workplace while the storycards did address #1 and the roles helped with #3, an insufficient pipeline of projects meant that what was expected on too many days in a row was “nothing from you today, sorry” or “volunteer”. Without sufficient work, #3 was impossible to attain.
And, the factors builds from small to large numbers, that is, the questions with larger numbers only matter if the lower numbered questions are solidly answered “yes!” So, if a workplace is missing a low number, even though it has plenty of higher number traits (awesome people, learning environment), it is precariously balanced and often the relationship becomes fragile, the weak links I wrote about previously in my post on “un-inescapability”.
Q3 – formal roles don’t let people do what they do best. I do feel that more informal roles work better at letting people branch out. I’m seeing more creative and willing progress at the ‘traditional/non-agile’ place I’m at where the developers are asked to be more than just developers – and they do indeed rise to the occassion. Specifically, thinking in a broader sense of what is needed for the business, some early business analysis that takes them out of the ‘of course I can code it’ to ‘should it be coded at all?’. All items that I think are more beneficial than straight-jacketing people into roles. So, this really begs the question that should one abandon the XP practice of defined roles? I think what I find that works the best is to let people expand a bit more than confine them, which enables those around them to also think of people outside of their specific role and see them for the value that they can bring to the situation. So for me, no, the XP formal defined roles do *not* enable people to do their best every day.
Q4 – praised or recognized in last 7 days…while I agree with Dunrie that management influence and workplace culture plays a bigger role than simply Agile/XP practices could, one minor form of recognition occurs in the Show & Tell. If based on a 1 week iteration, one shares what they have accomplished in the last week and can subsequently feel a sense of recognition for it, allowing others to share in recognizing the work completed. The XP practice of breaking tasks down into smaller pieces of work does indeed help to foster this.
The upshot – I do agree with most of Dunrie’s comments, and do feel that an Agile environment addresses most of the issues in helping to build a good workplace. I do not feel that the implementation at our last place of employment really played to the benefits of Agile. The short contracts and frequent ‘on the bench’ time actually worked to pit people against one another for the next opening. I think your term of people being ‘hungry’ is a good one to explain the feeling at that workplace. When you’re hungry all the time, you’re just working to meet your basic needs, and not being your best or doing your best. Looking back at my time there, I feel bad for *not* being able to be at my best there and for the negative impact I may have had on others. It was a stressful situation – but I don’t believe is typical of Agile environments.
Yeah, I think you’re right: formal roles serve Q1 rather than Q3.
Basically they help define expectations concretely. That was one thing our former place was good at: storycards, really formalized roles and ritualized interactions. But, unless one is perfectly suited to someone else’s definition (unlikely) those formal roles will interfere with Q3. I recall a senior developer saying he had to turn part of his brain off to come into work. Eventually, that just gets painful and annoying.
That role formality also served their business model. Essentially, because of the transient nature of the team, they needed to be able to train up and deploy new folks all the time. And, our favorite client from that old place did say that consulting shops in general experience a lot of pressure to produce consistent product, so making cogs is something that their process/business demanded.
As Chris and I have discussed, that level of formality and ritual was great for training new folks, but they found it difficult to maintain and hold the senior folks…