In our last post we discussed how becoming an agile organization is key to staying competitive in today’s hyper-competitive and fast-moving business environment. But how do you get started? Our own Diana Rodriguez said the best way to ease into the process is to start out with an agile pilot project.
Rodriguez emphasized that this kind of pilot is different from our conventional understanding of a pilot (the use of wireframes to demonstrate an application’s functionality). The type of pilot we’re talking about is the creation of a real application that will be delivered to a production environment.
The goals of a pilot project to prove the viability of the Agile methodology at your firm are three-fold:
- To solve a real business problem in a low-risk way (preferably an internal application, not a client-facing application).
- To prove that agile can work in your organization.
- To lay the foundation so you can scale up and adopt agile on a broader scale.
How do you conduct an Agile pilot? We’ve broken down it into five different stages.
1. Identify The Project
Try to find a candidate that solves an immediate need within a controlled environment. Look for a low risk application, but one that’ll drive value for your organization.
For example, we helped a prominent global hardware storage company choose an HR application for their pilot because it was not a customer-facing app where they could potentially be exposed to negative consequences if the pilot didn’t go well.
2. Build Your Team
Next is to identify the people who will staff the project, beginning with who your product owner is. The product owner is that person who can speak to the business and is empowered to make decisions.
Then choose the project stakeholders. These include representatives from the functional areas as well as the non-functional areas. The functional areas are those departments that define the product features and functionality. These are usually business stakeholders.
The non-functional areas refer to system architects, UX/UI designers, data architects, and DevOps. These folks help to lay the foundation for how the application will be built, and the non-functional requirements the app must adhere to such as performance, security and the tech stack, to name a few.
Last – but definitely not least – is to choose the development team who will build out your product.
3. Train Your Stakeholders
If you’re conducting a pilot it’s because you and your organization are new to Agile, so you’ll need to train your stakeholders in proper Agile procedures to ensure everybody understands the rules of the game, and everybody is rowing in the same direction.
And even though some of your technical folks may be well versed in Agile, training should ensure your development team has a homogenous understating of the Agile development processes to be used.
The end result should be complete synchronization between the technical team and the business stakeholders in their understanding of how Agile will be applied.
4. Hold a User Story Workshop
Here’s where the fun begins. Get everybody together for your initial user story workshop. In Agile, a user story is a detailed description of the features and functionality of the product as experienced by the end user, which provides a clear vision of the product end-state. These are added to the backlog as the work to be done (see definition of backlog below).
Make sure your user stories are written from the point of view of the users. According to Scum Methodology, “…a team may write its user stories in a number of ways as long as they are written from the perspective of the end user.” This allows the development team to have great empathy for the people who will actually use the application, which results in a better product.
A user story workshop typically follows the following process:
1) Introductions
2) Context Explanation
3) Brainstorm user stories (encourage all participants to brainstorm on as many ideas as possible and think about the product from a 360 degree perspective to surface distinctive features and technical characteristics).
4) Prioritization (don’t prioritize until a large number of user stories have been written)
5) Acceptance Criteria Definition (this is typically a very long process). It’s not unusual to iterate several times during step number 3 and drill down from product goals to actual product features.
Before step 5, it’s really important to add a “Release Planning” step. This is where the team assigns the prioritized user stories from the backlog to a timeline. More than an estimation process, this activity helps the team to envision the different product releases to be delivered to the business, and provides for a readjustment of priorities. The Release Plan will need to be revisited and adjusted continuously to ensure your product priorities are aligned with business priorities.
5. Start Your Sprints
With Agile work is done in sprints. Again, our friends at Scrum Methodology describe it best: “…In the Scrum method of Agile software development, work is confined to a regular, repeatable work cycle, known as a sprint or iteration. Scrum sprints used to be 30 days long, but today many teams prefer shorter sprints, such as one-week or two-week sprints.”
You’ll perform your work to fulfill your requirements in a series of continuous sprints to reduce your work backlog. At this stage you’ll also perform backlog refinement, backlog analysis, and plan for upcoming releases and sprints.
Make sure you have as much of a backlog as possible, or at least enough work for the next two to three sprints so your team can work while the product owner is laying out the next series of sprints.
Demo Continuously to the Business
Finally, a bonus point. It’s important to frequently demo product increments to the stakeholders so they can witness the on-going business value being created by the Agile team. This is one of the key differentiators of agile projects compared to traditional projects, and provides the required credibility top management needs to endorse an enterprise-wide adoption of agile methodologies.
Conclusion
These pieces are essential for a successful Agile pilot project - and success with your first pilot is key because it will serve as the foundation on which to introduce Agile to the rest of your organization. It will also generate trust with your business stakeholders, and will help you gain credibility with the those who were initially resistant to the idea of introducing Agile.
If you’d like more information about how to get started with Agile and DevOps in your organization, visit our DevOps Operations Management page.
