anthony galvin
TAGGED: AGILE
It's taken me a while to come to this realisation, but I've spent a huge chunk of my life trying to achieve things with teams. Sports teams, software teams, bands, orchestras, actors and product teams. To be fair not all of these notional teams have been successful - but when they work well, teams are awesome.
It's a cliche to say that "being a team player" is important at work. Most of the time this is just a platitude for people who don't rock the boat. A way of saying that the person in question is no trouble. I don't always buy into this team of mates dynamic.
To continue the cricketing viewpoint, Mike Brierley, arguably the greatest exponent of captaincy and understanding the psychology of teams sums it up nicely "If individualists are too powerful, too divisive and too selfish, the team suffers. If they run riot, the notion of team scarcely exists. At the other extreme, some teams can become flat, conformist and dull. Far from running riot, individuality is suppressed."
So there's plenty of scope for the right kind of discussion and a team that's able to sometimes hold divergent points of view, at least for short periods of time.
It's not always easy to identify the right group dynamic from the inside, never mind on the outside. In my experience it's one of the reasons why agencies often struggle with consistently casting high performance teams. Even if resourcing is operating beyond the principle of "availability as a skillset", the people making the decisions when pulling together new project teams are on the outside, and from there the signals of a genuinely good team are almost impossible to detect. In an agency it can sometimes feels like the approach is "We've got this project team performing really well. Now we've delivered everything we should break the team up and make sure this group of individuals never work together again".
I've written recently about some of the challenges in scaling teams across multiple locations, but as well as geography having a significant impact, more people also comes with a time cost.
More people doesn't have to mean your people. As the number of integrations, partners and vendors increase the time cost of managing, motivating and co-ordinating all these different folks can have a significant impact. A small team that has many thrd-party integrations doesn't just have a scope challenge, it also has team management challenge as well.
Perhaps this is the ultimate team challenge - when the team in question isn't just your team, but other teams as well.
25/02/2019 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.
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…
2013-09-30 11:39:00 GMT permalink
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.
10/11/2018 permalink