Thursday, June 11, 2009

The Pinball Principle

I read a fair bit about different development methods. Agile is pretty popular amongst developer advocates, but I would argue almost everyone in charge of development *actually* just runs with a grab-bag of "what works for them" taken from Waterfall, Agile, what their peers think, what happened on the last project etc. They'd be mad not to -- can you imagine running development based on what doesn't work for you?

Some people talk about bottom-up vs top-down, inversion of control, directed vs undirected, the importance of use cases, test-driven development etc. Usually, the argument is that if you tick whatever list is being advocated, better software will get written in an efficient amount of time and deliver what was ordered to the greatest extent. But, somehow, it never seems to work out that way.

There is a huge complicating factor, which is that most development activity is done due to an obligation owed by an employee to an employer, client or other stakeholder. The developer ends up responsible for not just managing their own development practises, but managing their clients through the process also. If there are just a few stakeholders, then that's easier (unless they're very difficult stakeholders). Issues come up when there are multiple stakeholders, and when there is conflict between those stakeholders. The best possible course of action ceases to be "build and deliver approximately X" and becomes "make all these people happy to the extent possible".

How does making people happy fit in with SLDC practises? Where do you stand firm, and where are you flexible? When do you tell your manager "we shouldn't do that" and when do you just fit in? How do you sell a use-case Agile practise to a control-oriented manager? What are the ethics of accepting your manager's control-oriented activities if you think things could be done better another way? When do you take a decision on your own shoulders? How do you actually adopt new design practises? How does it fit into the development team and the organisational culture?

Most people in an organisation run according to what I call the 'pinball principle', which is to say they get batted around by their key stakeholders, bouncing off obstacles, temporary victories, other groups etc like the objects in a pinball game. To some extent you can control your own fate and direction, but there are a *lot* of things which you can't control.

In a large development team, a kind of 'surface' will form around the team, representing that team's culture, which can protect those inside of it. However, some people either don't have a protective surface, or they are right on the edge of it. In these cases, you can't simply adopt a practise and hope it will result in better outcomes, you need to use personal insight to negotiate the situation you find yourself in, and no amount of 'best practise' will prevent your key stakeholders looking you in the eye and demanding action, their way.

The question is whether there is anything we can learn from the pinball principle. If our environment is so complex and demanding, is there anything about that which should inform our behaviour? Should we acquiesce to all incoming requests, devolving responsibility, and concentrating instead on doing the best job we can? Or will something like the Agile methodology allow us to write great componentry which will then turn out to be just the thing for the next request? Should we attempt to educate stakeholders in appropriate negotiation processes, or should we instead rely on meetings and face2faces to take care of things. What is the cost of attempting to enforce process?

If project direction is likely to be set by pinball mechanics, how can we best write software knowing that will happen?

I don't know the answers -- not all of them anyway. But here is *my* list of things which I think will help keep the development *direction* on-track, and best serve long-term development success. I have just come up with them now, but they are based on ideas which I have been refining for some time now. I'd love feedback on the list and this post!

1. Get all of the stakeholders into the same room at least once a month. Make them review their priorities in front of everyone else, and get agreement on the priorities for the development team.
2. Maintain a whiteboard or wiki with the top four development priorities. Focus prioritisation on the top four issues.
3. Email out a bulletin every fortnight without fail to all stakeholders and users who are interested, including the current priority list and progress achieved.
4. Hold 'air your grievances' sessions regularly (say twice a year), especially if there is a layer of bureaucracy between you and your end users. Don't minute them.
5. Identify what makes your stakeholders actually happy (i.e. less user complaint, positive feedback from other departments etc) rather what what they say they want (more progress for less money). You will only make other people happy by reducing the pressure they get from the pinball board. That's only sometimes the same as what they're asking you to do
6. Pursue a two-layer development methodology. Make the bottom layer whatever you like (Agile, TDD, Waterfall), and make sure the developers understand it. Keep on top of new ideas here. Make the top layer As Simple As Humanly Possible. This is your 'interface' process, and keeping it simple is the only way that others will follow it. If you can't explain it at the beginning of every meeting in two slides, then it's too complicated.
7. Document Everything.
8. Publishing = profile = perception. Make sure you nail the following items: project web page, prototype web page, email bulletins, conference/journal publications (if relevant), regular meetings/presentations

Regards,
-Tennessee