A co-worker just shared a powerful TED talk, “Yves Morieux: As work gets more complex, 6 rules to simplify". Yves discusses how our current pillars of organization are obsolete and he shares their solution...
The Smart Simplicity Approach:
- Understand what our people do
- This requires regular interaction.
- Reinforce integrators
- Have the power and interest to ensure others cooperate.
- Increase total quantity of power
- Empower everybody to use their judgement, their intelligence.
- Extend the shadow of the future
- Tie people to consequences of their actions. ie. In order to achieve low warranty costs, car designers are later in charge of the warranty process. Developers also do customer support.
- Increase reciprocity
- Remove the buffers that make us self-sufficient. Remove dysfunctional self-sufficiency.
- Reward those who cooperate. Penalize those who do not.
- From Lego: Blame is not for failure. Blame is for failing to help or ask for help.
"You start looking at the interplay of employees."
"The real battle is not against competitors, it is with ourselves!"
I tried to connect his recommendations to my current workplace. We didn’t do so well. How about your group?
Yves talks about the importance of minimizing "complexification" and encouraging collaboration. While I have heard some discussion towards encouraging cooperation, I feel that the actions are pushing even harder against it. I feel barriers to communication and collaboration. We battle the complexity of a code base that was created by cowboy coders. We battle the complexity of additional meetings in order to make decisions and transfer knowledge. In order to achieve what we want, it feels like we need to add even more processes. I once heard that the only way to solve a complex problem is to remove things; complexity cannot be solved by adding.
I encourage you to ponder what he discusses and see how it feels to you. Some of it may make you feel uncomfortable at first, but if you look past your comfort zone, does it make sense to you?
While I had difficulties seeing these points at my company, I was intimately familiar with them. I feel that all of these points are directly in-line with the values of eXtreme Programming (XP); Simplicity, Communication, Feedback, Respect, and Courage. It has had these answers since 1996, building on ideas and practices that have been around for far longer. They understood that values are fuzzy, so they created Principles to tie the Values to Practices. It is battle tested (over 17 years) and well documented. Some companies attempt to achieve continuous delivery with legacy processes. I applaud them for their tenacity.
I collected a few thoughts about each of the “6 rules to Simplify" (listed above) and how they relate to XP:
1. Understanding requires interaction. XP ensures continuous cooperation. It ensures I know what my coworkers are doing, what they are capable of, and, most importantly, what they excel at; so we can cooperate effectively. Do you operate in a vacuum; unaware of the knowledge, capabilities, weaknesses, and interests of the people you sit next to? How can you possibly earn, or give, respect without that knowledge? Without a high level of interaction? (See: Communication, Feedback, and Respect)
2. Reinforce integrators. XP uses the title of Coach. There is little need for time management, task shuffling, and status meetings. The Coach is a part of the team, pairing along with everyone else, with full visibility into progress, blockers, tendencies, and issues. Full visibility... organically. They are facilitators and impasse blockers. Like a sports coach, they get on my case when I hog the ball, even if I score, because they know the team could have scored more, if the team was working together.
3. In order to use my judgement, I have to know the whys. Are you privy to the appropriate Feature discussions? Do you know why fellow coders have made the choices for their code? Do you find yourself throwing up your hands saying, “I don’t know why it was done this way. I'm not sure if I can change it." (see: Communication and Courage).
4. We need to feel the consequences of our actions. We need to see how the code we write affects others, including developers who were not privy to our conversations. Do your current practices support that? Developers need to see how their changes affect load tests. We need to get out from behind our desks. We need to meet customers. To work with customer support. To sit with the other teams, within our company, as they use our tools. Some may balk and we may give in to their cries, but we do it knowing that, in the end, it decreases our team's effectiveness. (see: Communication, Feedback and Respect).
5. Remove dysfunctional self-sufficiency. "We don’t fear anything because no one ever works alone." (see: Communication and Courage).
6. Cooperation: I encourage you to listen for this at standup. You will notice that some groups discuss who they are interacting with to achieve each task, some rarely do. I also encourage you to ask yourself what have you done lately to increase team productivity? To make it easier for a teamate to do their job?