Agile Time

Another big item on your shopping list for a successful Agile development is a little less tangible, but the work will fail without it.

Working hours

Decide up front during what hours people will be available. Most of us don't work in a Draconian factory where everyone clocks in at 9:00 and out at 5:30, but we do need to communicate effectively and to do that we need to know when people are available. Agree product-wide core hours and stick to them. Commonly, I'd use 10-12 and 2-4, but that might vary for situations where part of the team works in other time zones.

Stakeholder availability

If you can, be Agile, don't just "do" Agile. That means that all parties involved in the work need to be trained and operate in an Agile manner. However, regardless of what the books say, people in some roles (at least stakeholders and, often, even product owners) cannot be dedicated to the project full time. If that's the case, agree scheduled time slots when they can be dedicated and make sure they stick to them. Assuming there's no travel involved (see "video conferencing", earlier) hold the regular meetings even if there isn't much to say. Everyone likes having unexpected free time in their calendars. If a regular meeting is skipped once it can be clawed back; twice and no one turns up to the third one.

It's a sensible thing to do for each stakeholder to designate a deputy. There will be times when even the most dedicated individual can't make it (due to holidays, illness, etc). Having a deputy means the work can still go ahead, but remind the stakeholder that they need to keep their deputy informed.

Sprint cadence

I'm used to running large scale Agile developments with many teams, but even if you have only a few teams you'll benefit from sticking to a common sprint duration across all teams. Stakeholder time may be rare, so make the most of it by ensuring that sprint demos and other common meetings happen once for the product, not once per team. Common cadence makes these events easy to plan for and significant to miss. Knowing when a feature delivery that spans several team will be ready and having all teams' work entering integration testing at the same time is a great way to reduce stress and rework.

Essential gear for Agile development

I'm all about doing things on the cheap; quickly and efficiently. There are many complex and online tools and services out there that provide great (and expensive) platforms for collaboration. Sometimes, things can be simpler and just as effective.

In order to communicate effectively, you're going to need the proper kit, but what does that mean? This post hopes to point you in the right direction. What tools you'll need and how you might use them to better advantage, all based on real-world experience. It might make you smile too.

Jira

Yes, there are alternatives, but Atlassian's workhorse has become the industry standard for large scale development. Sorry, Rally, but you really never made it. Jira's (fairly) predictable nature means that there's probably a way to do it (for any definition of "it") either already as part of the tool or as a plug in. Learn the features; thank me later. Cloud licencing is more expensive, but less of a headache than the local version.

Chat

Sure, you can use email but that's so last decade. Share your thoughts in a public workspace and never have to remember that attachment again! Public chat tools can be a little scary at first, as your views are suddenly known to everyone with the right permissions, so keep it professional and make sure you use a tool that allows secure 1:1 chats as well as group think. Teams isn't bad; Slack is better.

Videoconferencing

A Microsoft study from 2010 found that there are orders of magnitude difference of effective communication in paper vs email vs chat vs audio conference vs video conference, so get in front of that camera and shine! Sure, audio conferences are more hangover-friendly, but you can't see the expression of the person speaking (or those behind them) without video, so you lose a lot of information about things such as whether they mean what they're saying, whether they're really interested or whether the expensive "get everyone in a room" meeting is really cost effective. Skype works; Teams works; Zoom is better.

Audio conferencing

"But how am I supposed to video conference and screen-share with our bandwidth?!" I hear you cry. Pay for more bandwidth, but in the meantime get on a call. Tools such as Teams are good for talking over a shared app or desktop. Enjoy your conference call bingo session as you're not sure whether the other side can hear you or not though. Did I mention video conferencing? You can see if they're having trouble or not, immediately. Just sayin'

Screen sharing and collaborative editing

Effective remote / global working relies on common understanding of content. Using collaboration tools that let you see and edit that content as a group from a number of locations simultaneously is marvellous (until that idiot in the other office edits your document using spaces instead of tabs again - hate that guy!). Don't be afraid to hand over ownership of a document to allow a reviewer to show you exactly which part they'd like to change. A stream of "this bit?" "no, before that" "this bit then?" "no after that" is always fun, but document-battleships wears thin after a while.

