goto; Aarhus 2011 – Day 3

The final day of the conference kicked off with a great keynote, and my favourite presentation of the conference in the afternoon – Linda Risingsadly I had to leave early to catch my flight home so missed seeing my ex-ThoughtWorks colleague Alistair Jones speaking.

Keynote: Applying Design Thinking and Complexity theory in Agile Organisations

Jean Tabaka began her keynote with a story of trying to produce an agile cookbook to help a company implement Agile. She used complexity theory to explain why this approach is doomed to failure: most organisational environments are complex, the same actions do not always produce the same results, so we must look for emergent practices instead. She emphasised looking for resilience over robustness, and effectiveness over efficiency, and suggested that we can use design thinking techniques to help.

Architect track: Seven secrets every architect should know

Frank Buschmann talked about the importance of architects staying involved with the development teams they represent, and emphasised that architecture needs to be designed for understanding and maintenance, as well as to support the key system functions. He suggested that an architect’s job includes implementing a walk skeleton of the architecture, end-to-end, to prove it works well, and that they should continue to work closely with developers, pairing and writing code, while still maintaining a view across the system. I particularly liked his description of an architect as “the eye of Sauron”!

Java: Titanic, COBOL and the 100 year platform

Ola Bini kicked off with a check for any attendees from Oracle, luckily there were no takers. For the first part of his talk, he discussed the key attributes that a platform needs to support to take it into the future now, including lightweight threads (fibres). For the second, non-technical section, Ola described some of the processes by which Java and the JVM are updated, and how implementations like Apache Harmony are unable to be licensed for certain uses – the basis of Oracle’s lawsuit against Google. He lamented the lack of openness around much of the work Oracle have done and are doing with Java and the JVM, and speculated as to whether this may hurt the platform. With Java 7 out, Java 8 delayed until 2013 and discussion already going on around Java 9, he discussed some of the upcoming changes such as the introduction of the lambda.

Tools and Performance track: Personal Kanban

Troels Richter declared at the start of his talk that his goal is for us to want to try his Personal Kanban technique, and it only took less than half the talk for me to want to give it a go! He used his own web based Kanban board to demonstrate how he first visualised his own workflow (backlog, this week, today, pomodoro, waiting for feedback, evaluation, done) and then applied work in progress limits – which, interestingly, he’s breaking. The evaluation stage is interesting: here he asks what value the activity had and whether it helps to meet core goals or values. The Kanban board the Troels used was online at kanbana.com.

Tools and Performance track: Coffee, Tea or Agile?

We now sleep less and use caffeine to wake us up in the belief that this is the way to be more productive. Linda Rising suggested that these habits date back to the industrial age and factory workers, but ultimately the effects of caffeine can be more harmful than good. My personal favourite slide of the conference was Spiders on Drugs, when she asked: would you want the spider on caffeine writing your software? Looking at the mess it had made of it’s web is almost enough to put me off tea! Our bodies have a natural rhythm, maybe we should start listening to it, taking regular breaks – even naps – to maintain productivity and focus.

Tools and Performance track: Lightning talks

First up: Ola Bini charged through 28 slides and two demos in eight minutes, all in an attempt to convince us of the general awesomeness of Emacs.

Tudor Girba talked about the search for innovation, and how we can examine our own wrong assumptions by presenting to others, demonstrating our ideas, and looking for challenges to them.

Fred George presented on how we can remove things that kill productivity from our culture – in particular, fear of failure, and extra roles that create the need for more meetings to transfer knowledge.

Martin Thompson said that in software, we sculpt models. It’s art, which is better when it’s minimal and not overdone. If we get too hung up on what we have, we don’t learn – we need to refine and change the models in our software, while keeping their identities the same.

Kevlin Henney described the link between productivity, personal effectiveness and happiness. By taking up street photography, he sharpened his senses, increased patience and creativity, which brings benefits to work as well as his personal life.

goto; Aarhus 2011 – Day 2

Day 2 of the conference, and after last night’s conference party there are a few sore heads and yawns. With user groups taking up part of the afternoon, it was a slightly shorter day, but still plenty of good sessions and chat in between.

Agile at mid-life track: Fractal TDD

Steve Freeman talked about how We can use tests to help us identify places in our system that need to be refactored, in particular where we may want to begin pulling out new classes to take care of things like logging. He presented many examples of code before and after refactoring, so that it was clear how the changes could make the code clearer and neater. Many of the changes introduced for tests also had uses and benefits in production. He also described common unit test smells: too many assertions, magic set ups and long, long tests with an unclear purpose.

