I often find my self talking to people about agile outside of a formal presentation setting, usually in response to the infamous "so what do you do?" question at fundraiser dinners or cocktail parties. Often, these are people who are not in the software business, so the inevitable question comes up: "What is agile really, and can it apply outside the world of software development?" The answer to the second part of the question is an unequivocal yes. In fact one of the agile methodologies, Scrum, is heavily influenced by the principles and practices of the Toyota Production System.
To answer the first part of that question—well that requires a little more detail, and it gives me a chance to flesh out my view of good principles influenced by agile, my Words to Lead By:
I thought it was time to elaborate on what I really mean by these statements, and to do it in general terms not directly related to software development projects so I can demonstrate their wide applicability.
The concept of collaboration in this context actually has two meanings. One is obviously the ability for the team to work together as effectively as possible. This is probably the one aspect of all projects, and really all group endeavors, that can always be improved. The key here is that where possible all barriers that prohibit effective communication are removed from the team environment.
The more subtle but equally important aspect of collaboration is that the team members who are actually doing the core work of the project are the ones doing the planning, decision making and status reporting. This is a shift from the traditional view of projects, where the thought is that a project leader should be responsible for those types of tasks. Why should the team be responsible for those activities? Because they are the ones who are most familiar with the work and are best positioned to make spot decisions and determine what really needs to be done. This also means that members of the team volunteer for items to work on, as opposed to having them assigned.
This aspect of the Words to Lead by should be applied on every project regardless of methodology and approach, yet this is probably the one that project teams have the most difficulty with because of old command and control habits on the part of project managers and the tendency of teams to look to someone else to tell them what to do, even though they don't often appreciate being given assignments. Changing course on this aspect is often a matter of going against human nature.
When trying to describe iterations in a non-software context, I decided to see what dictionary.com had to say. Interestingly enough, one of the synonyms for iterate is rehearse. If you think about it, that is what iterations are really all about. Whether you are building a software application feature by feature, or building several pre production models of vehicles to try out the assembly process and produce vehicles for the test track, you are rehearsing your approach and your design decisions.
Iteration is important because it gives teams an opportunity to propose an approach to how something will work and try it out, without building so much that they have wasted a lot of work when they find out they made a suboptimal decision.
The key to iterations is producing a subset of the final product or building a full sample of the product in each iteration, meaning you have something concrete to look at, try out, and experiment with to understand the results that the current approach is providing. You want to have a working product at the end of an iteration, because that is the easiest format from which to get feedback from customers or stakeholders.
This statement describes the leadership style I think is most appropriate for most project teams—that of servant leadership. The project leader really needs to serve the team in terms of providing them the environment they need in order to be successful and removing obstacles that are preventing the team from being effective as they can be.
This also means that a project leader should not use a command/control approach where they are telling the team members what to do. Rather, the project lead should act as a facilitator to the teams to help them make informed decisions and continue to follow the agreed upon process effectively. I discussed this concept in a little more detail in an earlier article, "Do you need different Project Management skills for agile projects?"
The term "Best Practice" is used quite frequently to describe techniques or processes that have been successful for one project or organization and are being copied by other project teams or organizations. Unfortunately, what works great in one project may not work as well in other situations. There are usually many environmental factors that play a large role in how effective a practice is on a given project. Because of this, I usually prefer to use the term appropriate practices or good practices to emphasize the fact that there really are no best practices across all projects.
Teams need to consider context when choosing which processes, practices, and techniques they use so they can be sure they are doing the things that will make them successful and are not doing the things that they do not need to do. In fact when it comes down to it, perhaps considering context is the only real best practice around.
A key point that may not be immediately obvious is that project teams need to determine what practices, processes, and techniques they are going to employ during a project, and be willing to change those practices as they learn more throughout the life of the project. Project teams often work within an organizationally defined process they believe they must follow to the letter, many times to the detriment of the project. Usually if those project teams examine reality a little bit, they will find they have some latitude as to what practices they adopt from the organizational method.
Once teams have decided what they want to do, they then must find ways to make sure that they are doing those things as best as they can. When teams follow the advice of considering context and doing things that are barely sufficient (see Deliver Value, below), they often remove controls imposed by organization wide methodologies. These controls are typically meant to protect team members from themselves by prescribing steps down to the nth detail. To account for this, team members must strive to have the self-discipline to perform their work to the best of their ability. Chances are if the rest of these ideas are followed, that will probably happen; the team will find the project more rewarding because they are able to work well with other team members, they are only doing the things which are really important, they are given responsibility and authority to do what they need to do to succeed, and they can tie what they are doing to value added to the business.
This idea captures the need for the project team to continuously learn from their experiences, and to accept and create change to improve their approach and the end result of the project. Projects often last longer than a couple of months. During that time, business conditions, team member understanding of the purpose of the project, and the environment surrounding the project will all grow and change. The team should seek to use that change to their advantage to make sure the end result of the project truly meets the needs of the customer at the time the result is delivered, not what the perceived needs of the customer were when the project started.
Project teams have long done "post mortems" or lessons learned sessions where the team gathers together at the end of the project to talk about what happened—usually the negative aspects—in the hopes that they can remember to do better next time. If that approach is considered a good practice, wouldn't it make sense to do the same thing during a project when the team still has time to make changes and impact the outcome? This is the idea behind retrospectives, which provide teams with a mechanism to discuss what has transpired on the project to date—both things the team did well and opportunities for improvement—and decide what course corrections need to be made.
All of the above ideas lead to this final one. Delivering value is realized in two ways on projects: doing only the things on the project that add value, and measuring the success of the project based on the value delivered. Projects can accumulate many to do's that seemed like good ideas at the time, but end up not being essential to the ultimate goal of the project. Project teams often hang on to these tasks because either the organizational methodology mandates them or because "it's what we have always done." It seems to be a fact of project life that it is easier to add tasks to a project than take things away. For that very reason, teams starting a new project should first determine the activities that are absolutely essential for the success of the project and then do only those. Over the course of the project, after some reflection, they may realize that they need to add a few practices to overcome challenges they experienced. This is fine, as long as the team is also willing to let go of practices that they determine they no longer need.
That focus on doing only the things that are necessary will help the project team with the second aspect of delivering value—measuring the success of the project based on the value delivered. This will seem like quite a departure for people who have focused on the "iron triangle," where the success of a project is based on staying within budget, on time, and within defined scope. But in fact, a focus on value delivered takes those into consideration. When project teams define the value delivered by a project in terms of a model which identifies the conditions under which a project will deliver value, those conditions will more often than not include the constraints of time, budget and scope, but in a context that is much more meaningful for the project team than some arbitrary metrics identified by an executive sponsor because it looks good on their annual plan.
So what is agile really? It is a mindset for effectively completing projects. The specific practices don't matter as much as why they are implemented: to engender the principles that I described above. Often when I am done talking about agile in this manner, people will say, "Well gee, that is pretty much common sense." Well, yes it is, but unfortunately it is not necessarily common practice. I believe that's one reason the term agile was coined in the first place. People needed a name to associate with this collection of good principles that would make project work more effective and fulfilling. It's my hope that one day the word agile won't be needed as part of a title or an adjective when describing project work because it will be commonly accepted as a good way of getting projects done. Until that time, I'll at least have something to talk about at a fundraiser.
©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us Site Map View current sponsorship opportunities (PDF)
Contact us for more information or e-mail firstname.lastname@example.org