Meeting rooms

Why does no one ever design a building with enough meeting rooms? Is there some secret cabal of office space renting companies controlling our working lives? Conducting meetings in an open plan office is always sub-optimal. Get a room, people!

Put stuff on the wall. More importantly, take stuff off the wall once you're done. Decorating is not your strength. Use vertical space elaborately during meetings, then photograph it and take it off the wall. Save the photos centrally so that everyone can access them. If you don't have the luxury of long-term meeting room use, stick sheets of cheap plain recyclable wallpaper up first then stick stuff to / write on the paper. If you need to change rooms, simply remove the wallpaper and carry it to the next room.

White boards

If you can, use whiteboards on wheels so that they can be moved from the office space into meeting rooms and back again. I recommend one reasonably large, double-sided whiteboard per team. Label each whiteboard with the team name so that they remain with the team. In an open-plan office with limited meeting room space these are a godsend. No one is allowed to write "do not remove" or "please leave" on any whiteboard - take a photo and spend two minutes redrawing / rewriting the content at the start of the next meeting in which you need it. You'll find that having to lay the content out again actually helps your thought process.

Wall space

If you have walls or windows, use them. Let each team set an archive policy before anything goes up though. Wall space fills up fast and "just in case we need it again" does not pay for the lack of creative opportunity. One tip: don't put company-sensitive stuff up on an external window.

Pens

In this digital age, always make sure that you have something to write with.

Whiteboard pens are like socks - blink and they're gone. The one that's left is the one with the damaged nib or that has run dry. Throw it out if you can't use it and save yourself the disappointment later.

Larger nibs make the writing more visible from a distance (like, say the other side of the room), so don't be afraid to use felt tips.

Post-Its

Post-Its (real ones, not the cheap variety that dry up and fall off overnight) are essentials of modern business life if for no other reason than to edit that process modelling mistake you made yesterday.

Forgot a step in your process model? Shuffle stuff along. Want a decision box? Turn a square Post-It through 45 degrees and you get a diamond. 5cm square stickies work well to limit the content you can put on them. Use colours to mean things and you add an extra dimension to your annotation.

One extra tip: when using Post-Its, always take a photo of your wall before going home. I once returned to the office the next day to find that since some had fallen off the wall, the cleaner had neatly stacked the entire wall contents and left them on the meeting room table.

Wiki

You're going to need somewhere to store all those photos, sketches and other documents you've produced, even in "document-light" Agile. Make sure it's accessible and searchable.

If you're using Jira, consider Confluence as they link reasonably well together, but other collaboration tools you have might work just as well.

What's the right size of a cross-functional team?

In the crazy old days of waterfall development we had distinct teams of specialists: business analysts, architects, designers, developers, testers, deployment specialists and support staff.

In the world of Agile development one of the recommendations is to have cross-functional teams. This post describes what that means and what a good cross-functional scrum team composition looks like.

So what is a "cross-functional team"?

Imagine a development team that has all the people in it that can deliver a piece of functionality. A base of developers, a healthy dollop of testers, a sprinkling of UX, a soupcon of project owner and a scrum master to stir it all with. I'm going to take the food analogy way too far but it fits reasonably well, so forgive me.

Vital ingredients

To get a perfect mix you need to use the right ingredients. Hopefully these are all items you have in your cupboard already, but here's my summary of what I need from each:

