Friday, November 18, 2016

Pull systems

If you've been around agile a while, pull systems are probably a thing you've heard of. This is not directly related to pull requests that are requests to review code, but with pull systems the idea is that in a process with many steps, the step after you determines when you should be producing. This is to avoid inventory (stuff lying around without moving forward) that is a form of waste.

If I think of my testing as a pull system, the consumer of my results is the developer making changes or the business person making decisions on accepting risks knowingly. It makes little sense for me to produce information that no one wants. There needs to be a consumer for that information.

However, the stuff we work on does not include clear cut rules of what people are interested in. No one can tell me exactly what these different stakeholders already know, and what information they find useful, or even more, if their finding something useful is correct as per their stage of learning about what is relevant. So, I shoot some info at them and stop to look at reactions. I try same or similar thing several times and stop to look at reactions, including if they even notice I'm trying establish a pattern. I have a heuristic that at a point they still reject the info and they see the pattern without me pinpointing it, we may be approaching a point where my time is best used delivering a different message. Except that time changes things, so it makes sense to try again later because it was clearly relevant enough in my perspective to conspire on getting the message across in the first place.

There's again a trigger I'm thinking through this. And the trigger is me realizing that pull systems thinking had become very ingrained in me and, as it turns out, some of my closest colleagues. Taken far enough, it means that no information is offered without you pulling it. Broadcasting things in hopes of serendipity can be considered waste.

One of the biggest puzzles for me with the new job in the two first months has been that it took forever before anyone offered me info I did not have to go hunt for. As a new employee, I felt lucky I was not here for the first time, so I knew things from the past and had the means to go for the information. But at end of every day, I've felt exhausted. Every day of work has required all my senses to be fully aware, and nothing has come easy.

I never sensed that this was ill-intentioned as whenever I would have a question, the response was overwhelmingly positive. No one refuses to help me, not by words, not by expressions. They are there whenever I know what I need from them.

And finally yesterday someone voiced out the words "pull system" when discussing my experience in our first ever (during my time here now) retrospective. We've been trained to think of pull rather than push, when we're trained agile thinking.When no one voices the idea of pulling information to a new hire, the new hire can end up feeling overwhelmed and exhausted without a good reason. In my thinking of plausible explanations of the behaviors, values/culture were high up on the list, but my guesses were targeted more towards individualistic culture ("I'd rather work by myself") than the idea of encouraging pull systems.

And there is such a thing as taking pull systems too far. When you're in a discovery process, you don't know what to pull unless you first discover more. Without broadcasting some information, you will minimize serendipity: the lucky accident of something relevant finding you that you did not know you could know.

The world is a balance. I'm still a big believer in pull, but some of the stuff we just need to push. Finding the right balance is fascinating, and I will think about this a lot more with regards to the ways I test. I still believe in teaching my stakeholders to pull information from me, remembering that I'm not the one fixing bugs here in the middle of the night if they escape into production. My expertise is valuable, and through pull system thinking, deemed more valuable by the consumers of the information I provide. But there might be stuff I need to just push through broadcast more. 

1 comment:

  1. My opinion is that it is very difficult to know what you want, if you don't know the possibilities. As a developer/tester you have the resposibility to know what the users of the system to build really needs. Most of the time it is nog what they say they want to have. You have to look to the goals of the user so you know the decisions he has to take. And then you can decide together what information he needs tot make those decisions. After that you know enough tot develop the needed system.

    ReplyDelete