I saw Maaret's Pyhäjärvi's post on LinkedIn the other day. This line chimed strongly with me:
Sense of lack of time. Someone asked how to have joy of discovery when feeling always pinched with time. We have in many cases lost control over time, and I have done work I have not necessarily appreciated on making time flexible - always seeing there is a next day and having no schedules and small slices of work.I feel like I do my work at various granularities across multiple dimensions and so, to begin to get this idea straight in my head, I tried to list some of them.
It was harder than I thought it would be because so much of this is instinctive, intuitive, and in the moment. Given that, here goes draft 0.1. Hopefully I'll begin to feel more familiar with the idea and be able to revise the model later on.
Scope
Parcel of work. My team's practices are reasonably common, I think. Tasks are portioned into into Jira tickets which progress out of a backlog through various states of refinement, into states of being worked on, and then into the state of being done. Perhaps less common is that there is no explicit state of being tested.
My testing, and other work, can happen anywhere from sub-ticket, through
the ticket itself, across multiple tickets, or outside of any ticket.
Additionally, I don't test the work in every ticket.
Learning. Some tasks offer the chance to grow my knowledge and sometimes the constraints mean that learning is not a priority. Given free choice, though, I
like to sit at the upper end of the learning scale, picking up what I can whenever I can. This
means that I'll try new ways to accomplish understood tasks and take on tasks
that I don't know how to do, just for the learning opportunity.
Breadth and depth. The direction I take an investigation varies greatly. I might see that some big new
project is coming up and dedicate a few hours to understanding the domain it
sits in before there is even a ticket. I think of this as a broad,
landscaping, task. I want to know the big pieces, how they relate to one
another, the shapes of existing solutions, the terminology that's typically
used, and so on.
Deep work could be done while trying to track
down, for example, an intermittent customer issue in production. There are
typically many variables to consider and they might interact so I'll be
looking at multiple techniques and repeated experiments to get an idea of
what's going on.
In contrast, sometimes a code review will be sufficient
shallow and narrow testing.
Tech stack. The main service my
team works on consumes components made by other teams and is a dependency for
components owned by other teams. I look for ways to test at all of the levels
in that stack. When we make changes in our service, I might test only against
it, up the stack, down the stack, or end-to-end with observation
wherever I think it's interesting and possible.
People
Collaborators. I don't do all of this work by myself. I do work alone, but I also spend profitable and enjoyable time
pairing with others, in small groups, in my team and cross-team.
Impact. Where will the outcome of this work be experienced? It is just for me, a
colleague, my team, the group my team sits in, somewhere else in the company?
I can think about the work I am doing and see where else I think it makes
sense to share.
At Ada we have Community Days every couple of weeks and they are a convenient way to share by broadcasting although the location of the impact is hard to predict that way. I use my personal Confluence page to keep a list of internal presentations I've done so they can have the same kind of impact at other timescales.
I think about the work I've done and try to find people or teams that I can
make contact with to share it. I talk about my work to colleagues, looking for
people they recommend might like to hear about it. This isn't egotistical.
It's about finding like-minded people who care to do good work in the same
space as me.
Relationship building. I build
relationships with others. I ask for help from others. I make myself available
to help others. Actually, I actively look for ways in which I can help
others. I keep an eye open for things that others do that could be helpful to me. I share
results that I have found with people I think will be interested. Different
activities give the opportunity to develop relationships to different extents,
from simply making first contact, through adding a new layer, to making a
radical change.
I joined the coffee chat rota in my first week at
work and am now, 18 months later, starting to meet people for the second time. Some of
them I have not spoken to since the first virtual cuppa, but others have been
valuable contacts when I've needed something or vice versa.
You
might say that a coffee chat is not work, and you'd probably be right.
However, it is a small relationship investment, a small time investment, a
low-risk investment with a potential longer-term payoff.
Time
Stake. What kind of gamble am I prepared to take on this piece of work?
The stakes can be effort, annoyance or inconvenience to others, cashing in
credit earned, IOUs, time spent, opportunity cost, delay, and so
on. I wonder how I can reduce the stakes and with what kind of trade-offs.
Level of effort. I can spend from no time, to a few minutes, hours, days, or even weeks
testing a thing. Depending on how you care to group activities, I have had
single investigations that have lasted months.
To payoff. I start tasks that I expect will pay off now, this sprint, in the medium or
long term, or that are only spikes or proofs-of-concept that I understand
might not pay off at all. All actions are gambles and I tend to take smaller,
more incremental steps (reduced scope, less time, lower risk) to reduce my
risk when the potential reward is less well understood.
A task
that pays off now might be some basic checking of a small fix that went
through today, where I already understand the issues. At the other end of the
spectrum, I've been working for over a year on weekly ensemble testing with a
group of medical doctors in my company. There's no set agenda for this, we
bring a topic to the Friday afternoon sessions and then work on it together.
I am sharing my knowledge, approaches, insights, tooling, connections and so
on. How, when, and where this will bring benefit is very hard to judge. The
participants all find value in it, so we keep going.
vs Ticket status. I can test while a ticket is in the backlog, in development, in review, and
in production. Where a ticket is in its life-cycle is not the only factor in
whether I am looking at the area.
Reflections
- When I start, I don't always know what granularity I will work at.
- The work evolves in these dimensions (and probably others) as I learn about it.
- When I externalise the idea of relationship-building I feel like it might be perceived of as manipulative. Perhaps I can find a better way to describe it.
- I am not very granular when it comes to visibility. I will pretty much always talk about what I'm trying and, because I'm an inveterate note keeper, there will be notes in public.
- I typically track my work as threads. Any given investigation may be more than one thread.
- Some work impacts on people and process more than product. I'm not sure the model reflects that.
-
How do I get to work this way when others feel the tyranny of tickets? I
believe I have built the trust of the teams I work in.
Comments
Post a Comment