Feel the Buzz
One of the things I love about working with a team who are delivering using an Agile Data way of working is the buzz that happens when they are doing it well.
There is the buzz as you sit at a Prove It session and see the awesome things they have created, or the hard problems they have solved, all in a 3 week period.
There is also the buzz as I sit amongst the team and they are constantly moving next to each other to talk through a concept, work together to solve a problem, or working with a peer to code or review what they have built so far. This constant movement and conversations as they collaborate cause a natural buzz of noise in the areas we are working.
When you don’t see or feel the buzz then it probably means there is an issue sitting under the covers you need to explore.
Don’t get me wrong, a developer sitting with their headphones on as they work on code is ok, but if that is all that is happening for days or weeks on end, then you should be worried as it indicates people are working in isolation. An Agile Data way of working is definitely a team sport.
Ask the questions
One of the litmus tests I often use is to ask a team member what they are working on.
People typically love to talk about what they are doing. So you should get a good sense of what the developer is currently doing and ideally why they are doing it.
You should also get a sense of the developer being excited by the work as well. Even if they are troubleshooting a problem, a good developer in a healthy agile team will typically be excited by solving the current problem. (Yes you need to factor in the different personality styles of the individuals to work out what “excited” should look like).
When to worry
If I hear some of these replies consistently then I start to worry.
- I don’t know what I should be working on;
- I’m working on xxxxx but it is a waste of time;
- I’m waiting for xxxxx to finish their bit until I can do something and I have been waiting for a week;
- We are working on xxxxx yet again and just waiting to be told to stop working on it yet again;
- The rest of the team are off working on xxxxx and i’m building something I have always wanted to build;
- I’m just waiting for the days of “meetings” to start again;
- I’m finishing off the testing of the “thing” we finished last sprint.
Don’t get me wrong, everybody has a bad day, every Agile Data team has a bad delivery iteration. But if you have these types of comments made consistently, then you need to dig deeper to see if there is a bigger problem.
My suggestion would be to get permission to sit through the retrospective and see how that feels.