Technologies and Tools: Programmer Anarchy

As so many of my ex-colleagues work at Forward, I wanted to see what all the fuss was about, and Fred George didn’t disappoint! He described their working environment with a high level of trust both within the development team and between them and the business. One of the interesting points for me was how all of the applications are tiny, just a few hundred lines each. Instead of creating one monstrous codebase, each application just does one thing and does it well – like store data, or produce one report. This also means they can use the best technology for each part, and they use a wide variety including hadoop, clojure and Ruby. It certainly sounds like a programmer’s paradise.

Agile at mid-life track: Beyond Retrospectives

Linda Rising reminded us all of the importance of retrospectives as a driver for change, rather than a whinging session. She suggested at the next stage beyond retrospectives is continuous feedback: why not have a real time timeline in the team area? Some other things we can all try: take five minutes at the end of every day to reflect on the small wins of the day, experimenting with one or two new practices every day, making all meetings stand ups or even standing up to work (moving more keeps us healthier and happier).

Agile at mid-life track: Measuring Progress and Performance in Large Agile Developments

Andy Carmichael described his role as a lead scrum master across about a dozen scrum teams, out of a total of a hundred. He acknowledged the management attitudes that make it difficult to run agile in large, waterfall organisations, such as wanting to harass the team (sorry, “give them a pep talk”) when it doesn’t look like velocity is high enough. It’s not easy to move management away from the belief that the guys doing the (shortened) upfront planning are “all knowing” when it comes to estimating large projects accurately, and towards considering how to change the plan when things go wrong. The metrics were detailed and I can think of many managers I’ve worked with and for who would love this kind of visibility, but I can’t help thinking it moves the focus away from trust and empowerment.

goto; Aarhus 2011 – Day 1

It’s been a pretty awesome first day at goto; in Aarhus – after the first keynote, I found myself gravitating towards the DevOps sessions, which were really interesting. The .NET track was also good, and I was sorry to miss Rebecca Parsons – whose idea was it to put both Rebecca and Jez on at the same time?!

Keynote: Dart

Lars Bak and Gilad Bracha present a technology preview of Dart, a new language for programming on the web. Syntactically, it looks a bit like a cross between C# and JavaScript – which is unsurprising as there was a deliberate attempt to keep the syntax familiar. Types are optional and type errors don’t prevent the program running, instead the type checker is designed to help the programmer. The code compiles into JavaScript to run in the browser, and in future we may see support added to Google Chrome. My first impression was that it looks like it’d be pretty cool to work with, so excited to have a go.

They presented a news reader and a cool clock project running in the browser, both written in Dart.

More info: Tutorials and language specification, open source project

.NET track: Conventions – make your code consistent

Mark Seeman presented an interesting and very technical talk, using dependency injection with Castle Windsor as an example of where we can introduce conventions to reduce the amount of code we need, therefore making the code more maintainable. He used a series of well prepared code examples, also demonstrating the app working, to make his points. By describing the conventions we want to use within the code itself. Enabling conventions make it more straightforward to extend the code using the conventions, restraining conventions such as unit tests ensure developers are following the conventions in place. Mark presented an interesting example of a unit test used to prevent references to the DI container popping up in any assembly except the outermost one.

Mark’s code on github

DevOps Track: Evolving Continuous Delivery

Like all of his DRW colleagues I’ve heard speak or follow, Chris Read succeeds in making me quite jealous when he describes their working environment, with clients sitting next to developers, and happy to accept a higher level of production bugs than most places I’ve ever worked! This acceptance of risk means that they are able to push out changes within 30 minutes of writing the code – on average. What I liked the most about Chris’ talk was the message that the things we’re told when we start doing agile – continuous integration is important, automate tests – still hold, but the implementation of them varies greatly. Just like with agile practices, how we manage continuous delivery must also vary to suit the team.

DevOps Track: Scaling DevOps

Jez Humble’s talk was polished and engaging, covering the need to bring ops and development together in large organisations in order to deliver better quality software, faster – which is of course what he’s best known for writing and speaking about! The two key insights for me were that reducing the cycle time will mean people are less than 100% utilised (and conversely, aiming for 100% utilisation increases cycle time), and that deployment pipelines can actually be a great tool for helping audit software delivery, possibly for SOX or ITIL compliance. I only wish that more companies grasped these concepts from the top, and used them to manage projects.

