A while back I had the bright idea of writing an “agile weekly” to share information specific to agile values, principles and practices via Asynchrony’s blog on a weekly basis - one quick blog post each week - how hard could that be to keep up? Alas, a great idea and you might have even seen some of these, but it didn’t take me long to realize just how quickly we can lose track of the principles that best enable agile to be successful. In particular, achieving “sustainable pace” is something that escaped my mind as I started writing weekly posts. That said, I finally managed to find a slice of time (by applying a few of my own lessons learned) so that I can write a bit to share some of the items I learned from my failed “agile weekly” experiment. These lessons learned are intended to help others achieve “sustainable pace”. Ensure the outcomes of work activities are well aligned to the goal At Asynchrony I have many priorities, and while posting to the Asynchrony blog is encouraged (and fun), it unfortunately is not my top priority. Sustainable pace is best achieved by ensuring that work performed is aligned to the top goal(s) for an individual or team. In this case, I signed myself up for work that unfortunately didn’t align to the top activities I need to support. Working to establish alignment between work performed and top goals creates motivation to follow through on the work that is required. To put it simply, I had greater motivation to support other activities that were more aligned to my goals and that I felt provided greater value to the organization - hence while writing to the blog here is enriching, I felt that focusing on coaching teams and facilitating training to enable others to improve provided greater value. As a result, my motivation to focus on weekly blog writing decreased. There’s a strong parallel here for agile teams - look at the stories you are currently developing and those that are prioritized to be addressed next - do all of these stories align strongly to the “goal” of your team? If you have stories prioritized that aren’t directly supportive of your goal, be mindful that motivation to complete non-aligned stories may suffer impacting sustainable pace. That said, if you have stories prioritized that aren’t directly supportive of your team’s goal, why are you doing them? And of course if the people on your team aren’t clear on what the goal of your team is, STOP developing and get everyone on the same page - having team consensus and strong understanding on a team's goal is a prerequisite for sustainable pace. Establish a schedule / cadence of needed activities Consistent outcomes are best achieved by adopting a consistent schedule of the activities needed to create those outcomes. Had I thought about this, I would have scheduled a consistent time each week to write my weekly blog post and been able to keep that time available to work on my blog post. As previously noted, since weekly blog writing was not strongly aligned to my top priority, the time I tried to set aside to write wound up being used for other activities that provided greater value and were more strongly aligned to my goals. So while misalignment to goals prevented me from being able to keep an established schedule, it’s important to not miss out on the linkage between having a schedule (sometimes also called a cadence) and ensuring that required activities are completed to maintain a sustainable pace. For agile teams, one of greatest benefits Scrum provides is establishing a regular schedule of the activities a team needs to complete to be successful - Scrum goes so far as to call these “rituals”. Alas, Scrum ensures that teams have a planning meeting to review and discuss upcoming stories, a demo to present completed work to the customer, and a retrospective to identify improvements - these rituals occur once every sprint. Beyond Scrum, the Scaled Agile Framework has established a similar cadence and collection of rituals that are intended to allow large organizations to be able to deliver software regularly encompassing the outputs from multiple teams. Meanwhile, some teams that use kanban or flow can experience challenges maintaining a regular schedule of the activities that are intended to help the team be successful. I’ve worked with a few kanban teams where the team was so focused on delivery, next thing we knew, 3 weeks had passed and the team hadn’t had a demo to get feedback from the customer, or the team kept putting off grooming the backlog with the product owner so they didn’t have good customer feedback on what to do next - while this isn’t always bad thing, it also isn’t always a good thing, especially if the customer identifies things that need to be changed that could have been caught earlier. The bottom line is that team should schedule work to ensure that required work is completed in a timely fashion and make it easy to achieve a sustainable pace. If you’re on a team practicing Scrum or supporting Scaled Agile, the framework will establish a schedule for you. If you’re on a kanban team, think about adopting working agreements that trigger necessary activities when a specific number of stories are completed - such as: having a customer demo whenever the team has 15 - 20 stories in the done queue. Measure outcomes then inspect and adapt Whether we choose to admit it or not, all work is done in a “systematic” matter and consequently can be measured. Even activities like writing a blog post takes a specific amount of time (called “cycle time”) and every so often I actually manage to complete a blog post (called “throughput”). These metrics (and a few others) can guide a team to sustainable pace; however, the key to success is looking at the metrics gathered as part of a system vs. looking at each metric in isolation. For the “agile weekly” experiment, writing a short blog post doesn’t take that much time (“cycle time” is short), but that doesn’t necessarily mean I’m going to have a new blog post every week unless I also consider my “throughput”. As previously mentioned, my “throughput” of blog posts is low due to other priorities I’m motivated to complete due to my goals. Using such metrics data, I know that even if I change things to try to write my blog posts in less time (reduce cycle time) such a change will actually have no impact on the outcome unless I do something to increase my “throughput” of completed blog posts. From looking at the data, I can see that my problem isn’t that I’m spending too much time writing blog posts (so I don’t need to go to a writing workshop), but rather I need to focus my efforts on improving my “throughput”, which goes back to goals and scheduling considerations previously discussed. The benefit of having these metrics in place is as I change things about my schedule or my goals, I will have data to determine which changes are providing benefit and which are not. An agile team can be guided to sustainable pace by having metrics data that encompasses the work of the entire system that a team operates within - sustainable pace is achieved by gathering a collection of metrics at the system level to assess the benefit of changes made, rather than examining a single metric in isolation. Have you ever been on an agile team where you get things rolling, then the customer shows up and says “we must go faster” - come on, I know I’m not the only one. Next thing you know, the team abandons practices like test driven development or pair programming seeking to reduce the cycle time of development - the only problem is these changes are made without having any data to show if they will actually support the goal of going faster. Yes, these changes will make development take less time (although the quality of the code developed will suffer), but in the long run, if the outputs of development are constrained by something else like testing, integration, or release activities (which many times they are) - such changes to development have no impact on the goal of going faster. If you’re on a team and you’ve been issued the “go faster” challenge and you don’t have this kind of data, you really need to prioritize gathering it so that you can assess the impact of the changes you make. And if you’re wondering, using personal kanban, I have cycle time, throughput and other metrics for my blog writing activities - the free versions of kanban tools like “Kanbanize” and “LeanKit” make it really easy to get this data for anything that you do. But that’s not all I learned - the “words” you choose really do matter An additional item I reflected on after the “agile weekly” experiment is thinking a bit more about what’s in a name and the close relationship between the words we chose to use in names and how those words influence the expectations of people (or customers) around us. Consider this, the name “agile weekly” created expectations of a timely and recurring post each week about agile values and principles and unfortunately that expectation was not met. Rather a name like “agile insights” communicates the same intended outcome; however, it eliminates the additional expectation of time and better positions me to be able to meet my customers’ (readers’) expectations. Recall that agile challenges us to maximize the amount of work not done, it’s amazing how sometimes just the choice of a word or two can create the need to do more work which ultimately may not be needed to achieve the goal. While this seems so simple, it’s so frequent that teams use words in the definition of their user stories that introduce additional expectations (beyond what the customer originally asked for). As can be imagined, once the customer sees these stories and approves them for development, the customer’s expectations grow to encompass the words used by the team. In some instances, this makes it harder for the team to succeed since team now needs to satisfy an increased number of customer expectations. In closing, an experiment for you to try:
Go look at a few upcoming stories in your backlog
Look at the words used to communicate the outcome of the story
Ask yourself if the words used to express the stories have set additional expectations beyond what your customer initially asked for.