Friday, June 29, 2012

Software Principles - Agile or not - 2 of 3

Continuing my theme of Principles, I’d like to outline my own principles of “Agile Software Development”. As I implied last time, these may be simply “Software development principles” but right now I’ll keep the “Agile” word.



1. Highly adaptability over highly adapted


Strive to make you processes, practices, team, code and environment adaptable rather than adapted. The future is uncertain and shows no signs of getting more predictable. Rather than try and predict the future and be adapted to it, strive to be adaptable to what ever may come.



Code design and architecture is a good example of this. Rather than spending a lot of time designing a system for the requirements you think the business wants - they may even aware blind this is what they want and sign in blood - accept that things will change.



Adaptability comes not from exhaustive contingency measures but from simplicity, reflection, learning and change.



Plan, design, for the short term but put in place mechanisms to roll with change. Don’t spend weeks designing, spend hours, be prepared to refactor, put in test frameworks to allow change. Sometimes there are architectural things you can do to allow for change - for example the plug-ins pattern - but these are fewer than you think.



Don’t implement this or any other architecture until you actually see the need for it. Don’t build it because you have a hunch.



2. Start small, get something that works, grow


In keeping with the principle #1 above and dis-economies of scale always start as small as you can, if things work then grow. For example: Start with the minimal viable product, if customers like you product add to it. Start with the smallest team you can, if the team delivers good software people use then grow the team



3. Need to think


Agile is not for those who want to follow a flow chart or for those who want to leave their brains at home and follow procedures. Indeed, if you are such a person then working in IT is probably a bad move in the first place.



Not every Agile method or practices will work were you work. Agile experts and methods disagree. You need to think about this.



You also need to think about what you are actually doing, what you have been asked for, and how you can work most effectively. Unfortunately economies of scale thinking has created a lot of companies whose modus operandi seems to be to stop staff from thinking.



  1. 4. Need to unlearn
Doing Agile practices is the easy bit. The hard bit is unlearning: the things you have to stop doing. If you have burn down charts you don’t need Gantt charts; if you have an automated test suite you don’t need a regression test process; if you have supplies you trust you might not even need a contract; etc. etc.

Things that have made us successful in the past are included here. Teams advance, companies change, to much baggage from the past is carried forward making life in the new world expensive. Remember the words of John Maynard Keynes:



“The difficulty lies, not in the new ideas, but in escaping from the old ones, which ramify, for those brought up as most of us have been, into every corner of our minds.” The General Theory of Employment, Interest and Money (1935)



5. Feedback: getting and using


Agile doesn’t work out of the box, as the two points above say: you have to find what works for you. Some of this might be obvious at first but the more you get into this the more you are dependent - in all sorts of ways - on feedback.



Feedback about the thing you are building. Feedback about the way you are working - as team and as individuals. Feedback about how your customers are responding. etc. etc. etc.



6. People closest to the work make decisions


The people doing the work are usually in the best position to make decisions about the work itself. They have the most knowledge about the work and they have the most immediate need of a decision.



Every time a decision traverse up a decision tree information is lost and delay is introduced.



7. Know your schedule, fit work to the schedule not schedule to work


Easy really. Know when something is needed by and fit the work to that schedule.



In part this principle is a reaction to Kelly’s First Law of Project Complexity - coming in the next blog entry.



8. Some Agile practices will fix you, others will help you see and help you fix yourself


Some Agile Practices - like planning meetings - will administer a fix and you will get a little bit better immediately. Other practices - like retrospectives - will not fix anything but will help you see what is happening and find your own solutions.



Most Agile Practices are somewhere in the middle. Iterations and stand-up meetings are good examples. They may fix some problems immediately - they will improve focus and communication for sure. More importantly they will help people see what is happening and will, in some cases, force you to get better at what you do.