It is my pleasure to lead a software development team as a Delivery Manager. My team consists of a Solution Architect, a Staff Developer, three developers, a Business System Analyst, and two QA's. We use the Scrum agile framework to work iteratively. Normally, the ONE role that you could argue is required to use Scrum is a Scrum Master. My team does not have one. I act as the Scrum Master for my team. That may be less than ideal, but I get the job done.

Scrum typically has four meetings. First, there is the sprint planning meeting. A sprint is a block of time in which the team will build, test, and deliver software features & fixes. In my experience, sprints are usually two weeks long, but it can vary by organization or team. In a sprint planning meeting, the team selects work from a prioritized backlog of work items and assigns the work to developers.

Once there are stories on the board, the typical Scrum team will have a daily stand-up to discuss progress, roadblocks, and more. I've experienced both informal and formal stand-up meetings. Informal means no official "script" to follow and no hard time limits. I've been in formal stand-up meetings where there was a specific way to do an update and a time limit to deliver it.

Once the sprint is over and the work is ready to deploy, there is a sprint review meeting with stakeholders or the people who requested the work. Ideally, functional code is demonstrated. The goal of this meeting is to get stakeholder feedback and approval so the code can be deployed to production. For my team, we build web APIs, so we use a tool like Postman to demonstrate that our APIs work as requested. I've seen sprint reviews run by Product Owners before, but on my team, each developer shares the results of their work. I like how this model gives each developer experience with presenting to business users.

After the sprint is over, there's one more Scrum meeting to hold: the retrospective meeting. In this meeting, the team discusses what went well and what didn't go well. The team can then vote on the most important topics and take action, if possible, to correct any issues.

During some of my team's retrospective meetings, some concerns were raised about how code reviews were going. One of my developers would pick up a ticket, do the work, and submit the code for review only to have it rejected for various reasons. This often meant there was no time left to fix it before the sprint ended and the ticket would roll to the next sprint. This was very frustrating to all involved. For these tickets, the architect and the developers thought they were all on the same page on how to implement the request only to find out later they were not.

I took the team's concerns seriously and considered possible solutions. The one I ended up trying with the team splitting the sprint planning meeting into two meetings. The first meeting (a now shorter meeting too!) was the typical sprint planning meeting, but we held it on the last day of the current sprint. After the tickets were assigned to developers, we would end the meeting, and prepare to deploy our deliverables for the current sprint. The developers would also add tasks and implementation details to their tickets in the next sprint. The idea was that each developer would document their intentions related to the implementation of the story. Then, on the first day of the new sprint, we had another short meeting so the entire team could review the developers' intentions and discuss them. By doing this, the developers were more confident going into the sprint that they knew what to build. I also suggested a new team norm be codified that whoever rejects a pull request needs to follow up with the developer and collaborate on getting the code fixed. For some teams, this is obvious, but I wanted to make it clear that there wouldn't be any code rejected and thrown over the wall back to the developers.

So far, the new process seems to have helped the team do a better job of getting tickets implemented the right way the first time. Our last retrospective was overwhelmingly positive. We'll continue the process for the next several sprints and see how things go. If the team continues to do well and likes these new ceremonies, I'll continue with them indefinitely.

Have you or your team taken a novel approach to getting work done? Have you had to suffer through some terrible process? I'd love to hear about it!

Cheers!