This is part two of a three part series, where I explore the fundamental shift in adopting an agile development methodology and explain how to analyze and measure success. If you missed part one, you can check it out here.
In part one, I discussed some of the history around the shift to agile and why it needed to happen for Roambi. For part two of this series, we’ll take a deeper look into the logistics of how we manage the agile process and what fundamental practices need to be in place in order to succeed. If you’re a product manager, project manager, developer, quality assurance specialist or just generally interested in how organizations run and track agile, then this post is for you!
Getting Setup for Success
This is one of the more complicated aspects of moving from a traditional development process to an agile approach. Because I’m not attempting to write a book here, I’ll keep it short and to the point and focus on the pieces that really mattered to us. Looking at the shift in a linear fashion, getting setup for success can be distilled down into 3 important sections.
Define a Process
I’m not talking about defining scrum here, that part has already been done for us. No, I’m talking about the entire end-to-end process, where the dynamics of scrum, albeit extremely important, are only a portion of the process in it’s entirety. Think about the entire process (not just the development portion). Ask yourself questions like;
- How do we get our direction? Meetings with management? Collecting feedback from a customer portal? Following a roadmap of initiatives?
- How much lead time is required to go from vision and strategy to user-stories and effective sprint planning?
- How can we organize those pre-planning phases to work with our agile process?
- What do our releases look like? Do we deploy code on a frequent predictable basis? Do our sprint timelines coincide with those objectives or will they conflict?
- How will we communicate progress or missed commitments?
- How will the cumulitive effort be externally communicated? Release notes? Emails? Marketing communication?
Make sure you have answers for all of those questions and any others that are relevant to your organization and product/s. Start with a timeline of Scrum meetings over a particular sprint (Figure 1), as a basic structure for how things should play out. Then begin to overlay other external factors, such as releases and pre-planning sessions (Figure 2).
Does it make sense? If not, massage it until it feels right for all stakeholders. Don’t be too afraid if your proposed outline needs refinement. It’s more important that all external factors have been considered and addressed, in some fashion, versus a plan littered with holes that you plan to address at a later date. The goal of defining a process at this point is to create rules that people can follow and help your organization move forward without asking, “What are we supposed to do next?” Think of this process as the schematic and your development organization as the machine. It’s not about building the perfect machine it’s about building a machine that will work and can be tuned and refined without having to rip the whole thing apart every sprint.
Pick The Right Tools
Tools, tools, tools…a project manager’s dream and a start-up’s nightmare! This doesn’t have to be the case if you understand what the tools can provide to your process. Remember, it’s about helping you succeed and choosing tools that work for the process you defined. First, take a hard look at what you already have. It’s extremely common for smaller organizations to get complacent about the tools they have in place. They become misused and in a lot of cases, simply configured for a process that no longer exists. That complacency ends up creating frustration for the people that interact with those tools on a daily basis and sometimes leads to rash decisions to deprecate the whole thing. I call this the “clean slate” syndrome, where it seems more reasonable to start over with something completely different than invest time to fix what you have. Those types of decisions can have unintended consequences, like ramp-up time and onboarding. A lot of people in your organization have probably built up a substantial amount of expertise with the tools that you have, so consider updating existing software over a full replacement. Also consider how your current tools integrate with each other and what you might lose or gain by switching to something new.
Anecdotally, we use JIRA Agile as our main issue tracking system. GitHub for development projects and collaboration. Google Apps for basic word processing and spreadsheet needs, as well as Smartsheet to augment our more complex spreadsheet needs. On the build side, we are working with Jenkins and exploring what Bamboo can provide. On the customer facing side, we use Salesforce, Zendesk and Hubspot.
Keep Engagement High
With our experience, the move to agile brought with it an inherent enthusiasm. Switching to agile was an obvious and conscious decision to be “better” at what we do on a daily basis. Who can’t get excited about a proposition like that! That being said, keeping everyone motivated and engaged at all times is crucial when you’re starting agile. It can become very easy to slip into a routine, especially one that seems to be a huge step forward. I implore you, do not slip into a routine. The process must evolve constantly, which means constant reevaluation and collaboration. You might need to get creative with this, as everyone will have a slightly different level of enthusiasm for process. Here are a few things we’ve done to help engagement stay high and not feel stagnant.
- Give others an opportunity to be involved outside of their normal roles. For example, at Roambi we do not have dedicated scrummasters, so each team is encouraged to swap out scrummaster roles on an interval that makes sense for them. Of course, this needs to be accompanied by proper training. Don’t just throw somebody into a role they don’t understand. Give them the tools to succeed and they will.
- Encourage cross-team collaboration. Set up scenarios where members from different teams have an opportunity to share their experiences or work together. This provides a much more organic mechanism for feedback and learning.
- Empower decision makers. There will undoubtedly be a flood of valid feedback coming in from all areas. When someone has a good idea or proposes meaningful improvements, let them run with it. We can all learn from each other and sometimes, as managers of people and process, we tend to hold on too tightly and miss opportunities to improve in fear that we might lose control.
Tracking Starts With Good Data
Whether we’re talking about product metrics, usability statistics or issue tracking, you must have good data to work with. If you don’t get a handle on the data coming in, you will never be able to parse out what needs to get done, what’s been done and what effect that’s had on your customers. Remember, agile is all about bringing value to your customers and value is measurable. So, the million dollar question; how do you get good data? Well, you might be surprised to find but the answer is relatively simple. It’s all about meta data…gobs of it!
I’ll start with a simple example that product managers, like myself, can relate to. How do you keep your product backlog in check? Enhancement requests from the field, bugs from QA and an always evolving product, with countless features to implement can be extremely overwhelming. Great product managers will tell you that you need to take action as soon as possible, no matter how small that action is. If you don’t, you risk being consumed with a clutter of unorganized “stuff”. It’s not that much unlike your email inbox. Are you the type of person that has 18,000 unread emails in your inbox? Or do you take action immediately as they come in, even if that action is to simply move it to a to-do list?
This is not a rant about cluttered email inboxes (though that is a pet peeve of mine). The point is that you need to take action but that action will most likely be followed by some other action. With a product backlog, it can be as simple as tagging something as “not now” or “needs elaboration”. This is what we refer to as “triage”. Product managers are very familiar with this term but conceptually, you are tagging items with relevant meta data that can be followed later with a more specific action. This concept can be extended to any facet of good data tracking. Raw data is just raw data but if you start adding relevant meta data that helps you push that data to a more filtered state, you are that much closer to being able to take an action that actually means something.
This is part 2 of a 3 part series. In the final post of this series, I’ll reveal how we analyze measurable data to make better decisions for our product and ultimately our customers.
Justin Cox is a Senior Product Manager at Roambi. Along with his product management responsibilities on the Roambi platform team, he’s also the resident agile evangelist and JIRA expert. Justin has more than 10 years experience and has co-authored multiple patents in data visualization.