You Need to Use Agile Before Writing Your First Line of Code
You Need to Use Agile Before Writing Your First Line of Code
In this article, Randy Earl explains how he uses Agile to optimize resource use, minimize risk, and maximize quality for his company and its clients.
Join the DZone community and get the full member experience.Join For Free
“Agile development practices have steadily risen to become trusted and preferred methods of development…using Agile, organizations can respond to market changes faster, deliver higher-quality software, and gain a significant competitive edge.” – Harvard Business Review
Considering these benefits, it’s no surprise that Agile development has become immensely popular among technology companies. More than a fixed methodology, Agile development is a mindset that embraces flexibility as its key characteristic: “evolving our practices to suit the challenges at hand,” according to Andy Hunt, one of the originators of the Agile Manifesto.
At the agency where I work, we put these ideas into practice with a hybrid approach incorporating many aspects of Agile development into each project. One thing that sets us apart is that we apply this mindset during the discovery phase of the project when we are working with the client to define product requirements.
According to PricewaterhouseCoopers:
“One of the key differentiators for the Agile methodology is the requirements-gathering process and the iterative approach that fosters alignment through increased communication…Agile provides a high level requirements process to define what the system should provide, not how the system should work.”
This quote sums up our approach: you start at the very highest level of requirements for your business and your customers and what they need to achieve, and don’t discuss how that will be done until later. The details of how you achieve those objectives come in the second critical part of the quote during the iterative process of increasingly refining your focus to more granular aspects of the requirements and solution.
Our solutions team has a toolbox of discovery techniques to observe, investigate, research, and experiment. These techniques allow us to ask and answer specific questions about needs and potential solutions. The specific forms of discovery include interviews, workshops for brainstorming and collaboration, surveys, reviews, and focus groups, among others.
We identify requirements in a hierarchical, iterative approach so each step informs and determines the next. For example, in the very beginning, we use stakeholder interviews and sometimes business model and/or value proposition workshops to identify key aspects of the business and the project. These aspects include a first pass definition of the market and which customer segments the solution should address.
Let’s take user research as an example. We need to define many characteristics of the people who will use the solution, such as their demographics, wants, needs, and behavior patterns. Depending on the nature of the website or application being developed, we may need to go into more detail regarding specific tasks and workflow, as well as roles and permissions.
In order to discover those details about the user base, we employ one or more of the following techniques:
- Persona workshops
- Focus groups
- Contextual inquiries
Each technique answers specific types of questions and provides certain types of information. However, we won’t know which of these techniques to use until we have performed the first-pass definition of business requirements. For example, a business that needs to deepen engagement of existing users might survey those users to learn more about what they wanted, while a business that needs to reach new audiences might use persona workshops to discover who these new users are.
Another possibility is that something we find in discovery may send us down a completely unexpected path. For example, we recently had a client engage us for a redesign of their static marketing website. Their current site contained hundreds of pages of content, so we took the usual step of performing a content inventory. This technique is helpful in determining information architecture, content update needs, finding forms and data feeds, etc.
Our content inventory also led to an important discovery: the website contained functionality for posting open positions and accepting applications for those positions. The initial client brief had not mentioned this critical capability.
As a result, we added a step in discovery to perform a process analysis and map out their entire process for posting and filling new positions. This would identify exactly which steps would need to be replaced on the new website. Had we not done this, when the old website was turned off, they would have suffered a severe disruption to their hiring process. As an added benefit, this analysis identified multiple process improvement opportunities which were incorporated into the requirements discussion for the next phase of their project.
These two examples show how applying the agile principles of flexibility and feedback from the very start of a project provide several benefits throughout the project:
- Optimize resource use by applying only the techniques needed.
- Identify risks as early as possible in a project.
- Identify opportunities for continuous process improvement.
- Allow for prioritization of tasks.
- Increase precision of estimated effort.
To recap, we find that it is not efficient to try to state categorically exactly what the appropriate discovery for a given project will look like in advance. This one-size-fits-all approach either includes too much (and is thus expensive) or misses crucial information (thus incurring high project risk). Instead, we find it much more effective to “adapt our practices to suit the challenges at hand” (to paraphrase Andy Hunt). This optimizes resource use, minimizes risk, and maximizes quality for us and for our clients: a win-win application of Agile development.
This article was originally written for Atlantic BT.
Opinions expressed by DZone contributors are their own.