• Product Owner - The restaurant owner who decides what sort of food should be on the menu and which customers will want to eat it
• Scrum Master - The restaurant manager who ensures that everything the chefs require is available when it they need it; that the menu isn't too elaborate and who makes sure that the kitchen is kept tidy
• Tech Lead - The head chef who works out how to make the food on the menu, works out the recipes that can be delivered each iteration and makes sure that the food is as expected when it's served to the customers
• UX - The one who makes sure that the food looks attractive and is easy to eat, with the correct utensils to hand
• Developers - The sous-chefs who prepare and cook the food, make sure that it tastes OK and clean the work-surfaces afterwards
• Testers - The tasters who check that the food is really OK to eat and meets health & safety regulations before the customers get to eat it
• DevOps Specialist - The mechanics who make sure that the equipment in the kitchen is adequate and works as expected for the chefs (if the chefs don't do that themselves); that the routes through to the serving area are clear and well understood and that the chefs know how to get their food through those routes

Getting the recipe right

The purpose of the team is to be able to deliver food to the restaurant (i.e. features into the production environment), but it's quite hard to work out the correct recipe. After much trial and error, this is the ideal balance I came up with per team in a scaled Agile framework:

• 1 Product Owner
• 1 Scrum Master
• 1 Tech Lead
• 1 UX
• 2-4 Developers
• 1-2 Testers
• 1 DevOps specialist

Team structure for a single scrum team project

However, that's a heavy mix of some very expensive ingredients and the kitchen is large enough for several recipes to be cooked by multiple squads at the same time, so if you like you can spread some of the ingredients over a number of dishes. I'd recommend these proportions:

• 1 product owner per 3-5 squads
• 1 scrum master per 1-3 squads
• 1 DevOps specialist per 1-3 squads
• 1 UX per 2 user interface squads (not all squads require a visual element if they are specialised)
• The remaining roles are full time and shouldn't be divided cross-squad or the squads risk losing core cohesion.

Team structure for a multiple scrum team project

The result is a team size of around 6-8 FTEs per squad once the kitchen has settled down into a regular pattern. Too small and the team can't deliver enough food to the customers; too large and they keep falling over each other in the kitchen.

Considerations for larger projects

For projects that require larger teams, I'd add a Delivery Manager above the Scrum Masters and a Product Manager above the Product Owners. You may want to add a Business Analyst or two if the project is very large or Product Owners will spend their time dealing with team requests and run out of time to write stories for future work.

Bon appetit!

How to do usability testing with only an hour's notice

Recently, while on a customer site, I participated in two usability tests carried out by a couple of experienced specialists who did not follow the same process as the more usual camera-based method. I thought it would be valuable to share that with you.

First of all, apologies for the slightly misleading title to this blog. You don't need to use this approach for impromptu usability testing alone; indeed, this is the approach always used by those particular specialists. In this case, they prepared the testing the day before it was due, but the same principles can be adopted with much less time.

Secondly, my inclination was that testing only rough wireframes would not be useful. I was wrong. Test early, to help to guide the direction of the project. Test again when the solution looks a lot closer to the finished article, even if that just means testing a prototype.

The rest of this article describes the steps you as a test moderator should follow to carry out an effective usability test. You can do all this in under an hour, but you'll have to get your skates on!

Step 1: Decide what to test

The main challenge with any usability test is to set the scope. Will you dictate the actions that you want the testers to follow, allow them to roam through the system or both?

If you are going to create a set of tasks, do that and stick to it. Make them singular user journeys. Make sure they have an obvious start, a middle and an expected end point.

Don't expect a tester to test more than five things in a single session. To expect more will make them bored and their attention spans will start to wane, skewing the test results.

Step 2: Vary the tests

Asking a tester to run the same test again but with a slightly different set of parameters (e.g. the same lookup but with a different status) will do two things, both of which are bad:

1. They will have learned about the function the first time around, which will skew the results; and
2. They will be bored, which will skew the results.

If you have to test different parameters for the same test, have them done by different testers.

Step 3: Write the tests down

Each test should have a clear objective, written in a way that any tester would find easy to understand. If it is more than two paragraphs, it is too long. Make sure that only the test (and any data the tester needs to perform the test, such as user ids or reference numbers) are written on the sheet that the tester sees. Prepare the instruction sheets to that you can give them the sheet for one test at a time, without them being able to see the details of other tests.

For each test, prepare a review sheet that asks the tester to answer a series of yes/no questions about how they found the test. This keeps the responses brief and focused and removes the kind of doubt that (for example) a 1-10 scale might introduce.

Include questions about whether the journey made sense, whether they felt that the functionality was logical and whether the activity was easy to do, but also softer subjects such as whether they would recommend the function to a friend, whether they are likely to re-use the the function or not, and so on.

Always make sure that there is an area at the end of the sheet where the tester can write their overall views of the test and offer any comments they may have. Don't forget to make sure that the form includes the name of the test they were carrying out.

Step 4: Find some test subjects

If you have time, send out general invites to the expected user groups that the application will be used by. Do not invite anyone who knows about the application build, unless your work is to enhance an existing, non-public system. In that case, only invite users of the current system. In all other cases, you can use members of the public and you're in luck - there are loads of those sat around you!

Try to make sure that the testers have different backgrounds and levels of comfort with technology, even if that means randomly grabbing people in the park!

Step 5: Sort out the logistics

Book a room for the session (if you don't plan to do a mobile test - I was serious about grabbing people in the park). Make sure you have a computer / tablet / laptop / phone / etc on which to test the application. Make sure that the application is installed on an environment that can be accessed from the device and from that particular room.

Expecting wireless access to be sufficient isn't the same as knowing that it will work. Expecting the application server to be available isn't the same as making sure it is accessible and booked for the test.

Step 6: Invite the testers

Create a schedule of testing slots and send out invitations to the potential pool of testers. Assume that 20% of people who accept the invitation will drop out but make sure that everyone understands that there is a waiting list. In other words, invite more people than you need. Once you have some respondents, allocate each a test slot and confirm it with them.

Step 7: Prep the team

There will not be a camera; having a camera in the room makes people nervous and skews the test.

Have no more than two observers (to avoid intimidating the tester) but have them in the room. Make it clear to the observers that they are there only to observe unless invited to speak. If they make any noise, pull faces during a test or otherwise do anything that might influence the tester, throw them out of the room. Really. Make these rules known and understood.

If there are two observers, have one sit facing the tester (watching the tester and, if possible, screen-sharing the screen they are using) and one to the side of and slightly behind the tester so that they can see the tester's profile and the screen. Having both behind the tester can be intimidating.

Step 8: Introduce the tests

Each tester must receive a brief introduction to the test session: what is expected of them and how the session will run. The Moderator (that's you) runs the test sessions and does all the talking.

First, tell the tester that they are not being tested; it is the application that is being tested. Any problems they encounter are problems with the system and not with the tester. They cannot hurt your feelings.

Tell them how long the set of tests will take and that the tester will be given a series of tasks (never say how many, as that will put undue pressure on the tester - if you run out of time, just do less tests).

Step 9: Run the tests

Introduce the first task. Read the test script. Ask if there are any questions or things that need further explanation. Once any questions are answered, hand the test script to the tester for reference.

Depending on what the tester is comfortable with, either ask them to talk their way through what they are doing as they go, or let them stay silent. In either case, observe closely what they do and take notes as they go. Encourage the observers to do the same. Ask the tester to tell you when they think they have finished.

Do not guide or offer advice to the tester. If they ask for advice, ask them what they think they should do next. Do not answer their questions directly. You must act as if they were alone, difficult though that is.

Step 10: Review the test

When the tester seems to have finished the test (often detectable by bodily sitting back from the screen or by them saying so), hand them the review sheet and get them to complete it.

Once they've completed the sheet, ask the tester how it went and whether they have any questions. Ask the observers if they have any questions for the tester.Record the questions and the tester's answers.

Start the next test and repeat steps 9 and 10 until the time runs out.

Thank the tester for their time and hand out any reward they earned (often something like a gift voucher for public tests). Call in the next tester.

Step 11: Collate the results

Compile the review sheet answers into a spreadsheet and bring out the most significant answers; "significant" means problems reported by more than 20% of the respondents. You will never be able to please all the people all the time. Go with only common problems, do not try to resolve every bit of feedback you get into a system change.

Step 12: Decide what to do with the results

Will each significant feedback item become a formal change request? Will you simply absorb the feedback into the build? Will you ignore the feedback? Each case has to be taken on its merits. Talk to the project manager, team leads and business representatives to decide what to do.

In summary

You can do usability testing quickly and easily, which means that you can do it often. Do it often. Learn about how people will use your application as you are developing it. They will surprise and frustrate you. Let them. Learn from it. The result will always be a better system.