Individuals and interactions or processes and tools?

Individuals and interactions or processes and tools?

As the developer cheerfully runs over to work with Sue in the deployment team, with an extra cup of coffee, he is stopped by Charlie, the manager of the deployment team.

-Hey, where are you going?
-To see Sue about the deployment, the developer answered.
-Have you written a ticket?
-What? No, I’m gonna talk to Sue and we’ll do the deployment together as usual.
-Sorry, Charlie said, we have implemented a ticketing system last week, and you need a ticket. We can’t have developers running all over the place disturbing our team all the time!

True story.

That story actually happened at a client I was working with. The development teams had always been walking over to the ops/deployment teams and worked together on deployments (yes, CI/CD is faster, better and less error prone, but this was how it worked there at the time). This was some kind of spontaneous self-organization happening just in time, and the developers and ops people had a good relationship.  

The manager ultimately setting stop for all communication

Then suddenly they introduced a ticketing system in order to create traceability (so that they knew who to blame when it went south, I guess). Conversations then stopped between the teams as all talking was moved into writings in the tool instead. Needless to say, relationships deteriorated from there. It did not take long until I started to hear expressions like “developers know nothing about what we do or how complex our work is”, or “Gaah, do I really have to write this in the ticket, they literally sit 50 meters away!” and so on. Life was like that for a couple of weeks until I introduced a little concept known as DevOps.

At more or less all the clients I work with they are using Jira, finding it hard, overly complex and too much detail for what they need. When I ask the question why they use Jira if they find it not supporting their way of work, the answer is almost always the same; “I don’t know” or “we already had it in department X, so…”

Here’s another fine example. In SAFe, the hierarchy goes from Epics to Features to User Stories. In Jira it goes from Features to Epics to User Stories. The other way around of course. So the conversations are filled with misunderstandings as we don’t know if we are talking about a SAFe Epic or a Jira Epic.

I’ve seen this over and over again. We go directly to solutions, trying to find a tool without reflecting on what we want to achieve. When the tool is in place, we discover that it doesn’t really support the way we want to work, but then it is too late. What I would like to see isn’t so much a discussion on whether or not we can find the perfect tool, but rather a discussion on what behaviours that we want the tool to support. 

How come it is so hard to think about “Individuals and interactions over processes and tools”? What is it that makes people dive straight into tools and gadgets and become forced to a way of working dictated by a tool? Please share your thoughts in the comments.

10 responses on “Individuals and interactions or processes and tools?

  1. Global organizations, teams needing to work with other teams across the world. We can’t just walk over and talk to each other any more. We’re not even in the same time zone. Sometimes we don’t even have overlapping working hours. I believe this type of organization is a contributing factor to using processes and tools more. We have organized in a way which makes it really hard to talk to each other.

    1. True, good point!
      That makes it even more important to have tools that increase the behaviours that you want, not the opposite. So if large, global organizations makes it harder to communicate and thus collaborate, I would assume that they get tools that increases communication and allows collaboration.

      Interestingly enough, since the pandemic started and I’ve been in all remote mode with multi-national companies, large part of my work time have been listening to comments like “we can’t hear you, you’re on mute”, “can you see my slides now?”, “could someone please mute, there’s background noise!”, “it would be nice if you all could turn your camera on”, “Seems Leslie is having problems connecting” and so on. Now how productive and collaboration-friendly is that?

      1. One of the best setups I’ve seen for encouraging some teams that were spread between India and Sweden was:

        Each location had a room which contained nothing but video conferencing equipment. No chairs and no tables. We could open a call with the remote room with the press of a button, and it always just worked.

        So, anytime we wanted to have a quick talk between two teams, we just agreed on our chat that we would go to the video room, and then we’d have a talk there to sort out whatever it was.

        Everyone was clearly visible, we were standing up and there were no laptops or anything, just people having a conversation.

        This setup helped us form good relationships between the teams, which could have easily become a “them and us” situation.

  2. Here’s two more reasons:
    1. The engineer manager mindset. “I want run reports and analyze interactions to see how the teams are performing, so they must create a ticket for everything.” Oftentimes the reports are never actually used or produce no useful information except vanity.Related to the “weaponize-Lean-itis”, where the justification is “Lean says to be visual and transparent, so let’s create a ticket for everything.”
    2. Teams and individuals are spread too thin. They have many responsibilities to maximize “resource utilization” but at the same time they are dependent on each other. Result is a massive amount of handovers, which need to be queued in order for everyone to stay sane and be able to focus on one thing for more than five minutes at a time. Solution: create tickets to form queues (instead of solving the root cause).

  3. The counterpoint to this is that Sue was getting fed up with the developer coming over to have a 10 minute chat, followed by developer #2, #3, #4, and so on. Eventually, she asked Charlie to get in the way, as Sue wasn’t able to complete the work she’d committed to for that iteration.
    Your point is sound where Devs & Ops mutually respect each other’s time and workloads. I’ve worked in places where Devs see Ops as glorified button-clickers, to do as asked and when asked. True Story.

    1. Simon, true, but I do believe that you are missing the point. I used my dev and ops story as an example where a not thought through introduction of a tool made a fairly well functioning situation worse.
      In your example, introducing a tool would probably only help one part. The more thought through way of solving that is to collaborate with both dev and ops to solve the situation. A tool might help, but only if it enhances the behaviours we want, not the opposite.
      The right tool in the right place is often great, but don’t go for a tool as the first solution. That almost always fails. There is a reason to “individuals and interactions over processes and tools”.

  4. Mikael, thanks for your nice descriptions and the comments it raised. I believe you ask 2 questions. I see one being answered above. Good observations.
    The other question is about SAFe and Jira and the Babylonian confusion of terms. Very recognizable. However, I believe the Jira ticketing system was created to support ‘single team agile’ when the epic was only the ‘non-refined user story’, all fine so far.
    Then SAFe came along, introducing the 3 (or 4) layered system, and used Epic for the portfolio level. As soon as companies having ‘single team agile’ started using SAFe, the Babylonian confusion started.
    Is it fair to say that SAFe has technical debt, in that it should have used another word for the portfolio level items, like using Initiative (or feature-set)?

    1. Hi Ronald, I don’t think that SAFe sees it as tech debt, as it is how they view the organization of epics and features. But it still bewilders me why they chose to go against the community and introduce their own definition.

Leave a Reply to Mikael Brodd Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.