Distributed integrated developers for progressive agile in the enterprise
Agile is a dangerous word today. It has been picked up by the buzz-word industry and the spin is interesting to watch. The interesting thing is that I’m not sure that the current agile practices have finished their transformation. We seem to be freezing the progress at a comfortable point and pumping out scrum masters. I’d like to think that the future of agile lies in a more complete integration and alignment of developers and the business they support. Allow me to present my humble vision for distributed integrated developers.
Scattered to the winds
First, a picture.
Now a thousand words.
(Warning: N=1 study ahead) My experience has pointed me in a general direction. All the technical prowess in the world does not make up for solving the wrong problem. In most cases the wrong problem is solved due to miscommunication and process built up around a relatively simple task. If people had taken the time to question what they were hearing and make sure everyone was in agreement then they would have saved countless hours of pain. It seems that the further the developer is from the action of the business users the worse the miscommunication and the project problems. I’ve had issues clear up immediately by just going and watching business users perform the actions that they normally would. The clarity and insight that comes from direct observation cannot be understated. The agile manifesto clearly states “customer collaboration over contract negotiation” so where did we go wrong?
Get uncomfortably close to your users
Enterprise developers are usually extremely lucky in that they have immediate access to their software user’s domain. They can ask them questions, do usability studies, and quickly iterate in a relatively low risk environment. Unfortunately that rarely happens. For one reason or another the development department is walled off from the business and in this isolated environment loses the benefit of being an in-house development department. My approach, as shown in the diagram, would be to plant a development group (ba, pm, qa, devs) directly into the department that they are supporting. The ability to work alongside and react to changing needs would greatly improve the groups agility. The development department then becomes purely the architecture group who are governing across and spreading the best practices between each distributed integrated development group. The architects could move in and out of the development group to work alongside the business and make sure their designs are effective in the trenches.
The theory is nice, but in practice it would <insert pessimistic view here>
The business unit would need to have visibility into the distributed integrated development group’s work. Standard agile practices should suffice here. The ability to clearly communicate priorities would get better over time as the business group gets comfortable with how things get developed and how reactive the team is to help pitch in during emergencies. The distributed integrated development group would need to possess discipline so the business unit did not drive and overrun them since they are outnumbered. This is where the architects’ guidance and firm hand would be helpful.
In summary, developers need to stop putting themselves on a pedestal as “blessed designers”. Developers are no better or worse than other members of the business. The development department should plant developers directly into the business. The agile revolution has not finished and cementing the process and collaboration at this point might be premature. Tear down the wall!
Feel free to try this and let me know how it works for you.