Be agile in your processes

Problem

With Scrum being the most popular agile software development methodology, sprints and estimations are assumed to be the default approach for your project. Scrum like many other agile methodologies are based on the iterative and incremental approach to development. The incremental approach works well when the problem you're solving is one that can be validated and changed. However, if there is no regular feedback cycle that allows the direction of development to be changed, following the textbook may not the right approach for your product. Even if Scrum is the right approach, there is a lot of flexibility to discover what specifically works best in your environment.

Actions taken

The first question to ask of any development effort is whether an incremental development process is the right one for the type of product you are building? If it is, the sprint duration is an important parameter to consider. If the business supports continuous delivery, then sprint length can be selected with greater flexibility. Sprint alignment across teams is highly desirable even if some teams choose a longer duration for, e.g., platform deliverables. The purpose of a sprint is to deliver product in workable increments on an ongoing basis. Does your business and your architecture support this kind of incremental change? Can you have multiple versions deployed in production in parallel? In my most recent experience the two-week sprint cycle worked well for our company and our customers. Some work that will take longer than two weeks can be delivered in four week increments while the team still stays aligned with the rest of the teams. One of the teams tried one-week sprints; they found it to work well for some work, but the perception greater of overhead had them go back to two-week sprints. An obvious way to schedule sprints is to align them with the Monday to Friday workweek. However, I don't like this, as public holidays in the United Stats tend to land on a Monday or Friday which can affect your sprints ceremonies. In addition, Mondays tend to have the highest rate of absenteeism and people's energy levels are the highest mid-week. Mid-week sprint starts avoid these issues and allow teams to work well together across different timezones. If your sprint ends on Friday, then people in other timezones may already have started their weekend. To decide on when the sprints should start and end, it's important to talk with your team. Sprints ensure that everyone's work aligns and that they are working as a self-organizing team. If they feel like they're battling against different calendars – the corporate one, the holiday one, their personal rhythm – the team may not be able to reach the desired level of high performance.

Lessons learned

Be flexible in your planning. Assuming that sprints are the right approach for you, figure out what your business is able to support. It's okay to start out by trying what everyone does, with two-weekly sprints, starting on a Monday. You can then examine how well those sprints are working, and determine if you need to make changes. From my experience, two-week sprints work well, as they are a nice compromise between too much time being given between projects in four-week sprints, and too much time being spent in meetings with weekly sprints. Additionally, I prefer mid-week sprint starts, as they ensure people remain energized, and the sprint ceremonies are less likely to be affected by holidays. It's important to have sprint retrospectives, as they allow you to look at not just what you built, but how you've built it. Put everything on the table - it could be that at standups everyone is always late, so the time should be adjusted, or it could be what went well and what didn't. The purpose of a sprint review is to adjust if you're not on track in terms of building a product, a sprint retrospective is about if you're on track in terms of how you build it.