Developing Agile Leaders and Teams: A Developmental Path to Agile Leadership with Gilles Brouillette
A surprisingly interesting session to kick off Agile 2009, Gilles presented on developmental stages on how we’re influenced by the stage we’re in.
There are seven leadership levels, with most of us being in the ‘Heroic’ stage (Expert & Achiever). Perhaps a little bit disheartening, Gilles has suggested that
only 10% of the population is capable of operating at the ‘Post-Heroic’ stage.
- Opportunist
- Diplomat
- Expert
- Achiever
- Catalyst
- Co-Creator
- Synergist
There is an assumption that we move back and forth between the levels. For example, if we are stressed, we might slip back to the previous level. Also, the further developed you are, the quicker you are to adapt and the less defensive you are (less desire to hide your mistakes or need to know all of the answers).
Going from the heroic to the post-heroic stage requires a different mind set. A different way to think that is more strategic, more team focussed. An example is that a person at the heroic level will consider something a win if they manage to advance some aspect of themselves, we as a person in the post heroic stage will only consider something a win if they are able to advance some aspect of the entire team.
It was an interesting session and with the examples of the various levels, I was able to pinpoint myself somewhere between the Expert and the Achiever level, but I’ve noticed all too often that I’ll do something that that brings me back a level. Something I plan on working on for this year.
Craftsmanship wtih Robert Martin
Uncle Bob began the presentation by talking about how big plans don’t work, even if we’re wired to think they will. Actually, he started his talk with how electrons are fired form an electron gun through a filter and on to a screen to make a dot, but I can’t remember why now? Anyway, it came around to being about big plans and it all made sense at the time.
Big plans don’t work and even if we know it, there is a part of us that believes that if we plan enough, if we sit around this talk about everything we’ll get it covered and we’ll get it right this time. As much as we’re wired to believe that, it doesn’t work that way.
Complex systems that worked have invariably found to have evolved from a simple system that worked.
Complex systems that are designed from scratch never work and cannot be patched to make it work. Most people will start over, beginning with a simple working system.
Simple things live and evolve, complex things die a horrible and expensive death.
-
Short iterations
The consensus in the industry is that 1 to 2 weeks is the optimal iteration length. Bob believes that in a few years from now, this will drop to 3 to 5 days.
What gets delivered at the end of the iteration? Something that is useful and delivers value to the customer. The customer does not have to agree that the functionality is complete but every iteration needs to deliver something that works.
The Harvard Business Review had an article which concluded that the earlier you release, the happier your customers are, even if what you release is under-functioned.
- No grand redesigns
We are the ones that made the mess and we must be the ones that clean up the mess.
You don’ clean up your house by moving. - Incremental improvement
It’s not a technique, but a way of life.
A commitment to never making the source code worse.We have the mess because we don’t practice incremental improvement; we practice incremental destruction. There should be no reason why
a developer checks in source code in a worse state than they checked it out.Always improve the code as much as you can.
Every time you make a mess you will slow yourself down.Big Dave Thomas’ law of continuos improvements is that progress is a
sequence of decisions, some of them wrong. - The only way to go fast is to go well
- Clean code
Is an attitude, something that we commit to.
- TDD
- QA should find nothing
Every time QA finds something, we should be asking ourselves how did this get out.
- 100% code coverage
- Avoid debugging
- Manual test scripts are immoral
- Definition of done
All tests pass (unit, acceptance, UI etc), nothing less.
- Test through the right interface
Business rules should be tested at the business layer, not the UI layer.
You should test that the UI is wired up to your application, but do not drive your application from the UI tests.There should still be a few tests that drive all parts of your application from the UI, but these should be limited.
- Never be blocked
Never say to yourself that I can’t move forward because…
Uncle Bob ended the session with a quick note on how craftsmanship does
not limit you from taking shortcuts. You can implement code with the
intention of removing it in the following iteration. However,
shortcuts must be clean.
This aligns with some of the thinking that I’ve been doing regarding the
advice of “simplest thing possible that will make the test pass”. I’ve heard, perhaps even uttered,
this phrase when justifying code that is not clean, not well factored.
Perhaps we need to replace the “simplest thing possible” with “simplest thing that isn’t crap” :)
Integration Tests are a Scam with J. B. Rainsberger
Hoping to get some answers to my questions regarding unit testing vs acceptance testing, I went a long to the session by J. B. (Joe) Rainsberger. However, as it turned out, the session was about integration tests, with integration tests being defined as defined as any test where the result of the test depends on more than one object being correct.
The solution presented to the problem of integration tests was to isolate the service or entity being tested via interfaces and use mock objects to allow the class under test to be tested without bringing in the dependencies of other concrete classes. Once these dependencies are broken and you’re dealing with a single concrete object, the test is no longer an integration test but an isolated object test, or focused test.
Joe challenged the audience to write our tests using the single assert per test principle for 3 months. He wasn’t presenting the principle as the correct way to write tests, only that after 3 months of writing the tests as such, we would learn how to write better tests.
Joe also presented on the idea of Contract Testing, where you create a super test fixture class that tests the behavior of an interface and then create sub test fixture classes for all of the classes that implement that interface.
I was quite disappointed in how the talk turned into a unit testing practices session. Unfortunately this only became apparent around 45 minutes into the session and it was too late to change. It could have been a better session if it was more targeted as a way to improve monolithic and highly coupled unit tests and billed as such.
Before the session had started, Joe was talking about talking in E-Prime. E-Prime is a subset of the English language that does not use any form of the verb to be. He presented it as a way to be, or to project as being less judgmental. It sounds like an interesting exercise and something to investigate.
Swag
A drink bottle, Becoming Agile in an imperfect world by Greg Smith and Ahmed Sidky, Agile 2009 Conference book, Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R. Trott Real Options at Agile 2009 comic and a bunch of useless advertising.