anthony galvin


It often starts with a sigh. Away from work you hear the obvious sound of frustration when an app or service doesn’t work as expected or crashes at a critical moment. As more and more of our lives are mediated through different glass rectangles, the expectations and importance of delivering brilliant, scalable and reliable experiences on those devices grows.

Which means in practice that the numbers of people involved in creating and engineering the apps and services that people rely on are inevitably large. One of the challenges for people like myself responsible for delivering the software to make all this happen is that with so many people involved how do you create an environment that delivers high quality software and services.

It’s a bit of a management speak truism that everyone on a project is “on the same team”, but in practice that’s not really possible. For some of the global projects I’m working on at Huge, there’s often over 100 folks involved, with a large percentage of these made up of engineers in variety of locations. We have a common objective but in practice we are many teams.

Where location does play a factor is often around balancing time zone coverage so that there’s enough people in each location to ensure effective collaboration. There’s no point adding a single developer with almost no time overlap with anyone else on the project.

However, in practice the amount of overlap doesn’t always have the positive effect people might think. Complex engineering problems require deep focus and an environment that reduces interruption in addition to cross discipline collaboration. The reality of a distributed team is that at some point of the day there are times when there’s fewer people online. Which correlates with fewer interruptions.

Would I choose to have the engineering teams scattered across the planet if it was possible to have everyone in one building. Probably not, but the reality of the work is that this isn’t really possibly, and in practice it’s not the most important piece of the puzzle.

#work #teams #agile #remote #software

10/11/2018 permalink

Tools are recursive. 

Increasingly the conversations I’m having in the office are about tools - digital tools, scalable tools, technology as a tool. But these conversations quickly get meta. There are as many definitions of a digital tool as there are tools themselves. And many of these tools are really incremental pieces of technology, built on a whole heap of other tools and platforms.

As an example, some people in the office have been using Slack, a collaboration and communication tool that’s been getting some press (and dollars) recently. Slack uses, amongst other things, some Amazon AWS tools. Which are tools that we also use to build tools for our clients. And you can create and integrate other tools with Slack, allowing you to create tools to extend a tool that you use to help a team create tools. 

Confused? You probably shouldn’t be. The fact that there are few new ideas and that we are building on the ideas / frameworks / shoulders of others is surely standard operating procedure in the current point of our post-sampler creative and cultural continuum.

But what’s important is not the just the originality of the 1% being added to the collective digital noise, but the story that you tell. The how, what and why matter as much as the code you write. Perhaps story points shouldn’t just be in the backlog

#work #tools #agile #words #story

2014-12-11 21:53:57 GMT permalink

What we talk about when we talk about planning poker

How sizing stories (points, t-shirt sizes, days & hours) is more than just Numberwang.

For (digital) agencies who use agile techniques for managing the design and development process there are some added complexities hidden in the abstractions of the story sizing.

Depending on the nature of the development project, a typical agency team might run the gamut of disciplines, from Interaction & Visual Designers, working in Illustrator and Photoshop through to Python engineers coding in Vim and living in the command line. And each with a (subtly) different understanding of the complexities involved.

Planning poker is the technique of getting multiple people on the team to independently size user stories, whilst trying to avoid the risks of ‘anchoring’. It’s a great method for driving cross discipline understanding of those tiny assumptions that can threaten to derail a project further down the line.

Which looks something like this:  Sat in a circle, post-it notes scattered across the floor and walls, someone is describing a level understanding of a particular user story — it’s pretty simple on the surface “As a user I can sign-in to the platform, so I can register to use the service”. People scribble on the post it notes, using the Fibonacci sequence to size stories based on the relative complexity involved for the UX (interaction and visual design) and technology teams. After a few seconds everyone stops writing and holds up their post-it notes. It’s near the start of the meeting so people are still getting a little warmed up, even so the variance in the numbers is quite high. Not just between disciplines but also between team members who work in the same area. This is where the interesting bit starts.

The discussion that follows is the bit I find fascinating. The cases where someone in tech misunderstands the complexity of a design challenge or someone missing the difficulty of integrating with a third-party (“it’s just an API call”) is understandable — that’s why we are doing this as a cross disciplinary group. These are easy to flush out and correct.

The real area of interest is where people explain the assumptions behind the scores they’ve given. At this point we are into the details, and it’s great for the momentum of the project. Weeks of thinking, sketching and notes come tumbling out in the conversation — no amount of ‘annotated wires’ can accomplish the benefit of someone challenging why “that’s only a 3".

Capturing these assumptions is key — they make up the real scope and difficulty of a story. Often it’s also the risk factor that you’re gathering “I gave it a 21 because we just don’t know exactly how that’s going to work”. Whilst all forms of planning and project management are probably inherently flawed, you’re unlikely to get this level of collaboration and discussion whilst scoping out a typical waterfall build.

Agencies running agile are usually working with more constraints than a development shop. The client will probably have a fixed budget and timeline, so the only area of flexibility is scope. Whilst the aims of the project are (hopefully) going to be clearly documented and contractually agreed, these small instances of scope and the relationship between a ‘must’ and ‘could’ are the area of flex that teams are going to need deal with the reality of ‘unpacking a story’ and finding it’s more of a nightmare than a fairy tale. But that’s probably something to add to the backlog for another post…

#work #agile #planning #process

2013-09-30 11:39:00 GMT permalink