We’re off and running at Agile2011! I haven’t run into any other pure hardware guys so I’ll take it upon myself to do a daily round-up for the hardware folks that want to follow along. No promises… but I’ll try and do the same each night that I’m here.
Day 1 General Observations
The first thing to note was the seating arrangement in the rooms. I’m used to rows of chairs aimed at a presenter and screen; you might talk to the person beside you a bit but for the most part, you’re their to be talked at (until a Q&A). The seating arrangement here… very different. It was more like lunch time seating where people sat in groups around tables. About 4-8 people to a group seemed the norm. More inviting for sure compared to just staring at a screen and being blasted by an information fire hose.
Today were the 3 hour workshops mainly. The goal of the workshops was to balance presentation material w/team exercises. Things seem to alternate between 20 or so minutes of presentation then 2-15min of team exercise. They had the feel of a training session more than a presentation.
Agile In An Imperfect World (9:00-12:30)
This was the first of the day delivered by Ahmed Sidky and Greg Smith. It was an introductory workshop that I really liked. Ahmed and Greg talked a lot about the Getting Ready phase of moving toward agile development. They stressed that with so many different ways to be agile and with all the different personalities within teams and organizations, by failing to understand what is motivating a team toward agile development and without an understanding of what an organization needs to improve, success is less than likely. A team needs to understand the motivation behind being agile and that being successful ultimately hinges on embodiment of the agile values and principles.
They finished with examples for incremental adoption of agile. The advice was to start by improving team collaboration and communication then as a team is ready, it can adopt other practices. They did note that even stopping at improving collaboration and communication can be beneficial enough for organizations. Does stopping there that a team agile? Doesn’t matter. What matters is it’s better off than it was before.
Slides for this talk are here if you’re interested. I’d recommend taking a look.
Agile Requirements Exploration With Tester Collaboration (1:30-5:00)
This was a workshop from Ellen Gottesdiener and Janet Gregory (Janet is from Calgary). The theme seemed to be acceptance test driven development, which I’ve not done before, so this was a more advanced workshop than I was probably ready for. It wasn’t so advanced that I didn’t get anything out of though! I just didn’t get what they intended :).
Honestly, I had enough in the first 45 minutes to ponder for the remaining 3 hours. They showed a V diagram similar to one I’d seen before in Brian Bailey’s and Grant Martin’s book ESL Models and their Application: Electronic System Level Design and Verification in Practice. While I was out of my element, seeing that diagram was extremely encouraging. Ellen and Janet explained how the tests identified at the validation level can be used to work out details in the specification (in TDD, development is driven by the tests) and also at lower layers to verify the system/architecture/implementation. That message was very similar to Brian’s and Grant’s description of a modified V approach where requirements validation happens first followed by system validation and so on down to the implementation. Besides the test-driven approach that Ellen and Janet were suggesting, the big difference would be how many features get built at once (a sliver of functionality in the software vs. all the functionality in the hardware).
The best part, however, was a technique they had for analyzing product features.
Normal for hardware teams is to be handed a specification with a list of features. We ask questions about the features that are answered by architects, CTOs, etc. Question. Answer. Done.
A different way to do things. Step one is still to ask your question (i.e. what does feature <blah> do <at some point in time>. Then list the reasons why you’re asking the question instead of asking for the answer. All the reasons why you’re asking the question could turn into one or more testcases. It could also force the person who added the feature in the first place to think about the context in which it’ll be used. That’s the short explanation of an idea I really liked. I expect I’ll come back to this as things settle in my head.
In summary, this was a great workshop as well. I’ve love to see it again in a few months after I’ve had time to think about it.
The Big Park Bench (5:30-7:30)
This was an interesting session where all but 2 of the authors of the agile manifesto got together to talk about the 10 years that had passed since they wrote it. It was nice to view this as a hardware developer and relative outsider. Hundreds of people sat in on this and you could tell most thought of this guys as complete rock stars. Everyone was taking pictures.
People had the chance to ask questions and the authors of the manifesto took turns answering informally. The sincerity from all of them was obvious. There were no agendas. All the guys seemed very selfless as they described how they put the manifesto together, what they thought it’s meant for software development and what they thought it would mean in the future. All were very grounded and it was easy to see they all thought a successful team experience was far more rewarding than anything an individual could experience on their own.
Most telling for a hardware guy like me… as they described what most believe is the significant (very, very significant) change in how teams develop software, I didn’t hear tools mentioned once.