DevOps Track: DevOps Fools, Tools, and other smart things

Patrick Debois’ talk was focussed on how tools can help us to change our ways of thinking, and cultures. He talked how tools can encourage about collaboration and how two people from different backgrounds, like development and operations, can combine to make “creative chaos” – and that may not see the benefit of collaboration until we look around to see its effects. He emphasised that we should use tools to find new ways of working – be creative and look under the hood. If a tool only has one way of using it, that’s a problem – given an API, we can find new ways to innovate with the tools we have.

.NET track: Developers have a mental disorder

Greg Young was loud and entertaining, the perfect talk for nearly the end of the day. Taking the view that abstraction is “programmer porn” and developers love to solve problems that nobody actually has, with abstract solutions, he tore holes in many common development practices. A couple of things that made me think: it’s easy to measure DRY, but the flip side of removing duplication (coupling and complexity) is much harder to measure, so we optimise for DRY. Many tools take away the pain we cause ourselves by writing bad code, making it much easier to do just that. Most complicated problems can be worked around without the tools. Many of his observations had me laughing, or groaning in recognition, but I still have no idea how to convince others of the truth behind them.

Keynote: Cool Code

In other careers, like writing for example, we would look at other people’s work, particularly good examples of it. Kevlin Henney suggested we should do the same for code, and produced many examples of “beautiful” code. Some is literally beautiful, like the C program that depicts a part of the globe – and when run, outputs itself with a 45 degree movement. Another example was the chess program as long as 4.8 tweets. Some of the best code will never be used in enterprise applications, but it’s ingenuity and sometimes sheer playfulness makes it provocative.

Simple Design and Testing Conference

The Simple Design and Testing conference consists of two days of Open Space discussions between a small group, primarily developers with a keen interest in Agile. It kicked off in London on March 12th with lightning talks for introductions, before lining up the Open Space sessions.

On Day 2, Liz Keogh held two sessions that were closer to presentations than discussions: Feature Injection and The Evil Hat. Both were excellent, and it was quite a nice contrast to the open space sessions to have a couple that were more structured.

Tell Don’t Ask

Tom Crayford kicked off the session by asking what if all methods returned void? There was a lot of discussion about the patterns followed in the “GOOS” book before the group moved on to talking more about functional programming. Although I didn’t contribute much the discussion was interesting – I’d love to try a coding kata one day with all methods returning void, it sounds like an interesting challenge and I’d like to see how it turns out :)

Writing Tests against a Legacy Codebase is a Good Thing

I was looking for good ways to convince people that doing testing – unit and acceptance tests – against a legacy codebase is a Good Thing. I thoroughly enjoyed the discussion and plan to post more about it later, but what I found most interesting was the difference of opinion even within the group. Coming around to really, truly seeing and believing in the value of writing and maintaining automated tests can be a very long process.

Speculative Coding

Many teams and organizations still build software a layer at a time, with teams divided along technology and architectural lines. Entire APIs are built before the client that will consume them is started, with work being wasted because we speculate as to what will ultimately be needed. Finding ways to get fast feedback such as attacking the most complex and interesting scenarios first can help to avoid this waste.

Wicked Problems

I’m still a bit of a newbie when it comes to Systems Thinking, and I hadn’t heard of Wicked Problems. The definition is that this is a problem that doesn’t have a solution. You don’t know when you’re done, and you can’t experiment – every possible solution is a one-shot operation. Like testing software. You never know the best ways to test the software until you’ve done it. Liz pointed out that the same could be said of analysis. It was an interesting way of looking at things, and I definitely left the session with even more respect for testers.

Simplicity Debt

If we try to keep things simple, do we just defer complexity to a later date? Complex problems usually require complex solutions. We quickly realized that we didn’t really have a common understanding of “Simple”. Does it mean the least amount of effort, or the most elegant solution? Is simple really the opposite of complex, or do we actually mean the opposite of compound? I think we all came away from that session thinking wow, simplicity really is quite complex.

Feature Injection

Liz explains feature injection as a pull system to derive the requirements for the features we want by starting with the vision for a project. To meet the vision, we must achieve goals, which require the system to have certain capabilities. Features work together to form capabilities, and features are further decomposed into stories. Liz suggested that stories having true business value in their own right is often a myth – the main value of stories is that they can be completed on their own and provide a means to get feedback as fast as possible. Most stories can’t be shipped alone.

