An Agile Approach to Going Agile
Although Agile has been around for some time now, it seems like there are still companies who are struggling to integrate it into their working model. I still hear statements like “the business refuses to adopt it” or “ we call it fragile” and continue to receive questions about how to adopt Agile and related frameworks. The greatest mistake that I continuously see is trying to adopt too much at one time. This is especially true for large organizations which are trying to push their versions of Agile across the enterprise.
Agile is a great approach to developing products, not only for technical teams but with any organization (team, department, company, etc.). With the focus of placing greater value on the collaboration of individuals, working products, and being able to respond to change, as opposed to creating exhaustive documentation and following rigid plans and complex processes, it is easy to understand why Agile and its various frameworks are adopted into product and service delivery organizations.
As organizations look to take their first steps down the agile transformation journey, many questions naturally arise: how do we implement Agile, what is the best framework to use, what tools should we use? Some teams may go at it alone, learning lessons along the way and adjusting as needed, growing, and maturing with each product released or project completed. Some organizations may take the journey and find that they are stuck in the land of process confusion, while others may fail to get started as they become paralyzed in a state of unending analysis. Some organizations may be directed to take on specific agile frameworks well before they are ready or faster than they are able to, while others, may find that they are being forced to take on complex and complicated “agile” processes fabricated by the minds of non-practitioners. With each of these scenarios the most frequent and most important question that organizations may ask themselves is “where do we start”? In any of these situations, transitioning from a predictive approach to an agile approach may feel like a daunting endeavor; however, by taking an agile approach to going agile, teams can easily integrate Agile into their working model.
To support your organizations agile transformation, please consider this light-weight guide which will help in its transformation by reducing some of the up-font decision making at the start of its journey.
BECOME INFORMED
Prior to getting started with agile, it is good to have a basic understanding of what it is. There are many articles, books, blogs, and websites, that talk about agile and the various frameworks that are used to support it. Rather than this guide becoming yet another article that presents what agile is, I will direct you to two of those that describe it best.
To start, read the two sections of Agile in a Nutshell: In a Nutshell, and Fundamentals. Jonathan Rasmusson, author, engineer, programmer, and longtime practitioner provides one of the most concise explanation of Agile. This will give you and your organization a baseline of which to start from. Moving on, your organization should be come intimately familiar with the 4 core values of the Agile Manifesto. Established by the 17 core founders of the Agile Alliance, the Agile Manifesto serves as the keystone and foundation of agile and the various agile frameworks worldwide. By keeping these 4 core values at the heart of your organization’s strategy, you will have a solid foundation of which to start building. With any process that your organization introduces, always compare it against the core values found in the Agile Manifesto. After you (and your organization) have read through that information, discuss what was learned, what it means to be agile, and ensure that everyone is onboard with adopting an agile approach and its core values.
2. ESTABLISH A CULTURE
The agile approach is more about people than it is about process (although process is important), and so you and your organization should establish a culture that embraces Agile. Because this is so important, I am going to focus a lot more on this area than others.
After a few years of practicing agile, my team decided to define a set of internal values: Advocate for the User, Code SOLID, Design for “Of Course”, Research³, Put the Schmoo On It, etc. While some of these values may seem obscure, nonsensical, and even downright silly, after spending some time with our team one would see that there is real meaning behind each of them. First and foremost, our team wanted to ensure that these values were not just a set of words and business jargon that were posted on a wall and ignored by everyone. Our values had to be something that we believed in. Second, the values had to be practical and useful. Third, the values needed to reflect our culture. Finally, everyone shared in the creation of these values. As a result, we began using these terms as a part of our normal vocabulary and our work began to reflect these values. While our products were good prior to implementing these values, they became even better afterwards. Our processes improved as well.
Another strategic decision that was made was to establish our Why. Simon Sinek, best-selling author & world-renowned speaker established this concept of Why in 2009, with the idea centered on helping people become inspired about why they do what they do in order to change the world for the better. Using his concept of the Golden Circle, (Why, How, What) we drafted our own Why statement. If our processes were the methods of how we navigate, our Why statement became our True North, something that we could always refer to ensure that we were on the right course. As with our values, we wanted to ensure that this was something that our team fully embraced and did not feel like a canned business statement.
The third major concept that was implemented within our team the creation of a master plan. Rather than having long winded mission statements with boilerplate business jargon, we opted for something that is easy to understand and defines key objectives which we can then measure. As with our statement of Why, we were inspired by another visionary: Elon Musk, founder of SpaceX and CEO of Tesla Motors. In 2006 Musk released the 4-point Secret Tesla Master Plan. The beauty of the plan was that it was incredibly concise, easy to remember, and told exactly what the company was planning to do. In a similar fashion our team established our own 4-point master plan…
· Capturing and reporting on as much data possible.
· Using the data to make process improvements and better product decisions.
· Using the process improvements to make even better products.
· Do all of this to support the digital transformation of our organization.
We used this plan to drive everything that we did, and as new products were implemented, we ensured that we adhered to this plan. Three years later, we reflected on this plan, discussed what went well, what we could have done better, and then decided that a new master plan was needed based on the strategic direction and needs of our organization. If the statement of Why was our True North, then the master plan was our map.
Along with these three key points, we also ensured that we celebrated team and individual wins (no matter how small).
Having a strong, creative, and diverse culture that encourages contribution and feedback from team members is crucial for the success of any organization. As your organization takes on an agile transformation, be sure to establish a culture that mirrors its goals and values. Establish team values, define a statement of Why, create a master plan, and celebrate the successes.
During this time, it also makes sense to inform your customers, product owners, and other stakeholders that some changes are being made as a part of your agile transformation. This will help prepare them for these changes as well as being able to provide constructive feedback now that a milestone has been established.
3. MAKE A CHANGE
Now that your organization has learned the basics of the agile and has established a collaborative way to working, it is time to incorporate agile practices into your work. The biggest issue teams face when starting is taking on too much process and getting wrapped up in perfecting a toolchain from the very start. While there are some great tools out there and while it may be tempting to jump right into a framework like Scrum, it is best to take it slow and build up in iterations; otherwise, you risk losing sight of the purpose of the transformation and/or burning people out.
To start, try doing these 4 simple things…
1. Implement a Daily Stand-up. Yes, this is derived from Scrum, but this quick 15-minute check-in is easy to do and is one of the most valuable process you can implement. By simply asking the 3 standard stand-up questions (what did you do yesterday, what are you working on today, do you have any roadblocks), your team will gain transparency into what is occurring and expose roadblocks that team members may be facing. This is especially useful for team members who may be hesitant to mention roadblocks for fear of sounding like they are complaining.
2. Implement a bi-weekly review session. This process, which is also derived from Scrum, asks what was completed during the previous two weeks. It also asks the question of what will the team plan on working on in the next two weeks. There are a few key differences here between this Review Session and a Sprint Review/Planning Ceremony. First, this is a more informal review than what a team would see in a Scrum ceremony — there is no formal review of completed stories or tasks nor is there a review of velocity. The second key difference is that this is a meeting that only the development team participates in. The reason for the informality is to simply establish a routine way of working. Like a warmup in a workout, this review serves as a way to get team members comfortable and ready to take on more impactful activities. While there may be some opposition to not including a Product Owner in these activities, the point of this step is to get the development team ready by establishing a good cadence before engaging outside team members; however, if your team has a Product owner who appears to be very enthusiastic about this transformation and is willing to sit through a period of normalization then by all means invite them to join.
3. Identify a facilitator from the team to run the Review sessions and lead the Stand-ups.
4. Provide frequent status updates to your product owner and stakeholders. Unless you have a Product Owner that is attending the Review sessions, provide these updates following the same cadence as the reviews (in this case every two weeks). Keep the updates positive, even when presenting roadblocks, and keep the meeting brief. The point is to gain support for the transition while also benefiting from obtaining valuable insights from your Product Owner and stakeholders.
As the team and organization begins the transformation of their processes it is a good time to start reading more about agile frameworks, especially Scrum. At the same time, track any lessons learned, throughout the process.
4. FORMALIZE THE PROCESS
After a few of months implementing the previous change (2–3 should be sufficient), it is now time to take on more formal processes. To start, Scrum is the recommended approach. The reason for this is that Scrum provides the structure for new teams to operate in while being flexible enough to scale to your organization’s largest initiatives (more on scaling a later time). During this time the team should bring all work and requirements into an official product backlog. Start using official terms such as User Stories, Epics, and Tasks. Bi-weekly review sessions should become official Sprint Review, Sprint Planning, and Retrospective Ceremonies. For each of these Sprint Ceremonies an official Product Owner should be in attendance. During these meetings engaged Product Owner should be prioritizing the work to be completed (supported by information and feedback from the development or implementation team). The team should also agree to a Story Point structure for estimating work; there are a few different approaches to choose from. Our team currently uses a Fibonacci scale based on level of pain and ambiguity, but experiment and find what works for you and your team. Finally, keep track of velocity and reflect on it frequently to ensure that the team is taking on the right amount of work and not overloading team members or under delivering.
While implementing these changes it may be tempting to leverage project management software such as Jira, Basecamp, Trello, etc. I recommend that when starting out, it is better to simply leveraging the tools at hand such as whiteboards, sticky pads, and markers for tracking work and Word, Excel, or even a physical notepad for tracking requirements. Just do not try to shoehorn this into something like MS Project.
There are three key reasons why it is better to work with physical medium rather than comprehensive tools. First off, it is much more important for people to get used to the new way of working and thinking than trying to figure out how to implement new software solutions. Secondly, when starting with advanced tools, people often try to model their process around the tool, rather than using the tool to enhance the process. Finally, there is something gratifying about physically moving cards and notepads along a board.
5. IMPLEMENT A TOOLCHAIN
When your organization has become comfortable with the process and is looking to advance in its transformation, a product toolchain (software linked together that typically represent specific stages) is the next logical step. This is especially true for software teams looking to build out a CI/CD pipeline (Continuous Integration / Continuous Delivery). Some companies such as Atlassian offer a full suite of tools (Jira, Confluence, Bitbucket, Bamboo) and plug-ins that provide complete traceability for software. There are many opinions on which platforms and products are best, but teams need to choose based on their process needs and budget. Be sure to evaluate various products, performing your own A/B testing. It may also be logical to only implement a portion of a product suite initially, focusing on where the greatest need may be (e.g. starting out only with Confluence & Jira).
6. IMPROVE THE PROCESS
At this point, your team or organization, has been working for some time now with agile. It has delivered products, made mistakes, learned lessons, and made changes. The next steps in evolution is scaling and taking on other agile frameworks. The Kanban approach works very well for DevOps teams, while Nexus is great for scaled projects (following the scrum framework). Prior to scaling or adopting new frameworks, it is recommended that the team or organization go through some level of process improvement activity. There are many methodologies that exist that support process improvement, and a separate article would need to be created to compare each of them. While there are benefits to those methodologies, a formal process audit and improvement initiative may be overwhelming for some. This is even more so for organizations that do not have the budget or resources to dedicate to such an activity. While I am not discouraging anyone from taking on that approach, I would like to offer a simple alternative.
1. Look at how your team operates and break it up into separate holistic process groups.
2. Review the process areas with your team and ask what is working well, what may need improvement, and where there are simply gaps in a process.
3. Create a backlog of issues.
4. Prioritize the findings and focus efforts on a single process area.
5. Establish a plan to make improvements.
6. Once the prioritized items are complete, go back and work through the backlog.
After making critical improvements it may be time to evolve in the process even further.
7. BEGIN TO SCALE
The next steps in the maturity process of any team are to scale and evolve. The maturity transformation may come in the form of establishing multiple feature teams or it may mean transitioning to Kanban. Regardless, while this is the next step in the transformation, it is not the last. In fact, true agile teams should continually be evolving, always looking reflecting on their own processes and practices, looking for ways to do things better. Whatever the approach may be, implement changes incrementally, reflect on the change, document what went well and what needs improvement, and repeat the process. Evolve and grow with confidence.
Many organizations are looking to make improvements in how they create and deliver products. Agile, while it is a great approach for product development and delivery and is also a fantastic approach for supporting many business processes, is not a one-size-fits all solution, nor it is the answer to all project management needs. There will always be some room for formal predictive project management approaches (e.g., Waterfall), but at its core, agile concepts can be applied to anything you or your organization does. Natural evolution is not scripted, and neither should any organizations be. While there are best practices, each organization must do what makes the most sense for itself. For those looking for a timeline as to how long any team should remain in one state or phase before advancing, I would recommend a few months; however, some organizations (e.g., for small private agencies) the transformation process may go quickly and for others (e.g. global enterprises) it may take a long time; it all depends on the organization. Whatever process change your team implements, take an agile approach to the transformation. Make small incremental changes. Reflect on those changes. Adjust. Repeat.