I always have so much fun at Agile 20XX conferences that it sometimes feels anticlimactic when they end. This year, however, I was lucky enough to get one of the last few tickets for Corey Haines’ latest CodeRetreat in Orlando.
The CodeRetreats are focused on having fun while learning, and follow a simple formula: 45 minute sessions of pair-programming on Conway’s Game of Life, then deleting all the code written and taking a 15 minute break. As well as giving up his time, Corey organises a storming lunch. Thank you Corey!
Deleting the code, for me, is the magic. I didn’t fully understand until Corey tutored me out of my outside-in, BDD habit at the last Code Retreat in Bletchley Park. “Why did you start with the Grid?” he asked.
“Well… because that’s how I’ll know I’ve solved the problem.”
“Are you trying to get things done?” Corey asked. “Don’t try and get anything done. 45 minutes isn’t long enough, and we’re going to delete the code anyway. Why not pick something interesting and see if you can find a different way to do it? Why not look at the rules, or a single cell, or the number of neighbours?”
I got it. CodeRetreat isn’t about solving a problem or getting something done. It’s explicitly the opposite. It’s about learning, even if that means you never solve anything or get anything done. The 45 minute period is just long enough to learn significantly but not quite long enough to make any real headway, unless you already know the Game of Life backwards.
As part of teaching BDD and driving out various BDD tools, I’ve produced multiple implementations of the Game of Life in Java and C#, to the extent where I already have a good idea of the classes I’m going to use. That can actually be a handicap in the CodeRetreat, because it makes it hard to learn anything new. I often find myself letting my pair take the direction, just to see if any other interesting patterns emerge.
In Orlando, we were lucky enough to have several great programmers amongst us – including Michael Feathers, Brian Marick and Uncle Bob. Having already experienced a cage match between Michael’s Haskell and Brian’s Clojure implementations of the Game of Life, I was excited by the opportunities to learn a new language. Brian was kind enough to show me some of the language features in Clojure. We didn’t really get very far with the problem, but that’s OK – the object was not to solve the problem, just to learn. Thank you Brian!
For the last session of the day, we voted to use a bit of extra time to conduct a longer session, and Bob kindly volunteered to help me continue exploring Clojure. We started with a function which would find all the potential candidates for life in the next generation, and worked from there.
10 minutes before the end of the session, we had a working copy, which Uncle Bob has kindly blogged here. The code is a little tidier and a lot more readable than the version we ended up with. I need to find out what conj and % do! We should also have deleted it, but since we had already gotten something done, it was too late.
Clojure turns out to be a very beautiful language, and Uncle Bob is a lot less scary in real life wonderfully patient mentor. Thank you, Bob!
The Pask Committee have given the Gordon Pask award to me this year for deepening existing ideas and coming up with some pretty crazy ones of my own.
I can only do this because of the fortune I have in my communities, including some great coaches on either side of the pond, the Extreme Tuesday Club, Thoughtworkers and alumni, and the wonderful online communities in Lean and BDD.
My communities give me a safe place in which to play and get feedback. I am a member of a community of thinkers, and if I should happen to be a catalyst more than others, I consider that to be a tribute to those who have inspired me. This is as much a measure of your success as of mine. Thank you all.
My Grandad
My Grandad looked like Merlin. He had white hair down to his shoulders, steel-blue eyes that sparkled when he grinned, and half his teeth.
My Grandad worked as an engineer during the war. He used to talk about the bombers, who always claimed they were able to hit a target, even though my Grandad pointed out that the practice “bombs” they were dropping hadn’t actually fallen into the nets he’d put in the targets. It was, he said, the only way to test whether they were telling the truth. He was a keen physicist, mathematician and astronomer, and had a marvellous fascination with history and pretty nurses.
In the last few years his memory, and his body, started to fade. He stopped being able to hold on to conversations, but still enjoyed doing the crossword. He read books and papers. He loved to drink whisky and eat sweets. The last time I saw him, we brought him some jellied fruit. “No thanks, Grandad,” I said. “You have them.”
“Oh, good,” he grinned, and hid the box. I never saw a smile on his face that wasn’t a grin – cheeky, half-mocking, and often poking gentle fun at my ever-patient mother. That’s how I’ll remember him; by that smile, and the sparkle in his eyes.
My Grandad passed away in his sleep last night. He would have been 98 next month.
Sleep well, Grandad. I love you. Thank you for making my world a better place.
A couple of people have recently written asking for advice on how to start writing scenarios. In both instances, they have started by logging in, because “that’s what the users do first”.
If you’re doing BDD, may I suggest starting not with the scenario that describes the entire user journey, but instead, the scenario that describes the riskiest bits of the journey?
Assume that whichever user has access to the system is already logged in. Logging in isn’t exactly risky. It’s been done 15,000 times before.
Hard-code the data to start with. Getting data out of a database isn’t very risky either. You can code this later without affecting the scenarios, if you can get some realistic examples of data.
Work out which bits of the system you know least about. Create the scenarios and have conversations around those bits of the system. You don’t have to grow the system from the beginning – you can pick any point you like! Which bits of the system make you most uncomfortable? Which bits make your stakeholders most uncomfortable?
Those are probably the bits which will cause your project to succeed or fail. Logging in can come later, and by the time you come to code it, you’ll have some real value that people want to log in for.
I’ll be running the ever-popular Haiku Workshop in the SPA2010 evening diversions on Monday 17th May. My focus for this is limited to 24 people. I’m not sure how attendance is being organised; however, if you want to attend and find out before I do, get in there quickly!
Ben Hall has blogged his use of WiPFlash together with IronRuby to test Windows applications. Thank you, Ben!
The example UI that Ben’s using is WiPFlash’s own. I particularly wanted to provide a pseudo-realistic application, so WiPFlash has a pet shop. It works in memory, with hard-coded data – the idea is just to provide a realistic UI. This has really helped me to learn more about WPF and Prism, and get useful feedback about what I’m doing wrong from people who know better!
I have a couple of additional features I want to add before we move to 0.X releases, then I’ll stabilise the interface and make sure it’s all configurable for 1.0 – so if there’s something missing which you’d need to use WiPFlash on your project, please let me know. I’m trying to keep this really light-weight, so I might say “no”, but I promise to make you feel good for asking!
I’ve kicked off another open-source project, WiPFlash.
This is a little automation framework with a number of goals:
- To let me learn how to do .NET UI Automation
- To fix a couple of things that White doesn’t do yet
- To automate scenarios as fast as possible
- To provide examples that anyone else can look at, if you want to do the same thing.
The project is written in C#, and is exclusively focused on WPF Windows GUIs. Currently WiPFlash can:
- Launch or reuse an existing application or window
- Enter text in TextBox, RichTextBox, and editable ComboBox
- Select values and retrieve selection in ListBox or ComboBox
- Retrieve values from RichTextBox (and its children), TextBox, TextBlock, editable ComboBox
- Click buttons.
It also provides an example of a Prism application, complete with MVVM paradigm, command binding, dependency injection using Unity, etc.
Please feel free to try it out and add any requests and/or issues, bearing in mind that the purpose of the framework is not to replace White. For instance, I have no plans at this time to support drag-and-drop or mouse and keyboard input, nor am I going to respond to bugs with WiPFlash not working on WinForms, SWT, etc.
If you’re looking for something similar for Java and Swing, check out my other automation framework, Tyburn.
I’ve wanted to write this post for a while, and reading “Metaphors we live by” has given me some language and ideas to express it in. So here goes.
Requirements come from above
In a straw-man Waterfall project, requirements are delivered to senior developers to design. Senior developers deliver the designs to junior developers to implement. Managers instruct teams in how to progress. We have, in our language and hierarchical organisation, a metaphor which maps “up” to the origin of the project, and “down” to the implementing details. We also think in terms of seniority and power, with the originators of the vision having that seniority and power, and the more junior developers and testers being at the bottom of the pile. We even talk about the team members “on the ground”.
Think of every organisational chart with the managers at the top, or the V-model in which the requirements are split into increasing detail towards the bottom.
In life, things naturally flow downwards.
Orders come from above
The other hierarchy with which we’re familiar is the military. We can map our employment and communication hierarchies to those of the military. We even talk about companies fighting for market share, defending their reputation, a hostile trading environment, captains of industry, command-and-control management, etc. It’s hardly surprising that we have, in our subconsciousness, another pattern: that the more junior members of a company should obey orders. (This isn’t necessarily true even in the military, but it fits our perception of it.)
Turning the world upside-down
I once heard of a business analyst who got tired of explaining the requirements to the developers. “I’ve told you three times already!” she snapped. “Everything’s clear. Just do it.” The BA sees the developers as working to fulfil her requirements. They serve her needs, rather than the other way around.
When we write and deliver software to a user on an Agile project, we ask them for their feedback.
- Is this useful to you?
- Is this easy to use?
- Is anything difficult to use?
- Does it help you to do your job more effectively?
- Can you think of any ways we could make this more intuitive?
- What would you like next?
Because we think of communication in terms of orders, we also think of junior staff delivering value to senior staff. We don’t necessarily think in terms of the communication itself being a form of delivery. If we did, we might ask for feedback from the users of our communication.
- Is this communication useful to you?
- How easy was our communication to use?
- Was anything difficult to understand?
- Did it help you to do your job more effectively?
- Can you think of any format you’d find more intuitive than this?
- Any questions?
If the BA above was a piece of software, her users would be filing bug reports, working around her, and using her competitors instead. I imagine instead that she’ll get a poor review and teams will prefer to work with her colleagues. If they only have the one BA to work with, the project will probably fail – the developers won’t be able to use her to get their job done.
Stakeholders aren’t users
I’ve written about this before, and it takes on a new importance in the context of users, and stakeholders, of communication. When we get a management report, we often think, “So what?” We hit the delete key. Instead, we could try to think, “Who is it that cares about us understanding this? Why does he care?” It’s often the case that a user is meant to do something, as part of his job, which is for the benefit of someone else. Similarly, we may be asked to understand or act on something for someone else’s benefit – and it won’t be the person delivering the message either.
The stakeholders of communication on a project are often stakeholders of the project itself – the security expert, the chief architect, the facilities manager, etc.
Project experience
Eric gave me the concept of a “Project experience”. In the same way that we can think of communication as a form of delivery, we can think of the experience that our stakeholders and customers have when they ask us, as a project team, to deliver their code. We can ask usability questions about the team.
- How easy is it to use the team?
- Is it easy to see what’s going on and get information about the progress of the team?
- Is it easy to undo a mistake?
- Is it easy to input a new idea?
We often hold retrospectives amongst ourselves to work out how to change our processes. I’d also like to see us actively getting feedback from the people who use the project. And next time someone gives you some instructions which are unclear or don’t help you to do your job, perhaps this metaphor will help.
Rob Bowley has set up a petition to ask the government to review the way in which IT projects are done.
I don’t know about you, but I’m fed up of hearing tales of Government IT failure. I even heard one story of a company asked to triple its bid so that a council department could spend, and therefore retain, its budget.
Reading Simon Baker’s post on metrics made me smile. I rant about similar misuse of metrics quite a lot. A common reason that I see targets and metrics fail is because they’re aimed at a perceived circle of responsibility – for instance, developers who are measured on how few bugs they produce. This ignores the possibility that something outside of the development team might be causing the bugs – poor analysis, a difficult technical environment, lack of a decent production-like staging platform, etc.
Simon’s post calls out another common local optimisation. He says, “…the true purpose of the people doing the work, which is to improve service and quality and satisfy users.”
One of the ways in which we can satisfy users is through usability and user experience. At one of the Agile 2009 keynotes, Jared M. Spool gave a beautiful example of why this could be a bad idea. He talked about a company that had reduced a 5-stage process to 2. The users loved it. “Unfortunately, they forgot that the company was paid per page impression,” he said. The company went bankrupt shortly after putting the beautiful new website in place.
In Feature Injection, Chris Matts calls out the people with the original idea, or the people who are investing in the idea, as the core stakeholders. These are the people who need to be satisfied. Everyone else is incidental, and the vision is usually one that either makes money, saves money or protects money (stops another company spoiling your idea, or stops them from stealing your market share). Everyone else whose input is needed to make the vision a success is an incidental stakeholder. This can include the users.
Here’s an example of how focusing on the true stakeholder can help. I was talking to a friend at XtC about a user-centric story.
As a user
I want register to be emailed when the game is released
So that I can buy it as quickly as possible.
I was discussing alternative ways of implementing this story which didn’t involve email. “Who really wants the users to be notified? Who’s actually paying to notify them?”
“Marketing, I guess.”
“Why do Marketing want the user to be emailed?”
“So that they can make a big hype about the game when it’s released.”
So, rephrase this from Marketing’s point of view.
In order to make a big hype about the game when it's released
As Fred, the Marketing guy
I want users to register for an email about the release.
Now we can see that perhaps, users may not want to register for the game. We might have to entice them with something else. We also see that our goal – the big hype – could be met by other methods; with advertising, for instance, or by getting favourable reviews in magazines.
By allowing the developers to focus on the goal, we may come up with different or better solutions. We also come up with different tests. Will the user actually want to navigate through the 5 screens we make them fill in to register? Will we get the big hype we’re looking for?
I find when using the Feature Injection template that I frequently put the real name of the stakeholder on the card. This means that if we run into trouble, we can go and talk to the stakeholder about alternate ways of achieving their goal.
They’re not user stories. They’re stakeholder stories.
Comments