Agile Principles and Project Management

I attended my PMI chapter meeting last evening. The presentation was about agile principles and project management. Since agile project management is such a hot topic I thought I’d give a quick critique of the presentation and the topic in general.

Let’s start with the things that annoy me about this topic and then get to the good stuff. My biggest complaint is that people who present this topic seem to slam the traditional form of project management. I don’t suggest that the traditional form is fantastic. Like I’ve said, project management has changed over time and continues to evolve, much like the manufacturing processes have changed. I am not sure what the value is to the audience, since most of the audience practices traditional project management it can be a bit offensive. Next up is that there is not context given to the agile principles that they believe can be adapted for traditional project management nor do they mention that some of the principles have been used, to some extent, in traditional project management in the past. There is no mention of the fact that agile requires the principles to work. That being said, the practices that the speaker mentions are good practices for traditional project management.

The two fundamental points that formed the basis of the presentation are that agile represents a more active management approach than traditional project management. I’m not sure I agree. Either I’ve been managing projects incorrectly or counter to the suggested method or that is an agile message that folks who practice agile use to provide the perspective that they are agile. Second, the premise is that agile is meant to help project teams “fail faster” and accentuated four points; closed feedback loop, increased control, a strong and well maintained team structure and identification of issues sooner.

Some principles were omitted and should be mentioned because their supporting concepts differentiate agile software development from traditional delivery. A couple of the principles have to do with the management style and how the team is viewed. First, the team members are considered motivated and should be trusted to do the next right thing and the team members are self-organizing, they are not assigned work as much as they assign themselves work. The second group of principles has to do with the technical aspects of delivery, which are to have rapid continuous delivery of useful working software and to ensure that technical excellence and design are part of the rapid delivery (can’t cut corners). These principles are more difficult to adapt to a traditional project management method, and I believe they deserve some exploration in future posts.

Ride On, Manage On

Read more...

There are two kinds of motorcyclists, ones that have had a mishap (accident, falling) and one that hasn’t had one yet. One thing every new motorcyclist learns is that, at some point in their motorcycling career, they will drop their motorcycle. When I started riding, I knew it was just a matter of time before I fell. The same can be said of project managers. At some point in their career, they will have a project that falls. The extent of the damage to the project and the project manager, just as in the case of motorcyclist and motorcycle, is based on the amount of risk that the person took on for the effort.

Projects aren’t conducted in isolation, which means that the environment will change, sometimes for the good and sometimes, well, in the opposite direction. I haven’t met a project manager yet that has a perfect record of “on time, on budget, with quality delivery” for every project they’ve managed. I have met many project managers that have managed to avert disaster, where the project was not considered a failure, although it wasn’t considered a success either. Project errors, mistakes, miscalculations are part of maturing as a project manager. We have “opportunities” for growth where our best laid plans meet with unforeseen circumstances. These project errors are part of project management.

The trick to being a successful project manager is to manage the project difficulties and avert project disaster. The characteristics of the project managers that have been most successful in their careers have been those that have managed to stay “out of harms’ way”. There are some specific skills that these successful project managers have that have helped them to deliver projects successfully.

First, they know their stakeholders. That is more than identifying the stakeholders and capturing their needs and expectations. They have gone beyond those tasks and are able to identify the significant few, those that require more attention because of their role in the organization, their expertise for the specific project, or their influence. The project manager connects with those specific individuals differently than with the rest of the stakeholders. Obtaining direction, buy-in and support from those stakeholders can make or break the perception of success or failure of a project manager or a project. Since perception is reality, their backing is critical.

Second, they understand risk. It isn’t that they identify risks and perform the risk tasks. They understand the cumulative nature of risk and make specific choices about how to frame a project, present information on a project and strategically manage the project. They have mastered the art of ownership of project risk and are firm regarding the degree of risk that they believe is appropriate for the project they are managing.

Third, they can communicate project information accurately to the right people at the right time. They don’t cry wolf and they don’t cover potential problems. They are transparent in the communication and are not willing to gloss over potential problems and are willing to stop a failing project.

