One question I get asked a lot is whether Agile can work in a unionized environment. Fortunately, I have had the opportunity to work in a unionized environment. The engagement did not start out as an Agile engagement, but as the project wore on there were more and more opportunities to influence in more and more Agile methods. The engagement itself was to help set lead the implementation of a solution into an operational support area. Doesn’t sound very Agile right? But I thought it was a great opportunity to try to extend Agile practices into the realms of Application Management Services, otherwise known as Maintenance and Support.
Without a doubt, the people I met and worked with were some of the most client-focused, motivated people I have ever met. (Hi Catherine!) In fact, everyone on the project team was incredibly focused on value to the customer. At every turn, there was mention by people of the impact that current issues were having on the end clients and co-workers. Were there a few people who were the stereotypical ‘Union-worker’ ? Sure. But in my experience the percentage of those type of people are pretty consistent across both unionized and non-unionized environments.
There were a few issues to used Agile that were perhaps more prevalent in a unionized environment though.
Roles – The primary challenge was that unions typically have a large component of their footprint being the formalization of roles and the responsibilities of each role. In addition, the corporation itself also further segmented these roles into functional departments. These functional departments, like Quality Assurance, were the only departments that was authorized to perform those tasks. An interesting thing happened on projects though. People from these different functional areas were assigned to the project and the project was then given the authority to use them in whatever way they saw fit. The projects were also co-located. So the projects were quite a bit more Agile compared to the rest of the organization. But you always had to be careful so make sure everyone was totally happy with how the team self-organized as one person could submit a union grievance if they did not like the work they were doing and if they thought it was outside their official role. Unfortunately when the project was over and it was transitioned to the Maintenance and Support areas, we were less successful in having the team self-organize and had to adopt more structured roles. It is an interesting note that the client knew that this structure was not as responsive and efficient, but they required the process to be aligned and use their current organizational structure. <sigh>
Compensation – Compensation in a union environment is again a very formalized process and is based upon role and seniority. As we worked on the projects, it really did hamper the ability to recognize people even in informal ways. (like offering to buy someone a lunch) If you wanted to offer someone a perk, you had to offer everyone the same perk whether they were involved or not. This seems like a small thing but it ended up being a constant conundrum for the project.
Documentation – The documentation requirements were quite extensive for two reasons. One, they used documents as the transfer of knowledge between one department to another. Two, they evaluated people’s competencies and their readiness to be promoted to the next level based upon the deliverables they can produce. As you can imagine, this was a problem in trying to move toward more Agile methods. In addition, these documents frequently sat on the shelf for long periods of time after they were produced and became stale. <big sigh>
Hierarchy – Once we transitioned to Maintenance and Support, all departments had managers that assigned work. This was a traditional push system of work. The people were not empowered to pull work at all. Eventually this was a major issue as it really limited the ability to be Agile and focus on Value and Flow.
What did we do?
So you may be saying to yourself, this seems like a failure and Agile can’t work in a unionized environment. I would say that is incorrect.
One aspect that I thought we were very successful was implementing a Kan Ban board and limiting Work in Progress(WIP). The Kan Ban board was also extremely helpful in letting management see exactly what we were working on. Until we implemented the Kan Ban board, it was not uncommon for people to be juggling 20-30 items at once and not informing people of issues. As you can expect, the team also was very energized and focused by the use of the Kan Ban board combined with a Daily stand up to discuss the work they had planned for the day. These practices are still being used today in that area.
As far as the other issues discussed, although they were prevalent in the union environment, I have seen them exist to an equal or greater extent in other large corporations. These are not just union issues. I would propose that they are management issues. I believe they contradict Agile as they place the someone else’s needs above the client.
Can Agile be implemented in a union environment? I would say yes, but there are challenges that need to be addressed. But just like anywhere else, you need the commitment from management that the client’s needs and value will drive the organization’s structure and not the other way around. The challenge with a union environments is you need this agreement from not only the company’s management, but also the union management.