The other really useful insight from this session was that we often talk about stories from the point of view of the user, but in actual fact most of them are not for the user’s benefit. Does the user really want to see adverts on the page? If we think about the story from the stakeholder’s point of view, it’s far easier to articulate the goal – As a stakeholder, I want adverts on the page, so that when users look at the page I make money.

Why do we estimate?

Estimates, Daniel Temme proposes, are lies. There’s no value in lies, so why do we persist in trying to estimate all of our work? Why can’t we just put the work on the board and pull it in, and it’s done when it’s done? It’d probably be done faster if we weren’t wasting time estimating (and complaining about it). There are companies out there like Forward and DRW who are doing this successfully, blogging and talking about it. I haven’t made up my mind where I stand yet on this one.

Liz’s Evil Hat

I thoroughly enjoyed the Evil Hat talk. I think I just like hearing other people’s horror stories, and Liz has some great ones. It’s also a really interesting point of view to take, which is that most measurements and metrics are really just opportunities for people to game the system. Even if you don’t do it deliberately, that little devil is always on your shoulder, whispering in your ear.

Types of Testing

This session had been born out of a confusion in a previous one between terms for tests like functional, integration and acceptance. I think in the end, we were in general agreement that functional and acceptance tests and scenario tests are pretty much all the same thing. Integration tests usually test the interaction between two or more objects, but not the entire system. In the end, I think the most important thing is that your team have a common understanding of what you mean. Your functional test by any other name would still be green and shiny :)

Jasmine Testing Dojo

We attempted to run a jasmine testing dojo later in the afternoon, but ran into technological challenges (Liz had the only projector adapter, and she’d left for lunch …) but we managed to write a few tests and use some spies! I’d love to create a short Jasmine testing workshop to run in a user group in future, so watch this space!

Retrospective

We all agreed the weekend had been a great success, although for next time hopefully we can get more publicity and a slightly larger group. Finally, off home to rest my brain and have a well deserved glass of wine …

Launch 48

Launch48: inspiring, frustrating, mind boggling, fun, stressful, knackering, rewarding, and probably life changing one way or another. It’d better be anyway, since I’m missing the ThoughtWorks Christmas Party to attend.

Friday

The Conference

I check in at the PayPal offices and receive possibly the largest ID badge ever, for which somebody had the brilliant idea to print the agenda on the back. In the main room, small clusters of men sit amongst empty seats, discussing what I can only imagine are the next big thing in mobile. I’m terrified: I have no ideas, I’m here for the hackathon, where are the geeks and the girls?

Then Cathy sits down and says hello: she’s friendly and smart, and I’m inspired by how confidently she’s networking already. At last, things kick off with keynote speaker Darren. He’s engaging and insightful and I’m soon tweeting the highlights, but, as @otaku_coder comments: “Interesting how it seems to be only me, @ecobela and @jocranford tweeting at #launch48, this is a mobile event!”

@ecobela turns out to be Bela: the girls may be small in number this weekend but we are loud all right. I debate whether to STFU, but nobody’s complaining yet and I’m enjoying myself.

The presentations continue: 15 minutes each, which is the perfect length. John Lunn (Head Wizard at PayPal) is entertaining and I can’t wait to try Appcelerator; the VouChaCha founders give us an insight of what life can be like if we take our newly hatched business forward after the weekend; and Andy Munarriz of Hullomail gives me a new favourite word: featuritis.

Microsoft and Adobe have speakers at the event, which is great, but they can’t quite follow Ian’s countdown timer and overrun.

(Note: for a summary of the talks, Ben Wirtz published a great Launch 48 Conference Summary)

The messages I take away are that it’s hard to make money from mobile, and we will need to market our apps. Targeting more than three platforms is very tough, and the same UI doesn’t work for different platforms.

Pitching

At some point during the day, I decide I’m going to pitch, mostly because I find the whole idea terrifying. Ian draws out the anticipation for as long as possible with a Q&A panel before pitches start, with advice that is spot on although leaves me still with no real warning of what I’m in for.

Once I’ve pitched, I’m desperate to win, and I anxiously try to count the raised voting hands. Competition is fierce with some brilliantly entertaining ideas including “PeePal” and “Flitr”. There’s a tense silence as Tom grapples with Excel, then the results are in; and so am I! YES!

