A few years ago when I was in management, it was my responsibility to look for ways for teams to be more effective in implementing and completing projects. While we were following industry best practices as recommended by governing bodies such as the Project Management Institute (PMI) and the Software Engineering Institute (SEI), we still had too many projects that were considered failures or took too long to provide value back to the business. I quickly discovered Agile software development as a possible solution by reading several books and attending local user groups listening to those that had tried the practices. While I didn’t understand everything I needed to know about the practices, I was eager to get started and see some of the benefits that have been obtained by other teams that have adopted Agile.
However, we were really struggling with the adoption of these practices. We lacked the experience needed to implement the practices successfully and didn’t know how and where to make improvements. We also had many people resistant over the changes because they didn’t see the value and long term vision of why these new practices should be adopted. Like many companies I have seen who take this approach, many had decided after some time that Agile cannot work in “our organization” and was only good in “theory and not in practice”. They were ready to call it a failure and go back to what they were comfortable with. However, I know we still had the same problems that have plagued many organizations – projects were taking too long, deliverables didn’t meet end user expectations, and we cut corners on quality to avoid going over budget and missing deadlines dictated by the business. I wasn’t ready to give up quite yet, but knew something was missing in our approach.
Needing help, I sought some advice from those outside of the organization that had been successful in applying Agile. What I discovered was we were too focused on HOW to apply the practices without understand WHY we were using them. We needed some guidelines to help us understand why we were implementing practices to better understand where we can make improvements and still achieve the anticipated results. As I work with teams and organizations new to Agile, I find that not many have thought about implementing Agile this way. They figure they just need a process methodology, a tool, and a mandate from upper management that we are going “Agile” and everything should come together. That will put you quickly on the road to failure.
Teams need to understand the overarching goals, values and principles that will guide them in their adoption and constant improvement of valuable Agile practices. Fortunately, the Agile Manifesto (www.agilemanifesto.org) provides these elements. Let’s explore the Manifesto in more detail. The goal is simply stated, “We are uncovering better ways of developing software by doing it and helping others do it.” On its own, the goal is too vague without having more clarification through values and principles. Let’s read on, “Through this work we come to value: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.” Now, we have more of a framework around four critical areas: Communication, Delivery, Collaboration and Learning.
While I had read the Agile Manifesto early on in my learning about Agile, I had not realized that there was another part of the Manifesto that usually was not contained in the books and other resources. There are twelve principles (on right, with more details at http://agilemanifesto.org/principles.html) that were also developed to help teams understand the why’s of implementing the various practices that have been developed. Given that Agile is considered an empirical process for continual learning, those responsible for developing the Agile Manifesto wanted to make sure people had some specific guidelines in how they implement, inspect and adapt the practices in their organization. While I have seen specific practices change over the years, I find that these principles have endured the test of time and can be applied against any process, policy, activity, artifact, or tool to determine if the expected outcomes will be achieved.
Looking back, I knew we were at a critical point and could have made the (easy) decision to go back to our old ways or create a new methodology that would eventually been a failure. We would not have been successful in our adoption of Agile had it not been for seeking outside help from a person who was experienced and could help us focus on results as guided by unchanging goals, values and principles. Now, when I train and coach teams that are adopting Agile I start with introducing them to the Agile Manifesto and encourage them to put them up in their cubicles or in their team area. As they try to adapt Agile to fit their organization, they can use the Manifesto as a test to see if the improvement will get the anticipated results and make necessary changes if the test fails. If you are unsure where to go next, seek help from an outside coach as I did that can help you get on the right path and gets the results you are looking for.