This is my summary of Nathaniel Schutta’s “Making web apps suck less”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

[various examples and illustrations of bad usability]

What does usability include in web apps?

• Learnability
• Efficiency
• Memorability – how easy is it to pick up an application again after a few months’ absence
• Handling errors
• User satisfaction

How much should you focus on each of these? As usual in software development, the answer is “It depends”.

• How many users will the system have?
• How often will they use it?
• Will they get training?
• Do they have alternatives to using your application?

How do you find usability problems?

• Ask users
• Watch them
• Try doing it yourself
• Just as comments are a code smell, (the need for) documentation is a usability smell. Warning signs include post-its stuck to the screen, looking things up in the manual.

Paper prototyping is a powerful tool for evaluating usability. Test them with actual users!

My opinion: A good intro for those who have never given usability much thought. Luckily we’ve come a bit further than this with our application.

This is my summary of Brian Marick’s “Seven Years Later: What the Agile Manifesto Left Out”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

The Agile Manifesto has an outward focus: it tells the business how the development team will work with it. What it does not talk about is how the team must work within itself and with the code.

What should the team keep in mind?

• Joy
• Naivete: ignore the people and books who say that it’s impossible
• Ease: tools should work as if they are a natural extension of your hand. Pay attention to what it feels like to work. Spend time fixing the annoyances.
• Reactive: ignore the future. Don’t back up – change your course forward instead. This forces you to make your code easy to change.

Being wrong: is an opportunity to learn.

My opinion: Nice words and nice thoughts, but what do I actually do with them? Less inspiring than Brian’s first talk at ScanDevConf; rather vague and fluffy.

This is my summary of Thomas Lundström’s “BDD approaches for web development”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

Development should start with user stories.
Then break these down into acceptance criteria:

• Given «situation»
• when I «do this»
• then «this happens»

This should be done before the sprint planning meeting. Know what you commit to!

The rest of the session was a demonstration/walkthrough of automated BDD.

My opinion: The non-automated part of the session was a somewhat useful recap of BDD. The automated example involved, as usual, an extremely simple application and extremely simple user stories. While I understand that it will work in that case, I have great difficulty envisaging how we could possibly use it in our system.

This is my summary of Diana Larsen’s “Creating a Climate for Project and Team Success”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

What is a team? A group of people with…

1. a common purpose, undertood and committed
2. interdependent work and skills
3. a shared approach to this work
4. joint accountability
5. small size
6. a mutual history (at day one, you are not yet a team)

How do you achieve these? What do these imply?

1. A project kickoff, project charter; reminders and mini-re-kickoffs
2. Think about what skills are needed before you select people for your team
3. Have a working agreement – “we aspire to work this way”. Make implicit norms explicit.
5. If the team is too large, it will break into sub-teams.
6. Common adversities and successes; stories to tell about the team; knowing each other.

My opinion: Basic stuff. I guess there are groups out there that need these tips but they were not of much use to me.

This is my summary of Henrik Kniberg’s “Kanban and Scrum – making the most of both”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

A supershort summary of Scrum:

• Split your team into small parts
• Split your product into small parts
• Split your time into small parts

… i.e. instead of a large team working on a large product for a long time, you have small teams working on small pieces of the product for short periods of time.

Kanban is:

• a signalling system
• with visible indicators
• that are limited in number.

Kanban in software development includes:

• visualizing the workflow (with columns on a whiteboard)
• visualizing the stuff in workflow
• limiting work in progress (WIP)
• measuring and optimizing flow
• explicitly defining your policies – the definition of done, WIP limits etc

How do the two differ?

• Scrum has more rules than kanban. On a scale from prescriptive to adaptive, the order would be
  RUP > XP > Scrum > Kanban > do whatever works.
• Scrum defines roles while Kanban doesn’t. In practice they might look the same.
• Both are empirical and measure things (velocity, lead time, quality etc). Kanban gives you more knobs to twiddle to change the outcome.
• Scrum has one cycle: planning and committing, releasing, and retrospectives, all three are done on the same cycle. Kanban does not tie these together; you could have a different cycle for each one.
• In Scrum, items must fit within a sprint. Kanban allows long-running tasks, limited only by WIP limits.
• Both limit WIP. Scrum limits by velocity, per time; Kanban limits by column in the workflow.
• Scrum discourages mid-sprint change: “We want to work in peace and quiet for a few weeks”. In Kanban, you just need to wait for a slot to become available.
• In Scrum, the board is reset between sprints. In Kanban the board has a long life. Scrum gives you closure and a feeling of success, but also some waste.
• Scrum prescribes one team per board, cross-functional. Kanban is more permissive of specialist teams.
• Scrum prescribes estimation and calculating velocity. In Kanban both are optional.

For more information, read the free PDF minibook.

My opinion: Well-structured and informative. I’d been curious about Kanban, wondering if it might be worth trying instead of Scrum (which we use now). After this presentation I have a good grip on the differences between the two and know that Scrum suits our needs better.

This is my summary of Diana Larsen’s “How Can You Manage New Organizations in an Old Way?”, which was the keynote speech for day 2 ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

The short answer is, You can’t.

Before discussing the differences between the old and the new, it’s useful to remember that the “old” way of work, command and control, has only existed for the past 80-100 years.

Now the old kind of work is being replaced by knowledge work, where the workers know more about their job than their manager does. The old kind of management no longer works.

Old management activities are: planning, organizing, budgeting, monitoring, directing, supervising, evaluating, controlling, commanding.

New management: managers focus on flow, people and value, and continuous improvement. Their job is to enable and facilitate.

