Remote Scrum Masters
I want some examples of things that can fail in AgileBI
So that I know what to watch out for
One of the hardest things to do in Agile is to deliver using remote teams. When your Scrum Master is remote, it is almost impossible.
In the beginning, an agile team has to form and storm. If the agile team have never worked together before or even worse not been in an agile team that is doing or being agile, then it will take time to for them to create a self-organising team and to define, agree and adopt their agile way of working.
This is a critical time. It is the most important time for the Scrum Master to be present.
The Scrum Master is critical in advising the team on how to experiment. They are also critical in helping via retrospectives and constant feedback on how to identify and focus on the next areas that will be improved. Without this assistance, the team will often go around and around in ad-hoc circles trying a hundred and one different approaches, but never proving if that approach is making things go faster or slower.
One of the many AgileBI challenges is that a Scrum Master is often only a part-time member of the team. When an agile team is mature and self organising then the Scrum Master is only really needed part time to run the agile ceremonies and provide feedback. Typically I will see a Scrum Master being engaged for 50% of each week to undertake this role.
When the team is new, this should be 100% for the first 3 to 6 sprints (9 to 18 weeks) which is the average amount of time it takes an agile team to form. Often I see the Scrum Master engaged 50% at this time. If the Scrum Master and the agile team are experienced, then this can often work, but it isn’t ideal.
However, if the Scrum Master is remote it is almost impossible for them to be around at just the right time in those 9 to 18 weeks to help steer the agile team in the right direction. And by steer, I mean helping them identify areas of improvement they should concentrate on themselves, rather than telling them exactly what and how to do things.
In my experience, if you have a co-located team, you need a co-located Scrum Master.
One thing to watch out for is when you have a part-time Scrum Master who is also trying to manage another Scrum Team, often for another customer (in the cases where you have a contracted Scrum Master rather than a permanent one). This will often result in the Scrum Master not being on-site to work with the agile team at critical points.
They might use slack to try and keep up to date with what is happening, dial in or video conference into the ceremonies, or they might “pop in” for just the ceremonies and then disappear. They might even do a few regular days each week and miss some other days on a regular basis.
But without being on the ground, they are going to lose the subtleties that come with personal interaction. A good Scrum Master is a guru in picking up on these subtleties and help the agile team increase their maturity based on these observations. When the Scrum Master is not around the Agile team will typically just flounder.
Even worse is when the Scrum Master is more of a dictator than a servant leader. In this scenario, the Scrum Master will tell the team what actions to take next without really understanding what has happened in the last Sprint, what worked and what didn’t. Its one of the worse form of guessing.
So if your Scrum Master isn’t there when the agile team is, I suggest you get them to turn up or get a new Scrum Master.
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...