I have implemented the daily sprint before in teams that are struggling with the fundamentals of working in sprints, mainly, self –organisation and collaboration.
The daily sprint is a concept I have adapted from XP concepts of being able to release shippable code rapidly.
Even though there is a sprint (in our case, a two week sprint), with an overall sprint goal, the team aim to commit to delivering some value on a daily basis. I can imagine some may be suspicious of this approach already, believing it to be a form of micro-management of the team by the Business. There is certainly a risk of this if not implemented correctly, and I shall address this later in the blog. In the meantime, I’ll explain what made me adopt this short-term approach to a team.
The background is that the team had undergone a lot of change through new starters and working on a new project. A few members of an established, high performing team of four developers and a tester was left with just the tester and one original developer. The new developers were a mix of junior and more experienced developers taking the developer count to five in total. Obviously if we could have avoided messing with the teams we would, but people leave, things change. We have to adapt.
So, the changes in a nutshell were:
- Established team disbanded due to leavers and one of the team being promoted to management and working on other things
- New team members unfamiliar with systems and the culture of the company
- A new mix of abilities throughout the team
- Some strong personalities in within the new starters
- New starters new to Agile and Scrum process (full training and mentoring was provided)
The Business is generally tolerant of the impact change has on performance, but the above culmination basically led to a poor performing team that didn’t look to be resolving issues itself, even with the help of Retrospectives and mentoring.
After a few sprints with goals missed, the retrospectives revealed to me that the issues lay consistently within the clashes in personalities, individual developments taking ownership of stories instead of allowing transparency within tasks and inadequate communication in general. For me, a couple of sprints were enough in order to confidently take action towards resolving the issues. Hence, the daily sprint was introduced.
Now, this option was always intended to be short term. In my opinion a daily sprint is a means of exposing issues with a team by magnifying problems such as dynamics or lack of knowledge (whether this is process or technical). The same rules apply to a daily sprint as a longer sprint. The Definition of Done must be adhered to, blockers and threats to the daily sprint goal must be raised with the ScrumMaster and or Product Owner. The idea is that if you run a daily sprint goal with teams they will be forced into an intensive mini-sprint, where at the end of the day, the goal is achieved.
The development team alone decide the goals at the daily stand up. For my team, the goals were oriented around which SBI’s would end up where by the end of the day, but can include anything. The key is that whatever the team commit to is fulfilled on a daily basis.
Into Dev Rev
As a team, they need to all agree on this commitment, and make it happen. If the sprint goal is threatened, they need to inform the ScrumMasrter and/or PO. They need to remove blockers quickly, they need to collaborate, they need to keep each other informed of progress…. But, you MUST let the TEAM decide what they can deliver. If you don’t allow the team to decide, then you’re in trouble. The team still needs to be empowered to make decisions in this situation. It’s not a way for management to impose and dictate deliverables onto the team as punishment for not meeting sprint goals in the past.. They still need to take ownership of their commitments as a team, and they need to remain motivated to do this.
What I found is that, although the team at first were skeptical, they very quickly adapted and started to work better together. The problematic dynamics were eased as they were practically forced to get along, they were asking me for help more in terms of the process and removing impediments, but most importantly, their productivity increased and they started delivering. This was a real win because this in turn motivated them, encouraging them to continue with their efforts. As ScrumMaster I observed the team closely and praised them when I saw improvements and was energetic and excited about increased productivity. Its amazing how much of a difference it makes when someone is genuinely rooting for a team to succeed as opposed to rolling their eyes at the stand ups if they are failing.
This approach continued until the product was released several weeks later. The team then went back to regular sprints with no daily sprint goal with a better appreciation of collaboration, self-organisation and communication, but also, commitment.