The Agile Team member should know what they are working on and why
As a AgileBI Coach
I want I want to understand how to determine if the AgileBI Team are in a healthy state
So that I can keep the sprint team engaged
Feel the Buzz
One of the things I love about working with a team who are delivering using an AgileBI approach 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 AgileBI approach is definitely a team sport.
Ask the questions
One of the litmus tests I often use is to ask an AgileBI 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 AgileBI 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 AgileBI 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 sit through the retrospective and see how that feels.
Other Blogs from this category
The Issue: As a Stakeholder or Product Owner I want to understand if constantly adding Agile Team members is a good idea so that I can have a valid conversation with my Product Owner and Scrum Master. My Answer: Adding members makes you slower. Initially, at least....
As a Stakeholder or Product Owner I want I want to understand who can attend a standup So that I can ensure we are following an Agile approach Standups One of the many key things in deliverying in an AgileBI way is the use of daily standups to...
There are a number of myths abound about the Agile approach. These include that idea that having a daily 15 minute standup is being Agile, to Agile doesn't deliver documentation. When I hear these myths I typically reply with "Agile is not Adhoc". So let's list the...
There is a myth that Agile is all about being adhoc and that there is no planning upfront involved. It's not true. In fact when undertaking a AgileBI approach the team will spend far more time in planning sessions than in a typical waterfall project. What is different...