And now .... Agile!
There are lots of material out there about Agile - ironically for something which is about concentrating on the core important ideas of software development, there's a lot of waffle. For a discipline which is about concise communication over communication in bulk, there's also a lot of 600 page books being written.
I'm new to Agile, and learning as I go along. I'm not really an absolutely die-hard follower, but I do recognise that some of the key ideas of Agile aren't just "Agile ideas", they're good practices FULL STOP. Even if you're classic Waterfall, what it emphasises are "the important things".
The best place to start is the Agile manefesto - which is kind of like the tablet of stone from which all practices come from. And like any keystone of religion, there's a small bit of infighting over it's interpretation and application!
Basically the core values are,
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Nice words - so what does it mean? Well this is my take - and there are others.
Individuals and interactions over processes and tools
We've all worked in places where the processes in place can feel like shackles. Sometimes process has value - it can act like a safety gate - we have to formally be sure we're ready to test before testing.
But most often it feels like we're slaves on a galley ship chained to an oar.
Part of this to me is about saying, we're software professionals, and that's important. We're not children, we're professionals. If we act professionally we don't need safety gates to slow things down.
There's an example of this on a previous project. In order to formally run a test it had to be issued on our version control system. Problem was, only one person Andrea could do this. And she left at lunch on Fridays. This meant if we had a formal test ready to run on Friday afternoon, we couldn't run it until at least Monday - often afternoon (cos she'd have a backlog).
What's the point in having testers work full pelt if the process will actually derail them when Andrea is out on Friday, sick, on leave?
Working software over comprehensive documentation
You buy a new phone. You get it home, unwrap it, put the SIM card in, the battery, and get playing.
Least that's how I tend to do things. About a year later I find the instructions - and realise a few things I could do with it, but mainly the phone works, and I only really use instructions when it doesn't work.
Our documentation is like those instructions. It only tends to be of worth when the software doesn't work. At the end of the day, you're delivering to the customer software - they're not likely to worry too much about all the documentation you wrote.
I agree with this to a point. And that's this - there can be a tendancy with some developers to not to comment their code but shrug and go "hey but it works". The feeling is commenting slows it down. However good commenting is essential to the maintainability of the code.
Some developers feel threatened by this though - I have worked as a developer, and my tendency to comment my code made me more easily replaceable than a developer who didn't and "only I understand this module". It's kind of empire building - using knowledge as a bargaining chip. It's not the Agile way though - where it's about US not ME.
My other concern about this is about knowledge. If a project is documented, its possible to learn about the project, how it works, etc from that documentation.
Without it, you need a culture which will be prepared to teach and mentor new developers and testers to understand it. Alas on projects I've been on, there has been too much of a "throw you to the wolves" approach where everyone is expected to learn the whole system themselves.
To not mentor, is to devalue the individuals in your team - and it's again, "not the Agile way".
Customer collaboration over contract negotiation
Actually I probably have less to say about this. But it's about getting the customer onboard at all stages, showing them what you're doing, what you're going to do, rather than do a big end reveal, and when they frown go "but it's what you asked for".
There are lots of different versions of this cartoon - but it really elegantly shows the trap of many projects which use a contract.
If the customer had collaborated at all stages, they would have got what they asked, and the vendor would have not been stuck with the bad rep of giving their customer something they won't use ...
Responding to change over following a plan
Hannibal Smith in the A-Team used to say "I love it when a plan comes together".
Alas though, plans can fall apart.
Plans can be useful for mapping out the way ahead. But when there's a iceberg ahead, you need to stop, change course, respond to it. If you keep ploughing ahead, you're going to get struck and sink.
Things go wrong, things fall apart, people leave. You can build in so much contingency into a plan. But it's so much easier to manage the issues as they arise than try and have the foresight to predict every issue.
-------
Found yourself nodding along to some of that?
It's a kind of sign of solidarity "you are not alone". We're all veterans of processes which devalue our professional input, spending long hours on documentation that's never used, unhappy customers and rigid plans we can't achieve without excessive overtime.
Want to know more?
I recommend this book - Agile Tester by Lisa Crispin and Janet Gregory,
http://www.agiletester.ca/
First 200 pages are invaluable - the next 400 less so (if you're testing you probably already know this sections).
The work is in accordance with the movement. No one can resist nature.
ReplyDeleteSavan vegas