Forming Teams

My team members are a well mixed group, and I’m grinning like an idiot because it’s such a buzz that they chose me, and probably also because the beer has started to flow. We try to Clarify The Idea (as directed by The Launch48 Booklet).

There’s a lot of energy but I feel like creativity is stifled as we debate whether the app should work offline for users abroad, and where to get data. I grab a flip chart and attempt to find something we can agree to focus on, but it’s a struggle, and although we eventually agree on the user scenario, the same issues and questions continue to rear their head all weekend.

Saturday

Getting Started

At Tesco on Saturday morning I stock up on sweets and post-its, and on arriving I decorate a corner of the office with flip chart sheets. Scope control is going to be tough so I dedicate one sheet to Featuritis in the hope that if the ideas are captured they will not derail us. I scrawl “Build the simplest thing that could possibly work, then iterate!”, a mantra which the Launch 48 blog pokes fun at when we can’t agree scope.

The team have been hard at work already: we have a rough PhoneGap prototype, contact list, elevator pitches and a business plan. I write it all on flip charts and ask the team to underline the parts of the elevator pitch that they think form the heart of the app, this turns out to be “Simple” and “Custom Itineraries”. Despite my frequent and sometimes desperate references to this throughout the day, we battle to find a level of simplicity that we can run with.

I take the lead by default, and at first it’s fun. We create personas: Waldo and Susan are immortalised on the wall, but almost immediately we lose traction when we try to figure out how Susan will find our application: is it per city, or one app? The team seems unable to put an issue aside for later, so our first board meeting is a welcome distraction.

First board meeting

We sit in a row in front of the mentors. Ian grins at us like a child hiding something unpleasant behind his back, and I worry that a grilling is coming. It’s not as bad as I’d anticipated though, and we survive the gentle questioning. We admit that we have a data issue. The mentors suggest Yelp, Wikitravel, YQL. We need to sort it, and fast.

Ian gives us a to-do list. Blog post, marketing plan, business plan, technical architecture, UX designs. I’m slightly baffled; it’s a lot of businessy stuff, when do I get to hack a cool app together?

We divide and start to conquer the to-dos, and we make some serious progress on the business and marketing plan, at the cost of fragmenting the team.  The business team come up with an awesome name, Itiner8, and Patrick grabs the .com.

Progress on the UI sketches stalls: we can’t agree on how many buttons the initial screen should have. I want to JFDI, the others want an optimal UI now, and time slips away. Mentors stop by to lend their experiences, but even with this incredible expertise we struggle to reach a conclusion.

I’m tired of wading through mud; I want to code. We watch the Appcelerator demo, but Patrick seems pretty set on using PhoneGap, which he’s already familiar with. Data is still an issue, nothing seems to meet our requirements, perhaps because nobody really knows what they are.

Mentoring

Mentor Dan Moon visits our sofas and delivers a solid kick in the backside: choose a project manager and get going with building something, fake the data, just get it done. He doesn’t understand why everything is such an issue. Most teams are already halfway through their app.

Mark asks if I want to project manage, but I firmly decline and point out that he’s doing a far better job at the moment. Blatant flattery maybe but it releases me from the responsibility.

Coding doesn’t get far before I am distracted by the UI designers, who are sitting around a table producing pages of beautifully drawn iPhone screens. They are discussing aspects of the application that I don’t feel form the meat of it. I bluster in and announce that we need to keep it simple, and they are overcomplicating it. This is not what we discussed this morning. I succeed only in convincing them to dig their heels in further, and I want to tear my hair out.

I seek out Dan, who advises that we should get together, sort it out and move forward. Feeling like I’ve just grassed someone up to the teacher, I return and ask Mark to call the team together. My emotions and frustration are running high, and things get sticky when we try to discuss scope – neither side is giving an inch. With only ten minutes until our next board meeting, voting is 5-5, and we head in to get our mentors’ advice.

They’re not impressed either, the app should be mostly done by now. We file out and get back to work: I struggle with the back end while Patrick tries to get the PhoneGap app working.

The business guys have an excellent idea: write a short survey to gauge a price point, so we tweet the link.

Finally I head home to continue working on the back end and source some Yelp data, which turns out to be pretty good. I wish we’d tried it earlier.

Sunday

Prototyping

