I just got back from DevTeach Montreal all. For those of you that weren't there, what an awesome conference. Small enough for a lot of personal interactions, large enough to have an outstanding speaker's list.
I like the that DevTeach has such a strong agile track. It brings in a lot of people I rarely see except the MVP summit and DevTeach. For those of you that do not know, the MVP summit is gigantic and I don't find it a good place to step outside my core focus areas. The Alt.NET conferences have so far been scheduled when I could not go. So, for me, DevTeach is the perfect place to grab the process fix I occasionally jones for as a very independent independent consultant.
DevTeach has over fifteen time slots and I sat in sessions for about 6 of them (other than those I was giving). My own balance, without much planning, was about what I would have selected on theory, around 20% process, the rest technologies I want to learn more about. I am far more interested in getting the technology right than the process right - but if you screw up the process you're still hosed.
Which is a very long introduction to my impression of the one agile talk I got to at DevTeach.
To set the stage - the session is in a beautiful cabaret hall. There are box seats, two balconies and fabulous staircases. Red carpet and white and gold trim with lines of itsy bitsy lights outlining everything. It looks very much like someone took the insides of a fine old theatre and built the basement of this 36 story Marriott around re-hosting this theatre. The hall is small, but it is one of the most beautiful halls I've seen. Oh, and someone in the community was playing fabulously on the baby grand when I walked in.
I knew it was a fish bowl. This means there are a set of chairs (5) and exactly one is supposed to be empty at any time. People come up and join the panel, and immediately the one who had been there longest leaves. Happily they did this on one of the audience levels, not on the stage as that would have made it more difficult to see the equality of the fish bowl format. I was very impatient to get the startup stuff done faster. It seems a waste of time to establish and vote on over a dozen questions when you have time to talk about three or four. But, this signifies how easily I grow impatient in a 75 minute session.
Much of the conversation was predictable. People must have been in Twitter land as I didn't pick up any overall reviews on this session. I'm not giving one, as I want to focus on exactly one question - paraphrased to - What is the core or agile technologies or paraphrased again what is the bare minimum required to say you are doing agile. So, to start the list, I threw out testing. I struggle with the concept that someone can claim to do agile without testing. I really thought we'd build up a list of 6-10 core techniques. You can do agile without pair programming, but you can't do agile without continuous integration. That's the sort of conversation I expected from what I honestly thought was a rather inane question.
This is not what happened.
Oren Eini, sitting next to me, immediately disagreed. He said "It is shipping". I was (probably visibly) aghast. How could someone like Oren disagree wit the notion of testing?
But my purpose of being in a session, any session, anywhere, is to have the edges of my perceptions and knowledge tugged larger. So, I considered what Oren was saying and realized that with a couple of caveats he's right.
The core of agile is shipping with confidence often enough to maintain feedback cycles.
There are three points in this statement:
- shipping: completing things and making visible progress that can be measured
- feedback: having a clear path to understand what needs to be done
- confidence: concerns of the past do not need to be concerns of the future
Shipping means regular iterations. I like 2-3 weeks with a set schedule. Some iterations are small, and some are bigger. Plan for this and make good use of everyone's time in the iteration review. Shipping means a version of the application is ready to test and demo.
Feedback comes at a few different levels, all important. There is a level where the code feeds back to you. Smells are certainly one part of this, but it feels like more than that to me. The code whispers in your ear whether things are going ok, and its up to you to meditate on this. Maybe you'd rather call it gut feel than whispers. This type of feedback is the gauges, the sounds, and the smells of your project.
At the second level, you get feedback from pain. If your continuous integration, source control, granularity, or something else is off, it's hard to work the way you want to work. As long as you continue in your commitments (such as frequent testing and delivery), I think this is the least important. It's not threatening your project, it's just wasting time and causing pain. Don't confuse this feedback with the more important feedback of code smells and whispers or champion feedback. This type of feedback is the transmission for your project. It arranges for the engine output to be delivered to the wheels.
At the third level, you get formal feedback on features and bugs. A key reason for regular iterations is to fertilize the process of getting small chunks of feedback frequently. Feedback also relies on "done, done". It's not 90% done, it's done and ready for testers. Future iterations reflect the issues that are raised. This type of feedback is the engine that drives the process.
Confidence means primarily that what you've delivered works, and will continue to work. This is where the testing that I was so keen to label core belongs. Automated testing in and of itself is not critical. It is a technique - a means to an end. It is not critical if you have another route to knowing that done is done and that what you've delivered works as expected and will continue to work in the future. It is the only technique I know of that offers the level of confidence I want, but its at least an interesting question how else that might be addressed. Of course its not the only part of gaining confidence in your deliveries. You also need (at least) a consistent build and a way to track source code changes.
I don't think its particularly revolutionary, but I did find it interesting to cut through all the variations of agile techniques and boil it down for myself to that one statement.
The core of agile is shipping with confidence often enough to maintain feedback cycles