10 Tips for Successful Agile Transition

Joshua Kerievsky gave 10 tips for successful agile transition at QCON San Francisco 2007:

1. Begin all transitions with a readiness assessment: Figure out if you are ready and if you are what kind of agile to apply.

2. Leverage the power of non technical and technical practices

3. Evolve by learning a little of everything. Start with a whole. Do not start with a fragment. Don’t do fragile agile. Whole enchilada transition: Broad brushstroke transition

4. Educate the organization antibodies: use pilot project community and begin educating right away future project communities. Don’t sell pair programming. Sell the risks of solo programming (tunnel vision, less productivity, less knowledge transfer, longer times fixing bugs, less code re-use, poorer testing, etc.)

5. Business trumps process: most of the time, but not ALL of the time. We need to manage the technical debt.

6. Engage the entire organization: Management, customers, support, development

7. Pick a big important project: Do some little ones to start, but at some point in the transition, you have to do a big one to avoid the antibodies.

8. Handle scaling problems: use parallel knowledge transfer for training part using e-learning

9. Metrics: Do some on your own, put if you want to get serious read Larry Putman’s book

10. Fail fast: use automated tests. Work iteratively.

This presentation is available at InfoQ at http://www.infoq.com/presentations/10-tips-for-agile-transitions

Craftsmanship and Ethics

Bob Martin gave a talk about craftsmanship and ethics and wondered if we as developers have a profession. He defined a profession where as a body we can agree on a set of rules to follow. With the rise of agile techniques, developers have become more disciplined. Bob covers the following disciplines:

a. Short iterations (1 or 2 weeks). Plan, code, testing, documentation (complete cycle resulting in deployable software.

b. Don’t wait for definition: instead participate in the definition process by demonstrating working code.

c. Abstract away volatility: look at what is likely to change and separate it from what is not likely to change. (do not mix gui with business rules).

d. Commission instead of omission. It is better to experiment than to wait.

e. Decouple from others: write stubs to ensure your code can run and to define your interface

f. Never be blocked: always find some way to make progress

g. Avoid turgid viscous architectures: they do more to impede progress than it is to help. Built to create perfect architecture to solve all problems that may come up. Go with simple architectures.

h. Incremental improvement: check in the code better than when we checked it out.

i. No grand redesigns: they generally do not work very well. “tiger” team constantly trying to catch up with maintenance team

j. Progressive widening: Add a small feature from top to bottom (GUI to database),

k. Progressive deepening: Get something working in one layer and then move it down to other layers. 1st make it work, then make it right, then make it fast.

l. Don’t write bad code: It does not only slow down others months from now but will slow you down immediately.

m. Clean code: Only way to go fast is to slow down a minute and write clean code. Readable, obvious, small functions, good names

n. TDD: Follow 3 rules: 1) not allowed to write production code until you have a failing unit test, 2) you are not allowed to write more of unit test than is sufficient to fail (not compile is failing), 3) you are not allowed to write more production code than is sufficient to pass. This forces us to keep the code executing all the time. Tests make the software flexible and maintainable.

o. QA should find nothing: our attitude and approach should be that QA should find nothing.

p. 100% code coverage: strive for constantly achieving 100% code coverage. Managers should not use this number. Professionals should use it.

q. Avoid debugging: Don’t jump into the debugger. Look at the code 1st. Use TDD. Debugger should be last resort.

r. Manual test scripts are immoral: Playing with system should be explorative testing. The other vast majority of testing should be automated.

s. Definition of Done: All the tests are passing.

t. Test through the right interface: Do not test business rules through the gui. Test gui connected to a dummy (mock) layer.

u. Apprenticeship: We have to grow the new members of the team and transfer knowledge to them

v. Use good tools: open source community care about the code they write, like svn

w. Green band on wrist: A symbol of ethics. “I will be a professional developer”

This presentation is available on InfoQ at http://www.infoq.com/presentations/craftmanship-ethics