In process improvement we look for the root cause of why things go wrong. But what about why they are successful?
When I hear the question of why a team should switch to an Agile Methodology, I hear answers like "you get more done" or "it's easier to manage" or, my all-time favorite, "it's cheaper." If I ask myself why any of these are true, it makes me start to wonder why other traditional methodologies would not have the same outcome.
I spent the last year providing Agile training to Product Owners and Business Analysts and I covered a study conducted by Version One identifying reasons teams chose to adopt agile and the resulting improvements seen. Improving employee morale was considered a reason for adopting agile in only 29% of the cases, but was found to have improved 81% of the time. The majority of teams choosing to adopt agile received a surprise benefit.
Are you surprised as well?
In one of my first trainings, a student asked me what I enjoyed most about Agile. I had to think on it. The standard answers were not why I love working in Agile. It's because it is fun.
I actually enjoy coming to work. Even in a large corporation, I see the needle move, I see the team proud of their work, I see the team bond and collaborate to innovate new ideas, I see team members step up and offer solutions, not problems, I see customers get excited that their feedback is not only heard, but implemented. It is fun to be successful.
In Agile we teach the five Why's, which is with any issue ask "why" five times and you will discover the root cause. In this case, I instead asked myself "Why is it fun?" and "Why is it so successful?" It brought me back to a time before I knew what Agile was.
I had a team of five Business Analysts, we were responsible for a new product offering and were given all the money and people we needed. You would think the rest would be easy, right? Well this was not an easy product and as we peeled back the layers, we found more and more roadblocks. Even better, this product had already been sold to major clients. We had to find a way to make it work and make it work fast.
In the beginning my team was happy. They came to work every day excited to see each other, had common skill sets, worked well together and received a lot of praise from our customer teams. As their manager, I was proud of our performance. As time progressed and the project became more difficult, I began hearing more and more complaints from those we interacted with. We were late on deliverables, we didn't reply to emails and we made mistakes in presentations. One morning on my way in, I was thinking it over and became increasingly more frustrated. We were better than this, and quite frankly, we needed to get our act together.
That morning I called a team meeting. My blood was boiling and I was ready to lecture the team on expectations, until they arrived and I saw their faces. They weren't just tired - they were exhausted.
I took a deep breath and managed to dissolve away my adrenaline. I looked at them and asked, "Are you still able to do your best work?" They each shook their head no.
After asking why, I heard the same issues that most teams have: not enough time to get it all done, I have no idea what I should work on first, I get distracted with all the new requests regardless of how small they are.
I thought on my feet. I had never been in this situation and not knowing what else to do, I asked the team to grab a marker and write on the whiteboard everything they had on their plate, no matter how big or small. The lists were quite large. I realized the mountain they faced each day when they walked in, as well as the defeat they must feel when they headed home.
I walked up to the board and picked one priority for each person. They were not to work on anything else until that one thing was done. We kept picking more until we had a day's worth of items.
We set up reoccurring meetings each morning where we would evaluate the board: add anything new, erase anything completed and pick a new list of priorities for the day. Anything not picked as a priority that day became my job to work with the stakeholders to decide when it needed to become one.
When the team walked out of the room the first day, they seemed hopeful. Not happy, but hopeful. By the end of the week they were new people. During the day I would see them go into the room to cross things off, they would add new items and they would swing by my desk to ask what their next priority should be.
They were a team again. And they rocked! We ended up carrying this methodology throughout the project. At the end of the year we were even given a team award through the nomination of our own peers. We didn't understand how we were even nominated, as the project was so difficult and had so many pitfalls. When the nominations were read during the awards ceremony I realized exactly why. Things were said like "they remained a team through the worst of it," "they showed up every day willing to take on what's next," "they never pointed fingers, they just helped when they saw something go wrong," "they made the impossible happen."
We launched that product. I will admit it wasn't perfect, but we launched it. A Wall Street analyst wrote how it was a game changer for the industry. To this day, I see advertisements for it and although that project is long over, I remember the team like it was yesterday.
So what does this have to do with Agile?
We created backlogs. We picked priorities. We gave the team focus.
We allowed the business to change their mind. We added new things to the list. We worked on what was most valuable.
We met every morning. We ensured the team did not have any blockers. We made sure they were able to do their job.
We worked as a team. And they had a servant leader.
It was not the exact cadence of a Scrum or Kanban methodology, but it was the true essence of what Agile intends to provide a team. It gave the team focus. It gave them a sense of accomplishment. It allowed the business to have new priorities and not wreak havoc on the project. It brought the team together and helped them perform at their highest potential.
It improved morale.
It created engaged employees.
It created an outstanding product.
And that is the root cause of why Agile is successful.
Version One: State of Agile Survey, 10th Annual
About the Author
Nicole is an IT Management Consultant at CapTech, where she is an experienced Agile Project Manager / Business Analyst with proficiency in strategizing and implementing enterprise and global business solutions. During her career, she has leveraged Agile mythologies, leading transitions from Waterfall to Agile by recommending resource structures and an iterative approach to business objectives. She has partnered with several business representatives at all levels and IT teams to assess, initiate, and refine appropriate solutions and build agile plans for a variety of industries such as Food Safety, finances, telecommunications.