I’m early and take advantage of the quiet to indulge in playing with Appcelerator. After trying to keep the team focussed, I really shouldn’t be wasting time when we have half a PhoneGap app already, so it’s a guilty pleasure.

Overnight the results to the survey have poured in, and Rafael has produced an impressive looking HTML prototype overnight. I suggest that we take it to Starbucks and try it with real people. Later on, they do, and it goes down well.

We sail through the board meeting, although our actual app development is sorely behind schedule. I discover that Ernesto is a Ruby wiz, and suddenly we are rubbing along a whole lot better. He introduces me to Mechanize and soon we are pulling wiki data for our descriptions.

When Patrick has to leave unexpectedly, I opt to try and build something simple in Appcelerator for the demo on Sunday evening. This backfires when I run into an awkward bug, and the final offering for our demo is fairly pathetic. I had a lovely time coding it though.

Final Presentation

The final presentation has been written by Mark and the others so as we line up at the front I’ve only a vague idea what they’re going to say. Mark dodges the awkward questions about our finances, as investment banker Zuza put them together and she’s left already. We have to swap laptops halfway through to demo, and we can’t get the slides back up afterwards, so we’re not looking too smooth here. In our defence the presentations had been brought forward due to the tube strike. Ultimately, Mark does us proud, and Rafael’s prototype looks slick.

With the presentation over, the emotional blackmail begins: are we going to carry it on? There’s a weak desire to meet up and see what happens, but by the end of the evening Mark admits that he’s not going to drive it any further. Caught up with everybody’s enthusiasm it’s difficult to say that this is it, but my heart’s not in it either.

They think it’s all over …

I tidy up the flipcharts and post-its and pack my computer away. Finally it’s over. I find a beer and mingle with the people I’ve met this weekend, and make sure I’ve handed out my business cards. I chat to some of the mentors and marvel at the quality of people I’ve met.

For all the frustration and craziness, I can’t wait for the next Launch48.  This weekend has already changed my life. Monday morning: I steam into work, ready to go, with more energy and drive than I’ve had in weeks. I’ve already got another mobile app idea turning over in my mind, and this one, I will finish. Maybe.

Agile 2006 – my highlights

Over the last couple of days, I’ve spent some time collecting my ideas and thoughts following Agile 2006. Spending the time to reflect has really helped to tie up the loose ends that were hanging around in my head, at least the ones from last week. I’m glad I took the good advice to stay away from email, well as much as possible, because for the first time in a while I’ve really got into “the zone” and it’s been incredibly productive. So here’s a brief summary of my highlights, and for a summary of all of the sessions I went to, check out the Agile 2006 page.

I went to so many worthwhile sessions, it’s hard to pick my favourite, but three in particular really stand out:

Ron Jeffries and Chet Henderson’s Planning Game – this session is great for two reasons: firstly, it’s fun and entertaining, and secondly, the lessons just reveal themselves through the game: to the most value from an agile project , you need to have clear estimates for the stories, you need to know your velocity, and the business needs to assign a clear value to the stories. Armed with this information, you can get almost all of the project value in the early iterations. Combine this with small, frequent releases, and then you start to see the real value of being agile and iterative. Ron and Chet have performed this session a lot, and it shows. It really is a performance, the banter and role playing were fantastic, especially in the Management role. If you haven’t done this, and you get a chance to, do it.

Programmers are from Mars, Customers are from Venus – Angela Martin and Robert Biddle – this was a highlight for me because it had some really practical, relevant guidance on splitting up the role of the customer into nine separate roles with specific different responsibilities – including acceptance tester, UI designer, negotiator, diplomat, and technical writer. They also suggested techniques such as having programmers play customer apprentice to improve interaction, and having a customer counselor for those times when you just need to vent. The powerpoint is really simple and clear, and it was good to attend a session that really focussed on and sympathised with the customer, rather than the team. I don’t play the role of customer, but it did give me a much deeper understanding of why it isn’t always as easy as you think.

The Test-Driven Development Pairing Game – Peter Provost, Mitch Lacey, Brad Wilson – this was the one session I refused to miss, and I’m glad I went, even though I had to leave Diana Larson and Esther Derby’s session on retrospectives, which I was also really enjoying. Brad and Peter have a great energy and humour, and they’ve created their own way to productively get the better of each other. Anything that makes writing unit tests fun for developers is pretty impressive, and their solution to write a single test and then pass the keyboard so that the other person makes it pass seems to go some way towards doing that. They somehow demonstrated something that combines two fairly complex practices in a really simple, easy to understand way, and entertained a group of people while simultaneously writing clean code. That’s pretty impressive. I’m just hoping that when I demonstrate it back home, it will seem as easy.

