Agile is a data-driven, streamlined project management process designed to minimize distractions while still providing multiple opportunities to check and adjust the course of development. If done correctly, it can allow for long-term project plans that are accurate and resilient to changes.
Unfortunately, “Agile” is a trendy project management term that project managers and leadership love to brag about, but in a lot of cases, companies don’t do proper Agile because they don’t understand what they’re doing or why. Luckily, we engineers can get to the root of things and do things right.
Meetings
First, the whole point of Agile Scrum is NOT to waste time; it’s exactly the opposite. A brief check-in in the morning should leave most of your day free from interruptions. Once each sprint (typically two weeks) the development team will have a planning/estimation session and a sprint demo. Once a month your team should do a retrospective to address internal process problems. If you’re having more meetings than this, you’re getting caught up in the ceremonies and not the Agile.
- Daily
- Standup – 15 minutes
- Sprintly (every two weeks)
- Estimation meeting – up to 4 hours
- Sprint demo – up to 2 hours
- Monthly
- Retrospective – 1 hour
Total time available to work: 160 hours per month
Total time in meetings: 18 hours or 12% per month
- Standups: 5 hours
- Demos: 4 hours
- Estimations: 8 hours
- Retrospective: 1 hour
Daily Standups
Standups are an important aspect of visibility between your developer teammates and your Project Manager (PM). It’s how you communicate with your team about what things they’re working on, as well as gives everyone an opportunity to help each other in case they’re not thinking of something important.
The three questions:
- What did you work on yesterday?
- What will you work on today?
- Do you have any blockers, issues or concerns?
Goals: Pay attention to your teammates, because they might be walking into trouble or might need additional information about their task that they don’t know to ask for.
Respect the Scrum Master (SM) – they’ll tell you to take your detailed technical discussions “offline” or wait for a “parking lot,” which just means you’re interrupting the flow of the standup. This is fine; engineering meetings outside of this are part of the development process and not explicitly part of Agile/Scrum.
Backlog Building/Grooming
Most developers are only vaguely aware of the backlog building and grooming process and it doesn’t fall in the typical set of developer meetings. The Project Owner (the Client), the Project Manager, and the Lead Developer will get together to discuss new features. This is where User Stories are made. Once the PM has a stack of cards, they need to have the team estimate the tasks.
Estimates
Sprint planning and estimation is a critical process that engineers need to be involved in. It’s how the team builds out the data that the Project Manager uses to make long term planning decisions like deadlines, feature priority, and even budget. But it’s important you follow the process, or your estimates will end up inaccurate and the Project Manager will get annoyed with your team.
Each User Story needs an estimate, either in Ideal Hours or in Effort. These are both abstract concepts and are not directly related to actual elapsed time. At Perficient Digital, we like to use Ideal Hours. This means your team needs to agree on an amount of time each User Story will ideally take. But if someone says, “Oh, that looks really easy. It’s probably only 2 hours,” your team will be primed to give a low estimate, even if they have knowledge about the task that would make it much higher or lower. You can avoid issues like this by using Planning Poker, which I outline below.
Be careful though; only use Ideal Hours, and not an exact time. If you estimate a task at 8 hours and 30 minutes, you imply a false level of accuracy that can mislead your Project Manager and Scrum Master. These are estimates and intentionally include a level of uncertainty.
Planning Poker – How to Play
- Read a User Story and discuss the requirements and implementation. If the team feels like the Story doesn’t have enough details, don’t estimate it and return it to the Project Manager.
- If the team feels confident that they can complete the User Story, have each engineer pick an Ideal Hours value from this list:
- 30 minutes
- 1 hour
- 2 hours
- 4 hours
- 1 day
- 2 days
- 4 days
- 8 days
- Have each engineer write their estimate down secretly and then count to 3.
- On a count of 3, each developer will show the value they wrote down and discuss why they feel something should be estimated higher or lower.
- Once the team has come to an agreement, write that estimate down on the Story and move on to the next one.
Sprint Demo
The Sprint Demo might seem like a pointless meeting, but the goal is important; you are expected to demo the things you worked on to force you to build things that are actually working. It’s tempting to split tasks into chunks like “front end” or “back end” but this doesn’t result in working software, just working pieces. Without the focus of constant delivery, developers will revert to building just the parts they’re responsible for instead of focusing on the true goal, a working application or website.
Retrospective
The Retrospective doesn’t need to be tied to sprints but should happen regularly. Standups, Estimates, and Demos are all opportunities to see and adapt the product; the Retrospective is the opportunity for the team to do the same.
The goal of this meeting is to talk honestly and respectfully with the team to identify good and bad processes and help reinforce or fix what’s going on.
Retrospective – 4 Steps
- Review what fixes we agreed on last Retrospective – did these things get fixed? Why or why not?
- What went well this iteration?
- What went poorly?
- Come up with solutions for how to fix issues or reinforce good processes, and make sure each goal is assigned to someone to complete before next Retrospective.
Takeaway
Agile is a popular business buzzword but originally was an exceptionally high-function development management system. If developers understand the why of Agile, they can make better use of the benefits.
References
The Scrum Guide – The Definitive Guide to Scrum: The Rules of the Game by Ken Schwaber and Jeff Sutherland
Agile Estimating and Planning by Mike Cohn
Agile Software Development: Principles, Patterns and Practices by Robert Martin
