Every effective software team interacts with the outside world. In fact, all the teams efforts will be totally useless if they don’t. These points, where the interaction takes place, I usually refer to as ‘team interfaces’ or ‘contact points’. They take the form of a conversations between people. For instance, developers talk to customers or another team. It can also be a contract or a written specification of a product, a document, which is written by someone and read by another person. Chances are that these points will cause a lot of friction.
If your are crossing a functional border. You are using this interface, this contact point. A functional border is the distinction between two functions. One function might be the software development team and another the maintenance team and yet another might be the customer. The focus of these formations and the fact that they do one fairly defined thing, for instance programming, make them a function.
I believe this to be quite ineffective but this is the way work is structured in many cases. It’s also quite common that these functions are scattered across geographical areas, organizations or sometimes both. I’ve even seen companies that have outsourced software development to one organization, maintenance and infrastructure to another and using a third organization to act as customer, instead of themselves. What a waste.
The number of organizations involved in this makes me think of a game I used to play as a kid when I went to birthday parties. After cake was served and you were sitting around the table one child, usually the birthday-girl or boy, whispered a word or a short sentence in the ear of the person to their left. So it went up until the last person, who was supposed to say whatever they heard out aloud. This always led to loads of laughter. I can not recall one single time the message was the same when it reached it’s end as it was when it left the first person.
My point being, information gets distorted. The larger the number of hand offs the more the information gets distortion.
But, what about agile then?
Cross functional teams is an important aspect of agile software development. To get the view and input from all involved parties as early as possible. To be able to use the feedback from real customers, maintenance, end users etc. This also means that you reduce the risks of information loss and distortion by bringing down the number of hand-offs. Or even removing the need for them at all. You are reducing the friction dramatically, by bringing functions closer to each other.
But if this is done in a push manner, from the recipients point of view, it will likely increase friction. Lets say you start delivering software three times as often as you did before, without the customer asking for it, you’ve started pushing. And thus the customer might get overwhelmed. Friction is increased.
Your job, as a software developer is to deliver value not ‘inflict’ value. What you should do is make sure the customer wants the updates. Only then have you turned the value stream from push to pull. A much better and smoother way to work.
Maintenance and support personnel also have their reasons to be restrictive about frequent releases. They might experienced a lot of problems with new releases in the past. New bugs, a new GUI, loads of phone calls from customers etc. This means that they too will likely resist when your team delivers software at a higher tempo than before. By making sure they want the releases, they are bug free, are easy to install i.e causes a minimum of hassle for them you can turn the value stream from push to pull.
There might even be a hardware team whom you’re interacting with or another software team who is dependent on your teams releases. Your acts, the frequency of delivery, planning or meetings with likely force them to adapt. See where this is going?
If you’re at the bottom of the food chain, where software usually is, you’re the one that has to adapt. You are the one that has to deliver software in a pull manner. Let your contacts pull value from you.
Design against demand
I was in a project once where we could release once a month or at least we thought so. We made releases. Built the software, made installers and delivered it to the customers. Later we found out that it wasn’t being used. The end users couldn’t use it because it lacked the most important functions. Talk about pushing out software. While we thought we had it going on, we didn’t really have a clue. The end users thought we just pushed out unusable software, 12 times a year. Talk about friction.
The force that should drive software must come from a real need. There has to be a real problem that software can solve. Then you design the work so that it is pulled by the end user, customer or whatever you want to call it. They dictate the pace. You job is to design the work against the demand.
You can be all out agile. You can respond to every single new demand put on your team/function so quick that no one knew what hit them, but if the organization as a whole isn’t working pull oriented you have probably just made a sub-optimization. And you are probably causing so much heat from friction you’re minutes away from starting a fire.
‘Flow where you can, pull where you can’t, never push’.