These are not the only reasons a project manager is successful. I would say these are my top 3. Know your stakeholders, know how to manage a risk portfolio and be able to communicate effectively. When you don’t have the right backing and the risk is above tolerable levels it won’t matter how good you are at controlling the other aspects of the project.

Ride On, Manage On

Read more...

Project Systems

One thing I've learned from managing a large number of vastly different projects is that creating the appropriate project system is one of the ways a project manager adds value. The project system is made up of the relationships, methods and tools for the project. The components of the system are what provide the structure for the project. The interdependence of the relationships, methods and tools provide the boundaries inside which the project team can achieve the objectives of the project. Without these components, project teams struggle to know how to work together, which usually contributes to project failure.

Project systems are evolutionary. The reasons for this evolution are rooted in the fact that most projects are designed to make money, to save money, or to avoid spending more money than necessary. It wouldn't be necessary to have any form of project structure except one type if it weren't for money. The newer structures are designed to enhance the projects' ability to deliver value sooner. The project system is a value proposition and there will continue to be growth and evolution to provide value at the earliest possible moment based on the project. Project management will evolve in conjunction with the project systems to continue adding value to project delivery.

Projects aren't conducted in a vacuum. Every organization has multiple active projects at any given time, which suggests that, as project systems evolve, an organization must evolve their program and portfolio management. This dynamic suggests that project managers must be knowledgeable about more than just project management. Project managers must understand how the organization handles the programs and portfolios since the methods used will impact the types of project structures that will work best for an individual project.

The simple truth is that each project is unique, which causes each project system to be selected based on the unique qualities of the project. Which structure to use for a project is determined by the following factors (not a complete list):

The level of experience and competency of the team members

The size and complexity of the project

The maturity of the Project, Program and Portfolio Management

The culture of the organization

The risk tolerance of the customer

The number of stakeholders

When we view projects as systems acting within a portfolio management system it becomes easier to identify the best structure for the project. Employing predictive, adaptive or extreme methods to achieve value quickly is only possible by considering the entire system. Creating the right project system allows team members to work at the highest level possible, allows adaptation to change occur, and support the customer in the right way. No method is the best method for all projects, there is a "good, better, best" selection that, when made, enables success.

Ride On, Manage On

Read more...

Agile Project Management Experiences

I first started hearing about agile software development about 5 years ago. The company was working on a project designed to develop a web based incident reporting system. The lead technical team, new to the organization, was experienced in agile delivery wanted to use agile for the project. The project management staff was trained in traditional or classic project management and the organization was used to the language, tools and techniques associated with traditional project management. Agile software development wasn't a movement in the company, hadn't been introduced as the next great thing, the project wasn't even tagged as an agile project. After some debate at the senior management level it was determined that agile delivery was the best method for this project.

The project used paired programming, test driven development, iterations, regular builds and many other benchmarks that "make" a project agile. A project manager who had no agile delivery experience was assigned to the effort. This is where some issues began to be noticed within the organization. The project manager used the predictive, plan based management method they were familiar with rather than adapting to agile concepts. The project was going well based on the clients perspective. The client was able to dictate the next two weeks worth of project work, was heavily involved in the development of the software, and the software changed on a bi-weekly basis in their favor. Everything that was being requested by the client was part of the scope of the project. There were problems though, and the project manager was under the gun to answer the concerns.

When the question of "when will it be done" came up, the project manager wasn't armed with the language of agile or the metrics and wasn't able to present information to the stakeholders in a meaningful way. The stakeholders that were struggling with this new form of delivery were not the customers of the software. The stakeholders that were concerned were those that needed the resources next. The software had to be "done" at a point in time so that other software development could commence.

It seems to me that the example above could be any company. Company's are looking for THE way to get to market quickly, THE way to get software completed with less cost and THE way to maintain a competitive advantage. This isn't new, company's have been looking for that since the first company started. What is different today is that there is more than one acceptable way to manage a project. That is a good thing. There are a few things that must be in place to allow projects to work using different methods. First, the methods have to be defined and agreed upon. Notice, I didn't say create mountains of documentation. They must be defined so that team members know what is going on. Second, there has to be a reason to use one method instead of the other. Third, metrics need to be in place to support both the metrics and the communication of the status of the effort. Lastly, there should be one portfolio of projects that all projects report information to so that the organization understands how the money is being spent. As a project manager it is important that the portfolio view exists, otherwise I don't know when I'm going to get what I need to be successful.

