How to Be Faster in Agile
Can Agile be faster, do more with less, and still deliver quality?
18 April 2017
Any organization that has gone through an Agile transformation asked for Agile because they thought it would be faster, do more with fewer resources, and increase quality. Although these things eventually will happen, they don’t reflect the real picture of Agile.
Will you work faster in an Agile environment?
It would be more accurate if we put the question of speed in the right context; Agile is more about getting rid of anything that doesn’t deliver value, so eventually we should end up delivering more functionality over a shorter period.
A major principle in Agile is to continually determine the undetermined — to make sure that we are going about things the right way. I can plan, research, and do proofs of concepts, but I’ve got at least a handful of issues for which I'm anticipating the actual working software I’m supposed to build. Agile supports the principle that you will never know everything about the code until it’s already written, and instead of wasting your time with assumptions, let's focus our effort on what we do know. The more code we write and visuals we get, the more we learn and are able to move forward. This can happen by focusing on what we do know and building actual value out of it.
Doing more with fewer resources while we boost quality
You can use one or more of the following approaches to help speed the delivery of your product, with fewer resources and without sacrificing quality.
Have you been asked to detail the behavior of software before it sees the light of day? It’s all but impossible to design the details for anything when we don’t have visuals. For software, which is interactive, you must predict how your prospective customers will use the application.
User stories are reminders of the features we think we would like to implement, but we are deferring decisions about their details until we have something that will help us decide. User stories are purposefully short and informal — for example, "As a type of user, I’d like to X so that Y." They’re scribbled on cards that can be easily viewed and then sequenced by priority by customers or product owners. We can all intuitively understand that it’s no problem for the customer to add, update, remove, or reorder them at any time up until the point we’re working on them in an iteration.
Yes, we’ll eventually need to understand their details, but not until we’re ready to work on them.
This is a difficult practice to implement, because intuitively we believe that if we knew, up front, every aspect of how the software should look and behave, we could come up with an optimal design. We think that if we build only one feature at a time, without considering future requirements, we’ll end up with software that will fail before a customer can use it. If we add every new feature without any consideration for the overall design, yes, it will fail. I’ve worked on systems whereby the more functionality we build out, the more we learn about what type of design makes sense. Just like our user stories, the more of the application that gets built, the more we understand about what works and what doesn’t work, enabling us to make sound decisions. We can come up with the optimal design only by implementing functionality and then using the knowledge gained to evolve our design with each new feature.
This is not a call for "no design" akin to the myth about no documentation for Agile. Rather, this is emerging design. It means that for every new feature or new user story we implement, we will determine what will be the optimal design based on current functionality and behaviors, which all draw directly from the Agile concept: "Continuous attention to technical excellence and good design enhances agility."
Don’t look at refactoring as the result of a lousy team or bad code. Refactoring is a direct result of iteration. It is something we continuously build and evolve according to design principles to keep our code clean.
This is when the Agile technical practices are really meant to work together, so, yes, refactoring is like a house mortgage — try to forget about it, and pretend it didn’t exist — unless you plan it with your team.
Ideally, we are following acceptance test-driven development (ATDD), which is an executable plan that serves as a safe acceptance criteria, that describes what is expected of the user story that you are implementing.
Rather than spinning our wheels figuring out the optimal way to handle functionality, TDD provides us a structured way to approach it, designing and developing it one step at a time, always focusing on exactly what our code needs to accomplish and what we want our design to be.
You don’t have to do pair programming for every line of code written, because it will slow down your team. But you have to admit that pairing is a great way to share knowledge, get people up to speed on new technologies or unfamiliar parts of the system, and get a second set of eyes for working through a particularly tough problem. It’s also a great way to keep things moving forward. The pair can bounce ideas off one another, and often when one is stumped, the other has an idea to move it forward.
Make sure you don’t miss the bigger picture; the most important thing is that the entire team is moving forward in the same direction.
We need to makes sure that our team is moving forward together, not working against one another. One way to this is by running the automated tests that have been built up through ATDD and TDD every time someone checks in code. If a problem is caught often, the team can quickly resolve the issue while it’s still fresh in their minds.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.9 (7 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.