I hear stories like this all the time: A client is growing disillusioned with Agile because they feel that committing to sprint backlogs is preventing them from being responsive to operational needs that pop up on a daily basis. Or maybe a team following scrum is griping about the number and length of all the meetings they have to attend when they’d really rather just be writing great code. If this sounds familiar, it’s possible that you need to get back to basics.
The problem is that oftentimes we get caught up in these agile frameworks and begin following their processes blindly. Many managers have a tendency to select a process framework that they’ve read about or that they’ve heard of other teams using successfully, then they let this framework dictate their processes. What they should be doing is starting from the ground up, focusing on the principles that their processes need to follow, based on the specific and individual needs of their team and their business. Then they can select the processes and frameworks that work best based on these principles. I call these principle driven processes, and I strongly believe that this is the only way to ensure that your development team can deliver value in the most efficient way possible (and to be happy while they do it!). If this sounds good to you, but you’re not sure where to start, you’re in luck. These are my steps to creating your own principle driven processes:
Step 1: Create your own Manifesto
Hopefully, by now, you have heard of the Agile manifesto. The story goes that in 2001, 17 pioneers in lightweight software development methodologies got together to discuss how they worked. What came out of that meeting was the Agile Manifesto and the 12 principles of Agile Software. While the various methodologies that these folks had created preceded the Manifesto and the 12 principles, the methodologies collectively became known as “Agile” methodologies. If you have not read the Agile Manifesto or the 12 principles, stop what you’re doing immediately and go read them here. Even if you’ve read them before, go read them again. No seriously, it will take you less than 2 minutes. GO READ THEM!
Back? Great! Now the reason I’m so passionate about these basic agile principles is that these are the foundations for everything that every Agile team should be doing. These are the ‘why’s” behind the ‘what’s’ of your processes. It is so much more important that you and your team understand these foundations rather than clinging tightly to specific processes specified by a given methodology (more on this in a second). What I’m going to propose, however, is that not every one of the 4 statements in the manifesto or the 12 principles is created equally. Some of these will resonate more with your team than others.
In fact, the manifesto and the 12 principles aren’t the only lists of Agile values or management principles in general that you should concern yourself with. I find that as someone who went to school for Industrial Engineering, I’m particularly drawn to the 7 lean principles, which have a background in manufacturing and have been adapted for software development. There are also countless lists of principles and concepts of software engineering and software engineering teams out there. Some good ones can be found here, here, and here. For larger, more complex teams and organizations, the principles of the SAFe framework can be pretty powerful.
You don’t have to live and die by every one of these lists, in fact, that’s likely a good way to overwhelm your team. The point is, for you and your team, some of these may be more impactful than others. You may have your own favorite lists of important Agile principles, and you’ve probably developed a few of your own most important principles over the years.
The first step in creating principle driven processes should come as no surprise – define your principles. Read up on the “best practice” sets of principles (no seriously, if you haven’t read or re-read the Agile Manifesto yet, go do it!), but remember that you and your team know your business best. Throw out principles, combine lists, add your own. Make your own manifesto and make sure that it makes sense to you and your team. A few thoughts for this step:
- Make sure to engage the entire team – The whole team is going to have to live with the processes built on the principles and values you define here. Make sure to engage them in their definition. The diversity of viewpoints will help to avoid blind spots. A good way to ensure everyone has a chance to have their voices heard and to not let this process drag on too long is to utilize a KJ session.
- Be thoughtful, but don’t take forever – The agile principles that you commit to at this stage will form the framework for your team’s processes later, so don’t take this lightly. That being said, you could also debate the intricacies or wordings of individual principles forever and never get any work done. Make a decision and move on. You can (and should) revisit and revise these later!
- Keep it simple – Don’t let your list of principles and values get to more than 7 or 8 (bonus points if you can keep it to 4 or 5). Keeping this list focused will ensure that the team can easily remember and keep these principles in mind as they go through their day to day efforts.
Here’s an example of a personalized manifesto that one of my client teams came up with. This team built shared APIs for various internal front end teams within the company to consume. You’ll notice the team defined what each standard manifesto point meant to them specifically. We also removed the principle downplaying comprehensive documentation as API contract documentation was an important part of what made this team successful. We included one of my personal favorites at the end as well.
Step 2: Define your Minimum Viable Process
Now I’ll be the first to tell you, I love process. My wife would tell you about the times I’ve spent 30 minutes planning out the most efficient way to complete a 5 minute task. There’s just something beautiful about finding the most elegant set of steps to get something done. When it comes to your team’s processes however, less truly is more. While a regular cadence of meetings and a set list of steps to follow will ensure that everything gets done at a reasonable pace and nothing gets missed, superfluous meetings, documentation requirements, and defined communication flows can quickly get away from you.
Remember that the goal of any process should be to simplify the steps it takes for your team to get good work out the door while ensuring that nothing important gets missed. Any steps that don’t directly meet that end goal are just taking your team away from production time. A great read that may drive this point home is Paul Graham’s Maker’s Schedule, Manager’s Schedule. If you’re like me and love having a set list of steps and meetings for every given workflow that you could have to get done, you’re likely used to working on a manager’s schedule. Your work and personality prioritizes communication flows and keeping everyone on the same page. Remember that for the makers who likely compose your team, these steps can sometimes take away from the main work of your team – producing the product.
This is all to say start small, then add meetings, steps, process gates, etc. only as needed to solve specific problems. In the same way that the Lean Startup advocates for a Minumum Viable Product as the starting point to any product offering, you should think of your team’s Minimum Viable Process as the starting point in defining your best team processes. This means start with the lightest weight process that will allow your team to get their job done, then add overhead only as necessary.
So how do you know what’s included in your Minimum Viable Process? First, start with your team’s core agile principles. Do you have well-defined requirements that just need to be executed on? Maybe infrequent status check-ins will give the team more heads down time to work on their individual parts. Does your customer require frequent status report outs? Make sure you have enough touch points with the team to accurately deliver these. Do you work in a complex environment where your team’s product needs to interface with many sub systems? Perhaps more comprehensive interface documentation is a necessity. Trust your gut at this stage, there will be plenty of time to iterate and improve as you move on from the Minimum Viable Process.
This step is going to go much more quickly if you start from a well-defined process framework and then add or remove items as necessary. To this end, remember that Scrum is not the only agile framework that exists. I’ve worked with too many clients that use the terms Agile and Scrum interchangeably to describe the end goal for their teams processes. Scrum is the most popular base agile framework and works very well for pure product development. Its fixed sprint backlogs can become a nightmare in operational environments where system issues pop up on a daily basis, however. Kanban may be more effective in such a scenario, though it can leave you in a lurch if you’re looking to estimate and report out what your team will be accomplishing in the upcoming weeks. Your company may also have a standard process that doesn’t match either of these frameworks exactly, but works great for the various communication and compliance flows specific to your work environment.
The point is, you should look at the various process frameworks as tools in a tool belt. The prescribed workflows, meetings, documentation requirements, etc. of any framework are all designed to resolve particular issues or handle certain situations. Use the components of a given framework that correspond to particular issues you foresee in your particular situation and leave the rest. The agile principles that your team agreed to in the previous step should guide these decisions.
Take for example a recent team I worked with to define a Minimum Viable Process. This team had a duty to maintain development environments for other dependant teams and to quickly investigate and resolve any issues that popped up there. A kanban approach offered flexibility to reorder priorities and a limit on work in progress which helped ensure quick turn-arounds. They also had to coordinate with other teams and the business to plan for longer term feature development that spanned multiple teams. For this reason, we included a light sprint review/planning meeting every two weeks. This allowed us to chunk work into iterations and ensure the team was on track. Tickets were not mandated to have full acceptance criteria or complexity estimates until they were pulled into a “ready to work” status, right before work was begun. This ensured that no time was wasted planning around a given task that may never actually be worked as requirements quickly shifted.
Step 3: Iterate often
Your Minimum Viable Process will allow the team to hit the ground running, but you’re not done yet. Remember the Minimum Viable Product? This MVP is way to get something into customers’ hands early in order to start validating product hypotheses and iterating based on customer feedback. Similarly, your Minimum Viable Process is the starting point from which you will iterate and improve based on what works for your team. There is a pretty simple formula to this:
- Hold regular retrospectives – The main tool you will use in this phase is the retrospective. This is where you get the whole team together and go around the room, talking about how to improve your process. There are a ton of great resources out there if you want to do a deep dive on the sprint retrospective (seriously, google “how to run a retrospective” and you will be blown away by the number of articles on the subject), but don’t overthink it. Ultimately you just need to go around the room and have the team answer the three basic questions: “What went well since the last retrospective?” “What could have gone better?” and “What are some ideas to improve on these items?”
To ensure everyone’s voice is heard, it is often best to let each team member answer these questions without interruption, then discuss any major ideas for improvement that came up afterwards with the whole team. This should all end with a few action items that the team generally agrees on. Make sure you track these and actually do them!
- Remember to trust what your team is telling you – when it comes to iterating on your processes, remember that the team is most familiar with how things are going. If they tell you that something is not going well, don’t write it off, try to resolve it. I can’t tell you how many managers I’ve worked with who have complained that they just can’t get their team members to follow through on documenting their code, or that their team members are always carrying on about the number of meetings their in. Chances are if problems or complaints like these are recurring, it’s not a matter of lazy team members, it’s a bad process.
Now don’t get me wrong, sometimes we all need to be pushed out of our comfort zones and change takes time. Don’t rush to change your ticket tracking tool because one engineer complained that they don’t like it. But if you’ve given everyone some time to get used to a process and a particular complaint is still popping up, see if it is shared by multiple members, then fix it! “How?” you say?…
- Solve individual issues with process tweaks or frameworks – This is where you go back to the tool belt analogy. Remember that every meeting, every process framework, every ticket tracking tool should have a particular purpose. Think of all of these things as tools in your tool belt that you can deploy to resolve a particular issue that the team has, and in this way, you are building up your team’s ideal processes.
Is it starting to take a long time to get any individual task through your system? Try visualizing your backlogs via a Kanban board and limiting work in progress in any given state. Are daily standups becoming a waste of everyone’s time? Try moving to every other day or three days a week, focusing on regular in-person collaboration to keep everyone on the same page between these meetings. Does the team consistently fail sprints because tickets are just about there, but not quite “done done” on the last day of the sprint? Try extending sprints to 3 weeks instead of 2 and see if that helps.
You get the point: identify specific problems, then look to the various process frameworks and your own creativity for a solution that could resolve them. Always engage the team in this process as they’re often in the best position to creatively resolve these issues.
I probably should have called this “Phase 3” rather than “Step 3” as this process never ends. Don’t expect that you’ll get to your perfect processes and then nothing will change. Changing business environments, team composition, coding problems to solve, etc. will necessitate continuous and eternal iteration and evolution of your processes.
Bonus Step: Don’t be afraid to throw out the Scrum Handbook
We’ve talked a bit about how you should take a look at other frameworks outside of scrum when defining your Minimum Viable process and how you should think of the components of any process framework as tools in your tool belt, but I’ll emphasize this one last time: Don’t do anything just because the book says so.
I’ve worked with a few agile coaches in the past who always seem to say things like “we can’t add these tasks into our backlog until they’re written in good user story form (‘As a __ I want __ so that __.’) because that’s what Scrum calls for.” Now don’t get me wrong, Scrum processes offer a pretty solid default and the things laid out in the Scrum Handbook are generally pretty good practice, but if something isn’t working for your team, get rid of it! Never trust someone who calls for any particular process, meeting, methodology, or tool if they can’t explain why it’s a good idea and what specific problem it will resolve for your particular team.
And there you have it…
And there you have it. Follow these steps and your team will be humming along in no time. Remember not to overthink it. Define your basic agile principles, put a process into place and get moving. You can always reevaluate and pivot later as needed. Focusing on principle driven processes and continuously iterating and improving is the only way to keep the team moving forward and producing at a high level as the environment around it shifts and evolves.
Anything here resonate with you? Disagree on any of these points? I’d love to hear how principle driven processes have worked (or not worked) for your team. Drop a comment below and I’ll be sure to respond!