3 New Year Resolutions for Agile Team Members
by Kelly Waters
Some agile principles come naturally. Others you have to work at.Here are 3 agile principles I think require an extra level of care and attention. Perhaps they'd make good new year's resolutions?
1. Work to fixed timescales
The end of a Sprint is the end of a Sprint. Not near the end. The end. Meeting fixed timescales means paying particular attention to the principle done means DONE! and managing code carefully. At the end of a Sprint, changes are either 'DONE!' or they are not. No checked-in code should be 'work in progress' at the end of a Sprint.
2. Focus on quality
Agile development requires confidence about quality at the end of every Sprint. That means strong (automated) unit testing and automated regression testing. Write your test cases up-front for each feature, as part of the requirements, not in parallel with development. Design your code to pass the tests. If you automate nothing else, automate the testing of key interfaces.
Agile development requires confidence about quality at the end of every Sprint. That means strong (automated) unit testing and automated regression testing. Write your test cases up-front for each feature, as part of the requirements, not in parallel with development. Design your code to pass the tests. If you automate nothing else, automate the testing of key interfaces.
3. Document appropriately
Agile documentation is barely sufficient. That's barely sufficient. Not insufficient. Nor non-existent. Write requirements as 'user stories'. Write a high-level architecture/design diagram for your solution. Write appropriate documentation for your feature to be re-used. Feature-by-feature, of course, not all up-front, nor all at the end.
Why not start the year as you mean to go on :-)
3 January 2008 03:34
The timing of writing requirements-tests at the time of writing requirements is really interesting. It is very powerful, because it provides feedback about the measurability of the requirements - resulting in better requirements. It is also potentially expensive or slow, depending on how the QA/BA teams inter-operate. Net net, I like the idea, but am trying to think through the gotchas before trying to tackle it. Also - my brain is in the non-agile world at the moment, because that's where my client is.
How has this played out in projects you've worked on? Specifically - are dev team members doing the reqs, test, and dev work? That's the only way I've done it - but I didn't do "write the test" at requirements time, just a "can it be tested" as part of analyzing the requirements. Then the test was either created as part of the WBS by the devs, or in "staggered parallel" by the test team - but after requirement sign-off.
Anyway, would love to know how it has worked for you, if you have time. Enjoying your stuff very much,
3 January 2008 08:46
I'll try to write some more blog posts in the near future about user stories and writing requirements and test cases up-front.
In the meantime though, here is a brief response...
I have done a little test-driven development in waterfall projects. In these cases, writing tests up-front with requirements is quite onerous because it adds to the large amount of documentation that needs to be done before you start developing the solution. Therefore it works best in a waterfall situation if you have a dedicated tester from the start to work alongside the analyst.
In an agile environment, it's less onerous because you're working on the requirements for one feature at a time, just before you implement it.
In this case you can capture the requirement in a very concise form and write down with the requirement how you're going to confirm that it works.
If you have sufficient testers that you can have them do this feature-by-feature as the requirements are written, great! If not, then it can be done relatively easily by the analyst or developer that's writing the requirements, although of course testers tend to be better at it! :-)
In practice, what I think this highlights is that there is a very fine line between requirements analysis and test analysis. And the difference between a requirement scenario and a test case starts to blur somewhat.
As a consequence of this, and because of the need in agile development for testers to be involved from the outset, I think the roles of analyst and tester start to converge.
This can present some organisational challenges, and in our case is highlighting a potentiall new role of Analyst/Tester. Who better to confirmt the requirements have been met than the person who wrote them?
Kelly.