Agile is one of those activities where the more you do it, the more it just makes sense. And once you start winning with agile, the “A-ha!” moments will come fast and furious. With this in mind, I decided to ask members of the Ascendle team – all experienced agile practitioners – to look back at their own A-ha! moments while using Scrum to manage their client projects. Here are some of the agile lessons learned they shared.
“Always break your work down into the smallest chunks.”
This is helpful both for sprint planning and for gaining momentum during a sprint. By breaking down user stories into smaller chunks, you can fit more of your highest priorities into every sprint. Since your sprint production capacity is limited, once you get towards the end of your planning you might have to drop further down your product backlog list than you want to. This can happen if all your highest priority “chunks” are too large to fit, causing you to drop down to your second tier of priority stories.
Smaller chunks also allow you to gain momentum during the sprint. Each time a story is driven to “done,” it represents a victory for the team. Recognizing more victories like these is one of the best ways to increase your team’s velocity. For many scrum masters, the systematic chopping down of stories becomes of the most important agile lessons learned.
“Let the agile process guide you into working on what matters most.”
An important benefit of agile development is the ability to focus on and complete the most important features first. Scrum does this through prioritization of the product backlog.
When executed correctly, the product owner will arrange the development team’s “to-do list” in order of business value. The team then plans the sprint by adding the user stories at the top of the product backlog until the sprint’s capacity is full.
The beauty of agile is that the focus on what matters most does not end there. Between every sprint, the product owner has the opportunity to re-prioritize the product backlog. This allows the team to shift focus quickly to meet new business initiatives, competitive environments, and any other factors causing your business objectives to change.
While the scope of work the team committed to should never change during a sprint, agile’s flexibility allows you to switch gears and focus on new objectives in as little as two to four weeks – the length of a typical sprint.
It also drives home the importance of maintaining the order of priorities within the sprint, since you never know when unexpected obstacles may occur. As one of our senior ScrumMasters shared, “Work the sprint board top-down and finish the work in the current sprint before looking ahead.”
With Scrum, there is really no reason for a development team to start working on anything that’s not in the current sprint, since priorities can change before the next one starts. Even so, the tendency to work ahead (siphoning away time and brainpower that should be devoted to the current sprint) can be a hard habit to break, but once you do, you will have another agile lesson learned.
“Respect the flow of communication through an agile team.”
Agile communications are already laid out in structured, fine-tuned processes. Trying to improve on them or “streamline” your efforts by cutting them is one of the more common reasons why some companies fail at agile.
Daily standups, for instance, should teach you the value of forced communication, and are one of the most important agile lessons learned along the way. When the team knows that a daily standup will occur every day, regardless of the situation, it does two important things:
- It creates more discussion by eliminating the desire to “hold back” ideas, problems, or solutions. At the same time, these shorter, more frequent meetings are more focused and productive than the longer
traditional meetings most non-agile developers are used to. - It leads to better solutions by guaranteeing that all team members hear the issues being faced and have a chance to participate in the discussions.
Remember also that Scrum team members are considered equals and decisions are made by the development team rather than individuals. This entices development team members to speak up and share ideas since they all share accountability (good or bad) for their results. If discussions are dominated by certain individuals – such as those with higher titles and ranks outside the team – then the flow of communications are just as clogged as if standups did not occur.
Communications in and out of the team are also managed by the Scrum process. Business stakeholders can help set the team’s priorities through the product owner. But other than that, they should hold no influence over the development team’s daily activities. Once a team starts taking direction from the outside, it’s hard to hold them accountable for their results – or to motivate them to the high standards of success an experienced agile team can attain.
“The strength of an agile team is greater than the sum of its individuals.”
Sounds cliché, but high performing agile teams tend to get more out of individual team members than they’ve ever produced before. That’s because agile focuses on the team’s ability to do the work rather than on individual performance. For many, developing a “we” mentality over a “me” mentality can be one of the most valuable agile lessons learned.
Other software development methodologies focus on the work – developers are only responsible for their chunk of it. In many cases, their failures or lack of progress don’t adversely affect anyone but themselves. But in agile’s team environment, each team member is fully invested in the success of the others.
Also, consider that agile teams are relatively small. A typical team consists of just five to nine core members. Others may be brought in for specialized skills on a temporary or part-time basis, but it’s that core team that’s responsible for their decisions. With such small teams, the importance of each member becomes apparent rather quickly. There is no feeling like “a small cog in a big machine” – the team soon realizes that it is the machine, and in most cases will step up its game accordingly.
“Agile lets you focus on solving problems rather than laying blame.”
Agile teams are in it together, so to speak. Each member is responsible for the results of the team. So when problems arise, it does no good to point fingers and lay the blame. Instead, agile puts the spotlight on the problem… where it should be.
Most problems can be traced back to a failure in the processes being followed. Because Scrum is both streamlined and structured, it’s often easy to see where such failures occurred. And since sprints typically occupy just two to four weeks, your window for correcting errors is always a short step away.
For instance, if the development team underestimates the work to complete a user story, it could cause that story to go unfinished (and don’t ever extend a sprint just because developers are struggling with one story). If that story remains prioritized for the next sprint, the development team will get a chance to estimate the work remaining – now with the knowledge gained from the last sprint under their belts.
Because new estimates are only a sprint away, problems don’t snowball like they can under traditional development methodologies. The team can work together to solve any problems that might occur in this way, whether they involve estimating, communications, teamwork, or whatever.
“User stories solve the problems created by traditional requirements documents.”
The user story format adopted by agile solves many of the problems that were created by traditional requirement documents.
First, user stories force us to think about the who, what and why something matters. It’s not just an abstract technical specification – it gets at the real reason behind each feature. This perspective often leads to more creative and innovative solutions than would otherwise be the case.
The user story approach also demands open discussion and whole-team interaction as the details of the story are discovered. The inevitable “churn” created by drafting, reviewing, editing and re-reviewing of traditional, hundreds-pages-long requirements are replaced by a shared understanding. This greatly reduces the chances of miscommunication and alternate interpretations for each requirement.
“Don’t let process get in the way of progress.”
Scrum maps out an extremely effective and efficient set of guidelines that will lead to successful results when followed. But one of the key values of the Agile Manifesto reads individuals and interactions over processes and tools. This includes the Scrum process itself.
If the development team is dutifully following the process, but someone has an idea of how to streamline things even further and drive more stories to “done” more quickly, do it! Sometimes experienced Scrum teams slip back into old habits of doing things “the way we’ve always done them,” stifling creativity.
Don’t let the process get in the way of progress. Experiment with new ideas and adopt those that produce the best results, even if it’s not “our current process.”
“Wait for user stories to reach the top of your backlog before investing too much time in them.”
Creating actionable user stories can take a lot of work. First, you need to break them into stories of the appropriate size. We’ve found that sizes no larger than 25% to 33% of your average velocity produce the best results. Then you need to express the who, what, and why of each story and ensure the acceptance criteria captures the discussions by the Scrum team. Then you need to estimate the work involved, story points, and so on.
The good news is, you don’t need to do all that up front. And you really shouldn’t. Because some user stories will never end up prioritized near the top of the backlog. More important priorities will always end up getting inserted before them. Others will wait a long time before they’re addressed. Any time spent on these stories now is time that could have – should have – been spent on higher-priority needs.
One Ascendle team member recalled a bunch of time she spent creating some really sweet mockups for a particular story. She and her team spent a significant amount of time during their backlog grooming discussing the story in detail and estimating the story points. While the story wasn’t at the top of their backlog, they reasoned it would be in an upcoming sprint. But the client changed their priorities during the next sprint review and the user story was never developed. All the time they had spent – other than a high-level discussion and quick story point estimation – was wasted.
While the flexibility of Scrum is one of its greatest strengths, it can be a drawback if you allow yourself to put too much effort into stories that are too far ahead. For this reason, keep user stories at a higher level until they’re very close to the top of the list. Large stories are called epics, and serve to keep your product backlog from getting cluttered with too much detail. Only when your epics are very close to the top of your backlog should you take the time to split them down into smaller pieces.
“Track your numbers and course correct sooner rather than later.”
Always trust your numbers. Don’t wait until it’s too late to course correct your sprint.
The beauty of using an agile management tool such as Jira (to estimate story points, establish a velocity, and update sub-tasks to feed the sprint burndown chart) is that we have a wealth of information to help us determine if we’re on track during a sprint. Or if we’re on track to release the next version. Some teams will make justifications when things are off track. For example, assuming that they’ll hit a release date even though the JIRA version report suggests a date that’s two weeks later than your target is optimistic.
Don’t sabotage yourself by ignoring the data and missing out on one of the key agile lessons learned. Accept what it’s telling you even if it’s not “good news” – such as pointing out when your estimates are over-optimistic. Get as much done during the sprint as you can, and keep optimizing your process to increase velocity. Address any misses during your sprint retrospective and correct them when planning your next sprint. In doing so, each sprint provides its own agile lessons learned that will benefit you in the future.
Getting Help from the Agile Experts
As I mentioned earlier, the agile lessons learned here all came from experienced agile professionals on the Ascendle team. Take their “A-ha!” moments and put them to use in your own organization. Or, if you’d like that expertise put more directly toward your agile development efforts, contact us today and let’s discover where Ascendle could be of greatest value to you.