Ride On, Manage On.

Read more...

Now Project Management

The Motorcycle Safety Foundation Basic Rider Course is divided into classroom and hands on training. The purpose of the course is to help motorcyclists understand the risks of riding, the fundamentals of a motorcycle, and how to ride. I was sitting in the class room portion of the course and the instructor was discussing the 2 second, 4 second and 12 second rule and how it helps keep a motorcyclist out of harms way. The 2 second view helps avoid immediate dangers, the 4 second view for is for preparing for things that could occur and the 12 second view is for fewer pressing concerns, although critical to view traffic patterns as possible warning signs. The course then uses a video to help accentuate the point. Viewing the video is like playing the game "how much can you see given 2 or 3 seconds to look"? After we described what we'd seen they asked us to explain what actions we would take based on the what was happening in the video. It was a good way to think through hazards and determine the actions needed at the given moment to maneuver safely through to safety.

I was managing a project when my lead architect came to me with an issue. We sat down and discussed the problem to determine what our next steps should be and decided that, based on the criticality and impact of the issue, we should move into the problem solving process we'd outlined at the beginning of the project. Long story short, we implemented a solution based on the best alternative possible. After that problem was solved I pulled the team together to gather leasons learned. We covered the standard leasons learned and discussed how we handled this particular issue. I then moved into a leasons learned about the timing of when this problem was identified. The team had mentioned that this issue should have been identified as a risk earlier so I thought it important to uncover the reason for this apparant miss.

One of the things a project manager needs to balance is the past, the present and the future. This lesson learned covered all three. We retrospectively reviewed the problems' path within the project. We discussed the apparent miss when gathering risks, the manner in which the problem was handled when it became an immediate issue and how we could prevent this type of "fire" next time. "NOW" Project Management doesn't avoid the past and nor avoid preparing for the future. It emphasizes what needs to be done "Now", in this moment, at this time. Whether we are looking at 2 seconds, 4 seconds or 12 seconds, there is something we should do NOW for all of these elements. Whether it is simply to put something on a watch list, to do an immediate corrective action or to put together a plan of action, there is something in this moment that should be done. The most important thing to remember is that, whatever we did yesterday is complete and we have new information. When we stay in the present moment we have both a changed past and a changed future. Nothing about our present is stagnant.

When we stay in the Now, in the present, we have a clearer picture of what is going on in our project, we have a better understanding of the relationships between what has happened and what may happen, and we have a greater appreciation for the project dynamics. The great thing about having a project team is the opportunity for perspectives outside of our own to look at the project landscape and be able to view the past and the future differently. Making sure to review todays' information such as tasks, decisions, risks, issues, assumptions and constraints is important. None of the activities associated with managing a project are a "once and done" endeavor, hence checklists can be deceiving. It would be easy to manage a project if nothing changed, if our predictions all came true and our plans were always correct and the past always supported the future. That isn't the case.

Managing projects in the Now is important for the stakeholders. Providing a lens into the current state of a project, not a predicted past state or a hoped for future state, a present state. When we speak in the language of "if" we are not in the present state. The language of "if" is one of conjecture and hope. The language of "Now" can seem impersonal, cold. The language of "Now" is factual in nature, like a snap shot. It is a picture with a caption of what the project team sees and what it is doing today to prepare for what it sees. That is what "Now Project Management" is designed to do for the project. Keep the language to what is being done today, not about what will be done "if" something occurs. Don't misunderstand, contingency plans are important, more important though is that a contingency plan has been put in place today. The question that is most important in a project is "What must we do today". What the plan is is secondary to having a plan. "Now Project Management", stay in today and answer: What did the project complete yesterday? How did that affect the project tomorrow (2 second, 4 second, 12 second view)? What needs to be done today as a result?

Ride On, Manage On

Read more...