New management activities include mentoring, mediating, protecting, advocating, acquiring and allocating resources, tracking and reporting metrics, supplying a good work climate, supporting learning, improving systems.

The people working are affected by the system they work in, and that is the reponsibility of management. Behaviour is a function of person and environment.

My opinion: This all seemed pretty self-evident to me.

This is my summary of Niclas Nilsson and Hans Brattberg’s “The Pair Programming Show”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

This session was a live play showing pair programming in action – done right, and done wrong.

My opinion: Fun and relatively well done, but pretty basic stuff. The only thing it gave me was a reminder of the different roles that the two people in a pair should have. One to focus on the small, immediate stuff; the other to focus on the bigger picture – Are we doing the right thing? Are we doing it right? Could we do something else?

This is my summary of Udi Dahan’s “Intentions and Interfaces”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

A core design pattern: intentional interfaces. Whenever you find yourself facing a design problem, tell yourself – “Make roles explicit”.

For example, a Customer class may be used to validate a customer before persisting it, for making customers preferred, and for adding orders to the customer. Making these roles explicit, the Customer class would implement IValidator, IMakeCustomersPreferred, and IAddOrders. Now that these are in place, we may use them, for example, to implement different fetching strategies for #2 and #3 – lazy vs eager.

Another example: there might be a CustomerService class for those same three tasks. Separating out the three responsibilities, the class might implement IMessageHandler, IMessageHandler and IMessageHandler. Now that this is explicit, we may split this into three different classes, which would (among other things) allow us to have several handlers for a single message, in a pipeline.

As a rule of thumb, define your interfaces starting from use cases. These tend to be a stable foundation to build on.

Often we think one interface – many implementations. With this pattern it’s the opposite: one implementation, many interfaces.

My opinion: This session is difficult to summarize without all the examples and step-by-step reasoning, so I’m afraid the blog post won’t do it justice. I found it useful, and the reminder to Make Rules Explicit will probably lead to better design with less sprawling classes in our code.

This is my summary of Chris Hedgate’s “Effective Retrospectives”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

Note: In Agile development, a retrospective is a meeting at the end of an iteration (which a period of work, usually 2 to 4 weeks) where the team reviews the iteration together, and discusses possible improvements to their process.

A bad retrospective is: ad hoc, not prepared, with no structure.

The goals of a retrospective are two:

• participation
• decide on actions, what should we change (this is what new scrum masters often focus on)

Keys:

• Facilitation = planning, leading, setting a goal. Gives us flow.
• Framing = setting up and ending, making it focused
• Structure = ensures balance, gets everyone’s input

Facilitation

• Use an external facilitator. The person leading the meeting should not have an interest in its outcome. It is difficult to lead and participate at the same time. If not possible: be very clear about when you’re leading and when you’re participating.
• Work with the energy and the dynamics of the group. Take breaks; split into smaller groups when appropriate.
• Prepare. Think about what activities to use; when and where to have the meeting; is food needed, etc.

Framing

• Modify the retrospective according to its purpose
• Define the goal and agenda
• Not every retrospective needs to be about “how can we get better”
• Try retrospectives with specific themes: QA, communication, etc – gets you away from boredom and routine
• Start with a check-in: everyone says/draws something about the iteration
• Make it safe to participate

Structure
A retrospective should have three phases:

1. What happened? Why are we here? – In this phase we share context
2. Why did that happen? – In this phase we diverge, by brainstorming
3. what should we do? – In this phase we converge again, and decide on actions

Sharing context can include:

• Looking at raw data: burndown chart, story list, bug count chart
• Creating a timeline: write post-its with things that happened and stick them on the timeline (all at the same time or with individual preparation)
• An emotional timeline (a line chart scaled simply from – via 0 to +, and everyone draws their own line between these extremes)

During brainstorming, people write ideas and thoughts on post-its.

During the convergence phase, you can cluster the post-its, vote on them, discuss them in smaller groups, etc. At the end, the team commits to actions that are

• possible
• valuable/important
• someone who wants to do it

Finally, summarize: what have we learned, what are we taking with us.

My opinion: This was exactly what I needed. Chris’s comment about how inexperienced scrum masters always focus on “what should we change” really hit home. And our retrospectives have become relatively boring. This session gave me lots of useful, practical tips. I believe our next retrospective will be much better than the last one.

This is my summary of Bill Wake’s “To Make a Long Story Short – Splitting User Stories”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

Why split user stories? A story may be too big to manage. Or different parts of it may have different value. Or some parts may be better understood than others. We’re looking for bargains: best value for least cost.

There are 4 categories of splits:

• high-level splits that get rid of lots of work
• “ilities” – non-functional splits
• UX splits – simplify the user experience
• behavioral splits – simplify behaviour

Technical splits are not recommended. Stories still need to make sense and be valuable to users.

High level splits include: research; partly manual process (instead of full automation); buying instead of building; deferring features.

“ilities” splits include: static data instead of dynamic (a “refresh” button instead of constant automatic refreshes); simplified persistence; lower fidelity; lower reliability; lower performance.

User experience simplifications include: batch processing instead of immediate response (generate reports off-line overnight); single user (instead of multi-user); API only (UI can wait); simplified UI style; a generic UI (textboxes in a grid instead of nicely aligned dropdown boxes etc).

Behavioural splits include: happy path first (ignore alternative flows and exception cases); fewer choices (0 or 1 instead of many, e.g. fonts in a text editor); base case first (wait with a more general solution); collect less data.

My opinion: Pretty basic stuff rather dully delivered. I could have just taken the one-page handout and not missed much.