The biggest highlight of all was just meeting and talking to so many people who were doing agile – people who were still experimenting, who were learning from the same mistakes I am, and people who’d done it over and over and could share their experiences, or had the patience to listen to mine and offer advice. Over the next few weeks I hope I can share some more of my own experiences as I try and put some of these things into action!

 

Forming, Storming, Norming, Performing

During Agile 2006, one of the presenters (unfortunately I forget who!) mentioned the “forming-storming-norming-performing (adjourning)” model of team development. I recently found a good powerpoint by Glen Alleman on this subject that describes the stages and their characteristics. Since a number of people were interested at the conference, I thought it would be useful to post the link here.

Glen Alleman – Forming-Storming-Norming-Performing

Agile 2006: The Test-Driven Development Pairing Game – Peter Provost, Mitch Lacey, Brad Wilson

Thursday 15:30 – 17:00

Abstract

A new twist on pair programming that combines test driven development, or test driven design, with pair programming to create a game.

Summary

This was the only session of the entire conference that I had decided in advance there was no way I was going to miss. I’d heard about the technique and was really interested to find out more so that I could take it home. I wasn’t disappointed – Peter and Brad have so much energy and passion, and their constant banter made the session really entertaining.

It was a live demonstration, and the application they chose to demonstrate it (building a simple bank account object with unit tests) worked really well – I intend to use the same idea to demonstrate back to my team.

There are three legs to the development “stool”:

  • Test driven design
  • Real time code review
  • Refactoring

Developers want to get the most out of their time, and traditional pair programming can be boring for the navigator. The driver is the tactician and the observer should be the strategist, but in practice they are often thinking about email, lunch, or what they’re going to do next.

TDD evolves the design of the system. In TDD, a test is written before writing the code, then just enough code is written to pass the test, then the design is improved: write – run – refactor.

Refactoring improves the design without changing the functionality. If more tests are necessary, then it’s not refactoring.

In the TDD Pairing Game, the keyboard is passed at every step, which means it goes back and forth very rapidly – each step should not take more than 3-4 minutes. The pair negotiate over disagreements, so it ends up being a process of negotiation. The test writing drives the design.

  • Step 1 – write a test that compiles, but doesn’t pass. Pass the keyboard.
  • Step 2 – write enough code to make the test go green. Pass the keyboard
  • Step 3 – either write another test, or go back and do one refactoring.

The rules of the game are simple:

  • If the test light is red, the next step must be to make it go green.
  • If the test light is green, choose whether to write a successful test, a failing test, do a refactoring, or stop and think strategically about the system design – use the whiteboard to diagram it, etc.
  • If the system doesn’t compile, the keyboard can’t be passed.
  • Don’t write too much code. Throw exceptions if things are not yet implemented. You’ll be surprised where it leads you if you don’t write too much code.
  • One test at a time to evolve the game.
  • No email, no phones with email, no IM.
  • It’s recommended that developers should check in as much as possible – at every green light, if it’s cheap enough. Source control is a big giant undo button.

Tests have three separate code “paragraphs”: arrange, act, assert. Set up and teardown are considered evil – factory methods can be used instead. Whether we unit test edge cases or not, is a design question.

Ideas for new tests are kept in comments in a list, which evolves as you start coding. If a test gets too big, comment it out, then go back and refactor.

Recommended further reading

Avoid Setup and Teardown – http://www.agileprogrammer.com/oneagilecoder/archive/2005/07/23/6261.aspx

Agile 2006: Programmers are from Mars, Customers are from Venus – Angela Martin and Robert Biddle

Wednesday 13:30-17:00

Abstract
Being an XP customer is a lot of work, but this can be separated into roles and split among multiple people. There are also practices that can be used to make the customer’s life easier.

Summary
Of the entire conference, this was probably the session that gave me the most practical tools to take back to my team, and in the most straightforward way.

It’s a lot of work being a customer in an Agile project. Rather than heroic programmers, we’ve moved towards needing a heroic customer – there’s a lot to do and it can be exhausting. Many customers need to be available to the programmers to answer questions when they are needed, but still have to fit in their other work. However, most customers agree that the reward of having working software every iteration does make it worthwhile, so how can we redress the balance?

