Monday, 18 November 2019

Agile Time

Photo by Sonja Langford on Unsplash
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

Photo by Todd Quackenbush on Unsplash
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?

Photo by Michael Browning on Unsplash

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
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
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!