The Agile Manifesto was written almost 20 years ago. If Agile were a fad, it would have surely died by now. Instead, it has continued to evolve and 1, 2, and 5 years from now it will look much different than it does today. That is why it is so important for the learning to continue. The further you fall behind, the longer it will take to catch up. Learning does not have to be an onerous process. Making it part of your daily life ensures the learning continues and makes it more fun.
1. INTRODUCTION
It has been over 10 years since I was first introduced to the world of Agile. This unique journey has highlighted the need to continuously learn and accept the fact that the learning never stops. The importance of this NeverEnding story cannot be understated as Agile continues to advance. Today’s Agilists need to find creative ways to continue their learning and share their learning with others.
I believe this story needs to be told so that others feel empowered to explore their own Agile journey and maybe one day they too will share it with others. I also believe that many Agilists (new and old) may not realize their potential. Even though this report doesn’t cover all likelihoods, it is my hope that it provokes thought and possibly uncovers ideas I haven’t even thought of.
This experience report will focus on 6 key areas that helped to accelerate my Agile learning. These learning areas were not pre-planned nor were they documented (at least to my knowledge they weren’t). Rather, they happened over the course of a decade without even realizing it.
2. BACKGROUND
When I started my Agile journey, I really had no idea what I was doing or what I was getting myself into. It was easy enough to bury myself in a mountain of books but sooner or later you realize that just is not enough. In my local context (Alberta, Canada), there was not a whole lot of people to turn to. Agile user groups had minimal turnout. Furthermore, the overall Canadian adoption of Agile at that time was severely lacking and even today it is years behind the acceptance in the United States. There seemed to be this general reception that this Agile thing would one day go away, but I wasn’t buying it.
In 2013, I attended my first Agile conference in Nashville, Tennessee. At the outset, I felt completely out of place and I remember thinking that I made a huge mistake coming and all the attendees must surely know much more than myself. As intimidated as I was, I forced myself to make acquaintances with some of the well know Agilists including Jeff Sutherland, Mike Cohn, Lyssa Adkins, Esther Derby, Ahmed Sidky, Janet Gregory, and others. I took part in just about every event possible and some days that meant starting at 8am and ending at 2am. By the end of the 5-day conference I was completely exhausted but at the same time I couldn’t believe how much I had learned. That was the moment I realized that an investment in Agile learning was absolutely necessary.
3. LEARNING AREAS
As mentioned, I stumbled across 6 key learning areas along my Agile travels. That is not to suggest that only 6 exist. In fact, there are likely more and maybe I’ll encounter those as my learning continues. Also, these learning areas did not occur sequentially. In fact, some of them were occurring at the same time and in many instances, I was jumping back and forth.
Figure 1. Six Key Agile Learning Areas
3.1 Individual Learning
This is where many people start their Agile journey. Like most, I heard the rumblings of Agile and became quite curious. After all, I was tired of Waterfall projects and I had given up hope that they would one day magically work. In other words, I reached the “tipping point” (Gladwell).
To be perfectly honest, what really resonated for me was that Agile suggested no documentation (which I later found out to be untrue). So, I began my Agile learning by reading some online articles. As my interest piqued, I realized it might be a good idea to supplement my reading with books. Since I didn’t know which books to read, I relied heavily on the online articles to point me in the right direction. As a result, I started reading various books that included Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen; Agile Estimating and Planning by Mike Cohn; and Agile Software Developer with SCRUM by Ken Schwaber and Mike Beedle. It seems others started along this path as well. In the beginning, Em Campbell-Pretty (author of Tribal Unity) was not at all confident about Scrum so she armed herself with Agile and Iterative Development by Craig Larman and Agile Data Warehousing by Ralph Hughes (Campbell-Pretty).
I also began to try out various engineering practices on my own mostly because my team members at the time had very little knowledge of those practices or they no interest in learning about them. One of those practices was TDD (test driven development). It took a little getting used to, but once I got good at it, I realized that taking the time to write tests first, actually allowed me to produce code faster. I began introducing this into my work projects and others were amazed at how fast I could complete my tasks.
After my first real-life Agile experience (see Section 3.2), I was more intrigued than ever. I was desperate to determine whether or not Agile really worked. At the time, I was considering graduate school (specifically a Master’s degree in Computer Science), so I decided to pursue that opportunity and focus on Agile. In fact, most of my research was on Agile. This ultimately led to my thesis, which was titled “Challenges in Distributed Agile Software Development.” Preparing my thesis gave me a deeper insight into Agile. Not only did it provide me with more reference material, but also it offered a different way of looking at things. I was utterly amazed at what the research community was attempting to uncover.
3.2 Intra-Team Learning
Shortly after I began my individual learning, I started a new job and was assigned to a new project where we were required (i.e. contractually obligated) to use Agile. I thought to myself, this practical experience is just what I need. So, I was excited to put my elementary Agile knowledge to use as my role was to participate as a developer on a Scrum team. However, my excitement was short-lived. The client decided that the team had to write design specifications that required sign-off before they could begin development. This really frustrated me because we would spend multiple sprints writing these design specifications that prevented us from producing working software. My annoyances were further exasperated as the remaining team members felt that the design specifications provided a lot of value and were necessary. Also, I didn’t like the fact that everyone worked in siloes. There was a situation where two developers on the team were touching the same code base and didn’t talk to one another. As a result, the later code merge took the developer a total of 2 weeks. Furthermore, the sprint retrospectives did not provide an opportunity to improve. A round robin was performed where each team member answered 3 questions (What went well?/What went not so well?/How can we improve?). Nothing was actioned nor was anything added to the backlog. As the project continued the stakeholders became increasingly dissatisfied with the lack of progress. In fact, there was an eruption (by a few managers) in a sprint review as the team was giving a demonstration of the application and it crashed multiple times. The managers decided the team needed to focus only on producing code, so they canceled various events like the sprint review and the sprint retrospective. Even though the project eventually made it to production, many considered it a failure. I was curious as to why this Agile project had such dismal results. Since nobody could provide any real insight, I decided to conduct my own analysis. That’s when I pursued my Master’s degree (see Section 3.1) only to determine that the project was far from Agile. Even though the “failed” project wasn’t especially fruitful, I would later realize that knowing what not to do, is just as important as knowing what to do.
As I moved onto other Agile projects, I made more of an effort to push the adoption of XP practices. One of those practices (i.e. pair programming) had a huge impact on my learning. Watching others navigate through their IDE (integrated development environment) and gaining an appreciation for their productivity tools greatly increased my throughput. Another important aspect of pair programming that caught my attention was the amount of knowledge transfer that happens. It seemed like such a waste to hire new people and bury them in documentation for weeks when you could just have them pair up with a team member and they would be productive from day one. Finally, I think the most important aspect of pair programming is that two people working together easily produce software, much faster with higher quality than two people working individually.
Another important point about this key learning area is that I learned by imparting my knowledge onto others. I held various sessions on TDD and other important topics that developers cringed at. By teaching others, I was able to reinforce my understanding which made me that much more knowledgeable. In other words, teaching others is a great way to learn.
3.3 Inter-Team Learning
Some of the larger and more complex Agile projects I worked on required the use of multiple Agile teams. In these situations, interdependencies had to be considered. Interdependencies require that teams communicate effectively and work together instead of engaging in “the blame game.”
Agile promotes fast integration cycles. When teams integrate frequently, they receive faster feedback. Implementing continuous integration is of absolute importance. Without continuous integration, teams perform integration less often, with many manual steps. I worked on a few Agile projects where continuous integration was an afterthought. Those situations resulted in teams that were extremely stressed out especially at the end of sprint where they were required to work an incredible amount of overtime to produce a system that could barely run on its own. While continuous integration itself is highly important, it led me to realize how important a full suite of automated tests is. Automated unit tests, integration tests, and UI (user interface) tests are absolutely necessary when multiple teams are integrating and even more so when they’re working off of the same code base. This learning area really identified the need for teams to work together and communicate often. When all of the teams worked as one team, a lot of value was delivered.
Getting teams working together can be a daunting task. Social events definitely help to encourage communication but often teams stick to their siloes or don’t attend. On more recent projects I’ve noticed that CoPs (communities of practices) are becoming more common. This is a great opportunity for everyone to learn. A CoP typically starts out with 1 or 2 organizers, but the momentum can build quickly. In fact, some CoPs generate long lists of presenters willing to share their knowledge at the next CoP meeting. For example, many multi-team environments struggle with continuous integration and continuous deployment mostly because it’s new to them and they don’t understand the principles behind it. Starting a “Build” CoP can go a long way to bridging the knowledge gap. In the beginning, the temptation can be to lecture to the attendees about the importance of automation, but it doesn’t have to be that way. In fact, a Build CoP that I started quite recently commenced with a retrospective. I facilitated a retrospective to determine what were the main pain points with the current continuous delivery pipeline. The attendees generated many ideas and brainstormed many solutions, some of which ended up in the teams’ backlog. Some future CoP meetings were conducted as one-half presentations and one-half discussion, but the attendees didn’t seem to mind now that their voices were being heard. I learned that facilitating learning amongst multiple teams gets them closer to working as one large team.
3.4 Organizational Learning
Some organizations claim to support their Agile transformation and then there are the ones that actually do. Establishing a training budget (for the purposes of internal training) can be problematic given the fact that Agile training can be expensive. Even when a training budget has been established there are many instances where it’s been revoked once the company financials are released that are below expectations. There have been many occasions where I’ve fought with management to have an external trainer come in and train the teams on engineering practices. In many cases I lost the battle. However, there were some wins and having the teams undergo the same training at the same time was hugely beneficial. Everybody was on the same page and they were able utilize what they had just learned, the very next day. This type of training is quite popular in the SAFe framework where everybody (including executives) take part in training.
Organizations also need to provide the necessary time to allow people to foster innovation. Hackathons are an example of this. Giving people the time to be creative will increase morale and likely result in lower turnover. In terms of learning, the teams are trying out new tools and techniques, many of which they’ll be able to utilize when they get back to their day jobs. This creates a sense of excitement. I remember when we tested out JSF Primefaces and got it working. The team couldn’t wait to overhaul our web application with our newly found Java framework. What may not be obvious is that the organization is also learning. The organization is able to take advantage of these wonderful creations that didn’t require an enormous time investment. That’s why Google strives to create a culture of innovation (Thomas). What really stood out to me here is that, if you don’t make time for creativity and innovation, it won’t happen.
Agile typically grows out of an IT department and as such, IT is the most knowledgeable about Agile while the rest of the organization struggles to keep up. There needs to be re-alignment to ensure everyone is speaking the same language. Even though the business may not provide Agile teams, they still need to be part of the learning process. Human resources, finance, sales, marketing, and other departments all need to learn at the same pace as the Agile teams so they too can be part of the process.
3.5 Global Learning
The importance of this learning area is to learn from others outside of your current context. This includes attending (or presenting at) conferences and participating in training that your organization is not currently implementing internally.
In my own experience, I have greatly benefitted from attending conferences. It really gave me the opportunity to think outside of my current context whether you’re conversing with another attendee or listening to a presentation. As a consultant, this is really important because you’re likely moving between clients with some regularity which means you’re continually switching contexts. Conferences provide an opportunity to learn from others that are much better than you are. About 8 years ago, I started out attending 1 Agile related conference a year. Today, I attend 2 or 3 (sometimes 4) every year. As I attended more and more conferences, I became curious about presenting at conferences which I began about 4 years ago. The experience has been amazing because it allowed me to reinforce my own understanding of the topic at hand. Furthermore, I was able to build on my conference presentations by writing research papers and experience reports. Conducting research provided a whole new avenue for learning. Also, I was able to work with shepherds all over the world to critique my work (including this paper). This global scale has allowed me to establish friendships with people around the world. We have even gone so far as to create a support group (on Slack) so that we can coach one another when we need help. There are many times when somebody in the group posts a Slack message that looks like “I’ve got an issue. Does someone have time to coach?” It doesn’t take long for someone to respond and pretty soon there are multiple coaches trying to help you out. So, we learn from one another even when we’re distributed.
A smaller (but hugely beneficial) form of conferences are Agile user groups and coach camps. User groups are an excellent opportunity to learn especially for those that are on a limited budget. These events are typically free, and sponsors are usually willing to provide pizza. It’s also a great opportunity to get involved. I started out by helping to organize speakers at our monthly user group and eventually I had to confidence to give a talk myself. This eventually led to speaking at conferences. Starting small is often the best approach. Coach camps are invaluable as well. These are typically inexpensive 2-day events with a restricted number of attendees. This allows people to really connect. The open discussion and easy interaction are difficult to replicate at large conferences. Coach camps provided me with an opportunity to practice my facilitation and presentation skills. This is also are great option for organizations that are unable to incur the sizeable cost of a conference.
There are times when external training is necessary. Sometimes the training provides insight into territory that your organization is unfamiliar with. Or maybe an individual just wants to learn more on a particular topic. Regardless, this type of training has some similar benefits as conferences. It gets you out of the office and allows you to gain an understanding of the problems or issues that other organizations are seeing. Often, these types of training can lead to certifications which may require self-study after the fact. Certifications are a great way to display your competencies whether it’s visible from a business card or a LinkedIn profile. With over 20 certifications including CSM (Certified Scrum Master); PMI-ACP (Agile Certified Practitioner); SPC (SAFe Program Consultant), it’s the first thing that stands out when most people view my resume. This learning can be invaluable (especially if a competitor is also in attendance). Throughout my career I have benefitted from this type of training because it allowed me to enact my new found knowledge almost immediately. Even though I had only elementary knowledge on certain topics, my peers looked to me as the expert as many chose not to pursue Agile learning but benefitted from my efforts.
3.6 Fearless Learning
When I use the term “fearless,” that is not to imply that being fearful is weak. As I’ve described, there were many times I was fearful. Fearless learning is about overcoming your fears. It forces us to push ahead when the easiest thing to do is to reside in our state of comfort.
As I built up quite a bit of traction in my Agile journey, I began to notice a recurring theme. I realized that even though my employer wasn’t against Agile, they weren’t exactly for it, either. This resulted in limited support as I was looking to further my Agile learning. While my employer had provided some Agile opportunities (or in some cases opportunities where I introduced Agile) they were not focused in that area. Eventually I realized that I needed to find a new employer that had adopted the Agile mindset or become an independent consultant solely focused on providing Agile services (e.g. coaching) to various clients. I chose the latter. I was terrified when I made the decision, but I was fortunate to secure a consulting opportunity soon after I started my company. Working as an independent consultant forced me think about how I could help the client organization as a whole. This meant I would have to become more comfortable addressing matters that were outside of my comfort zone. I decided I needed to communicate (directly) with many people from all levels of the organization. This gave me a good picture of where the organization came from and why decisions were made. It also gave me an idea of where they wanted to be. In fact, one client was so impressed with the information I had pulled together, we co-presented the results at a conference. I was now able to push organizations towards change without being fearful of getting fired from the client and disappointing my boss because I was now the boss. The biggest reward of starting my own company is that it has allowed me to focus on the things that I want to focus on. I’m working towards my vision and not someone else’s.
My most recent revelation has been becoming a trainer. This is definitely not something I would have envisioned at the start of my Agile journey. It just seemed like this was the next logical step for me but there were no guarantees that I would be good at teaching. In fact, teaching the first few courses were a little uneasy. But I persevered and quickly identified areas for improvement that I immediately acted upon. Performing the role of a trainer has allowed me to reinforce my understanding of Agile concepts. It has also identified areas that I needed to allocate more time in order to strengthen my understanding. Whether I’m teaching a private or public class, the opportunity has allowed me to communicate with various organizations that I otherwise would not have had the chance. Even though I’m still getting used to this new role, I do feel it is a good fit for me.
4. BRINGING IT ALL TOGETHER
In summary, the 6 learning areas can be illustrated as follows:
Table 1: Six Key Agile Learning Areas with Examples
Maintaining a commitment to all 6 learning areas can be exhausting. But it’s not that different from maintaining a backlog. You have to prioritize. Utilizing a personal Kanban board can certainly help. Before I adopted a personal Kanban board, I used checklists. Either option works well. To ensure I wasn’t losing sight of my learning goals, I created monthly and annual checklists.
You may notice that the checklist items are not necessarily dedicated to Agile. That’s intentional. I found that I was able to learn about Agile from non-Agile resources. For example, I learned quite a bit about the Agile mindset from Carol Dweck’s book Mindset: The New Psychology of Success, even though it never mentions the word “Agile.” As a result, there are often times where I fulfill the first item on my monthly checklist by reading a psychology magazine.
Also, I decided to quantify each item (e.g. 1). I wanted to make each checklist item achievable, but I also wanted to provide an opportunity to exceed it as well. For instance, reading 1 book per month can be difficult at times but it is fairly achievable. Then there are times where I travel quite a bit and spend a lot of time at the airport and in the confines of airplanes where it provides an opportunity to read more.
5. WHAT I LEARNED
Individual learning is very important but it’s not enough: Eventually, you’ll get frustrated by the lack of support and constant uphill battle of promoting Agile. That is not to imply you have to cover all 6 learning areas. It’s perfectly fine to progress through your entire career only having experienced 2 or 3 learning areas. However, that is only possible if the organizations you’re working with possess strong leadership that fosters a culture of learning.
Everybody learns differently: The 6 learning areas merely provide guidance. How you apply those learning areas is entirely up to the individual. For example, some people prefer to read newspapers and magazines versus books. Others prefer an informal lunch ‘n learn versus a CoP. However, stepping out of your comfort zone and trying something unfamiliar can be a great way to accentuate learning.
Learning requires sacrifice: I’ve never tabulated the amount of time I’ve dedicated to learning Agile. Whatever it is, I’m sure the number of hours is astronomical and at the same time may appear quite minimal compared to others. The honest truth is that the time spent on Agile learning likely takes away from other things in your life you quite enjoy. For some people that means less time with family and friends, infrequent travel, or the inability to pick up a new hobby like playing an instrument. So, the question becomes, is it worth it? In my opinion, the answer is “yes.” And that’s because my Agile learning has now allowed me to do those things more than I could have imagined. In other words, be prepared for short-term sacrifice so you can achieve the long-term gain.
Practicing your learnings in everyday life accelerates learning: This sounds obvious but what may not be obvious is how fast the learning accelerates. Practicing a concept at home and work provides a deeper understanding (and makes it more fun). Your learnings from home will make you better at work and vice versa. I basically plan my personal life on a Kanban board using Zenkit. This has allowed me to identify anomalies at work when I’m reviewing Kanban boards for various teams. I quite often get asked, “How did you see that?”
Ten years ago, I would have never imagined I’d be where I am today. So if I had to do it all over again, I don’t think I would have done anything differently. There were definitely periods of frustration, but perseverance makes you stronger. One of the key experiences that particularly stands out is when I made the decision to become an independent consultant. When I look back at it now, there was actually an underlying (possibly hidden) decision that I subconsciously made. At that moment, I decided that the rest of my career would traverse in the Agile direction “I” wanted to take it.
These 6 learning areas have taken me on a long Agile journey and will continue to do so. In fact, I will likely experience additional learning areas before my career is over and I can’t wait!
REFERENCES
Campbell-Pretty, Em. Tribal Unity: Getting From Teams to Tribes by Creating a One Team Culture. SpiritCast Network Book, 1st Edition, 2016
Gladwell, Malcolm. The Tipping Point: How Little Things Can Make a Big Difference. Brown and Company, 2000
Thomas, Stuart, blog post: “How Google encourages innovation among its employees,” https://engageme.online/google-innovation-employees/