The customer role can be divided into nine sub-roles to form a customer team. One person can take on more than one role, or they can be taken on by different people.

Geek Interpreter
This person helps the customer to understand the programmers. This is probably not a full time job.

Technical Liaison
Almost no software development project is new, so there is a need to integrate with existing organization technical infrastructures. This role takes the responsibility for making sure that the integration happens in a sensible way. It may or may not be a full time job, depending on the business.

Political Adviser
This person helps the customer to get agreement from others in the organization. It’s always an unofficial role, to help the customer get through organization politics.

Acceptance Tester
This person works to support the customer and define acceptance tests.

UI Designer
This person designs how the system looks to the end user, which creates requirements for the system itself.

Technical Writer
This person creates the documents required for the end users of the system.

Diplomat
This person supports the customer in the organization, talks to the people who “matter” and report back.

Super-secretary
This person completes the administrative work necessary to support the customer.

Negotiator
This is the traditional customer role. This person must be flexible, agile, and decisive; able to work at the big picture and detailed levels. The Negotiator is the point of contact for developer questions, although would likely field these to the acceptance tester.

There are also several practices that can be used to support agile customers:

  • Programmer on-site – to help programmers understand the users better.
  • Customer apprentice – to help programmers understand the customers better.
  • Programmer holiday – allow the team to spend a week or an iteration focused on technical debt, refactoring, or spikes – while the customer has time to catch up.
  • Story standards – common templates for the stories.
  • Show and tell – to show the sponsors the return on their investment.
  • Look before you leap – create a business case for the features, and use release planning.
  • Be prepared for the “three month crisis” in long term projects, when they realize “their eyes were bigger than their stomachs”
  • Plan for this and be upfront when things slip
  • Customer pairing – divided geographically, or by functional line
  • Customer counselor – to allow venting, and to coach the customer

Agile 2006: From User Story to User Interface: Collaboratively Designing and Testing User Interface – Jeff Patton

Wednesday 09:00-12:30

Abstract

The user interface can be designed from the user story by following a process to define the UI tools to be included, then creating paper prototypes to test the usability, without focusing on the visual design.Â

Summary

The user interface consists of five layers:

  • Strategy – why is the software being built? What’s the usage context? What are the business goals?
  • Scope – tasks for the page
  • Structure, skeleton, and surface – this is where the user interface and prototyping takes place.
  • Understanding the task-centric scope defines the page structure. Tasks should be defined at the role level – i.e. a person engaged in an activity, e.g. shelf stacker. Create personas to represent people the product would serve – this allows focus on specific people in the design. Consider their skills and aptitudes.

When modeling tasks, consider the goal level:

  • Cloud – on going, business level goals, e.g. communication
  • Kite – long term goals, e.g. manage email
  • Sea – tasks that could be accomplished in one setting, e.g. send an email
  • Fish – sub tasks that stitch together to form a task, e.g. enter “to” address
  • Clam – sub tasks that form larger sub-tasks, e.g. look up an email address

Stories should start from sea level – at this level, if a user accomplishes the goal, they will consider themselves successful in doing something. Remember – “if you stay below sea level for too long, you’ll drown”. At this level, there is no UI design decision. As stories are split into small enough items to work on, the design starts to take shape as they become more granular.

A good user story is an example of use. They should follow a format:
As a [type of user]
I want to [perform some task]
So that I can [achieve some goal]

They should describe the goal, not the solution.

When moving towards a UI solution, use Constantine and Lockwood’s “Task Case”.

The next step is to define the UI tools for each of the system responses that will allow it to meet its responsibility to the user. UI tools can be three types:

  • Container – contains and presents information
  • Action – allows execution of an action
  • Actionable container – contains and presents information, and allows it to be acted on through selection or manipulation.

Once we have a list of the UI tools, it’s straightforward to create a basic paper prototype, and test it with real people, get feedback and refine it. This saves the time investment in creating and refining a real prototype.

Recommended further reading
Designing the Design Process – http://www.leaonline.com/doi/abs/10.1207/s15327051hci0502%263_6;jsessionid=ipItXBeszOt5o2aYbZ?cookieSet=1&journalCode=hci

The powerpoint from this session also includes further explanations and useful diagrams.