Managing Your Backlog

Life is full of difficult decisions and sometimes we have to make tradeoffs. The best thing you can do is to get your backlog in priority order and work from the top. Establishing a stable velocity is key to understanding how much you can get done. Sometimes you are fortunate and the list is easier than it looks. If you finish early, you can always go back for more.

Here is a link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/05/managing-your-b.html

Subscribe to this blog

Subscribe to Leading Agile

Trust Falling

For the past 10 years I've been involved with a Boy Scout high adventure program called Project COPE. The goals of COPE are to develop skills in communication, planning, teamwork, trust, leadership, decision making, problem solving, and self-esteem. The program is developed around a series of initiative games, more complicated low ropes elements, and ultimately a full blown high adventure course that puts you some 30 to 40 feet up in the trees.

This past weekend I took 17 teenagers and 4 adults out for a weekend of team building in the woods. You never know quite what to expect as every group is different. You can count on each weekend to be very powerful, and if you are open, you'll learn a lot about your team, and about yourself, in the process. If you are interested in learning more about the program, you can click here for some additional information.

This weekend did not disappoint. We started off with rain Friday night, but by mid-day on Saturday, the weather was beautiful. By lunch we had a group of strangers learning to work together, communicating, and beginning to coalesce into a team. We played skin the snake and marshmallow river. We learned to safely catch a falling team member, went on a blindfolded walk through the woods, and discovered how to walk on a high tension wire using pivot points.

By the end of the first day, the team was ready for the trust fall. The trust fall begins on a platform about 5 feet off the ground. The idea is that you fall backwards into the waiting arms of your team members, who safely catch you, and gently lower you to the ground. For many, this level of trust is very difficult and doing the event is a very powerful and emotional experience.

I was the facilitator of this event and as such, the first to fall. Aside from reminding them about proper falling technique, I want to demonstrate my trust in them, and show them I believe in their ability to catch me. It always helps getting the less enthusiastic participants over their fear when I go first… well… except Saturday. You see, the team said they were ready for my fall, but in reality, they didn't know quite what to expect.

They dropped me.

They broke my fall a little, but I basically went through their arms and hit the ground. I wasn't injured too badly, a little bruised maybe, but now I needed to quickly figure out what to do. In ten years of doing trust falls, never once had I been dropped. What now? I had a team that had just spent an entire day learning how to trust each other. Our whole event was at risk.

I got up, dusted myself off, and began to debrief what just happened. The team acknowledged they had not been ready. I acknowledged that I had not done a good job making sure they were clear what needed to happen and the potential 'impact' of failure. We talked about what needed to happen differently next time. Everyone was on board and ready to try again. We recommitted as a team.

I was a little sore and decided to let one of my instructors go next. I guess I wasn't ready to trust again so quickly. We ended up getting everyone to do the fall and the team felt good they had recovered. Once everyone was through, they asked me to fall again. I was a little reluctant because once trust is broken it is difficult to get it back. As their leader, I needed to repair the relationship and show them that I was willing to give them a second chance, so I fell.

They caught me.

I asked them at the final debrief why it was so important for me to fall a second time. They said that while it was important for them to trust each other, they wanted to earn back my trust. As their leader, I was part of the team. It was a good weekend.

Link to my post on Agile Chronicles:

http://blog.versionone.net/blog/2008/04/trust-falling.html

Subscribe to this blog

Subscribe to Leading Agile

The Message or the Messenger?

Sometimes we need to separate the message from the messenger. Whether we are talking about religion and politics or project management, there is often a disconnect between the message of the organization and the practice of the people in the organization.

Somehow when people get involved, the purity of the message is subordinated to getting stuff done.

We certainly see this in the Agile community. As people try to implement the principles, values, and practices they are forced to make compromises that sometimes don't feel very Agile. People on the outside will often even claim that Agile doesn't work because their particular implementation of Agile did not work. Was that failure because of Agile or because of the myriad of compromises we made along the way?

In all fairness, I think traditional methods suffer from this same disconnect between the message and the messenger. I can't find anywhere in the PMBOK where it says you have to do all the planning up front, but in practice, that is what often happens. Likewise, there is nowhere in that document that says you should not respond to change or adapt your plan, but again, that is how traditional methods are often implemented.

Is that the message or the messenger? It is inarguable that traditional methods lean more toward predictive project control and Agile methods lean more toward adaptation. In practice though, should we hold PMI accountable for advocating rigid up-front project planning? If so, we need to hold Agile responsible for advocating no project control and ad-hoc coding practices. We need to separate the message from the messenger.

Here is my take… you can run a software project using traditional methods. You can even run a highly uncertain project using traditional methods. You could use rolling wave planning and progressive elaboration. You could do most of the design up front and create a nice big Gantt chart for your project stakeholders. As we begin to build and learn more about the product, just document your changes, assess the impact to the triple constraints, and get stakeholder sign-off.

Send the team off to update their design documentation, recode the application, and retest anything that was impacted. Clearly if the change was approved, you have the additional time and budget to do all the work necessary to accommodate the change. If you dig deep enough into the PMBOK, you will find that everything you need is right there. You could even make the case that if you are not adapting your project and managing change, you are not responsibly managing your project.

So if the traditional processes have everything we need to support a highly adaptive project, why do we want to do so much planning up front? Why do we become so resistant to change?

Cost and time to market.

Traditional project management processes are heavy and slow. They make our products more expensive and take longer to build. Most of us are not willing to invest in the full adaptive capability of these methodologies, therefore, we try to take shortcuts. We believe that if we do our planning up front, and work to eliminate change, we can keep these costs in check. The root of this problem isn't that PMI processes don't accommodate change, they don't give us an INEXPENSIVE way to accommodate change.

As companies, we need to decide if we really have a strong enough business driver to use these heavyweight methodologies. What does your company value more: process control or cost and time to market? If you NEED this much structure and control, and I am sure that some of you do, by all means, leverage the full capability of the PMI planning processes and adapt through change management.

If you need to get product to market quick and inexpensively, because you know if you don't, your competitors will, you need something else. Agile methods are that something else. Don't pay the price of methodology unless it is absolutely necessary. Ignorance of another way is no excuse.

Subscribe to this blog

Subscribe to Leading Agile

Building Projects Around Motivated Individuals

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." - The Agile Manifesto

This is the one principle behind the Agile Manifesto that keeps me up at night. It’s the first part, the one about building projects around motivated individuals that has me worried. It is probably the single most important factor for a successful Agile team, and the one that is the most difficult for a project manager to really influence.

When I was introduced to Agile a few years back, that was the first thing that caught my attention. I was amazed at how dependent these lightweight methodologies were on the quality of the people on the team. For Agile to work, you really need to select your team members carefully and, to quote the Manifesto, give them the environment and support they need… to get the job done.

But here's the catch… many of us don't get the opportunity to hire our people or even pick our team. That is decided for us before we are handed the project.

And that is why this principle worries me. As companies try to realize the benefits of Agile, they are going to do it with their existing people. Most companies, especially the big ones, are going to have a mix of talents and people that are motivated in different ways. Can we assume that by creating an Agile environment, empowering the team, and encouraging them to self-organize that motivation will necessarily follow?

Don't we need motivated people first?

I sincerely believe that creating an environment where people can be successful will have a wonderful impact on attitudes and bring out the best in folks. Just be aware that Agile is not going to solve any of your personnel problems. It will, however, bring these issues to the surface so that they can be dealt with quickly. As managers we need to do everything we can to support the team and help them be successful.

Sometimes that means helping find new team members.

Link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/04/building-projec.html

Subscribe to this blog

Subscribe to Leading Agile

What About Me?

We've spent the better part of the past few decades building software organizations around individuals with very specialized skillsets. We have people that do the analysis and design, others that do the coding, another group to do the testing, and yet another to do the doc.

We have a specialized group of people to manage the people with the specialized skillsets and to manage the complex interdependencies all this specialization creates. We have project managers, and program managers, configuration managers, deployment managers, and release managers.

Agile software development basically calls for two roles… the product owner and the team. Okay… Scrum has three… product owner, team member, and ScrumMaster. As agile methods become mainstream we had better understand what we plan to do with everyone else.

Specialized skills are not required on the project all of the time. Specialization requires us to understand when folks are needed and when they'll be free. Answering these questions leads us down the path of predictive project planning and complex portfolio models to manage the interdependencies.

Eventually we start thinking more about matrices and less about teams. If we are truly committed to the idea that great teams can deliver more than a collection of talented individuals, specialization presents a real problem.

Our teams needs all the skills required to deliver working software. In an ideal world we have people that are capable of performing in more than one role. This flexibility allows the team to adjust to the changing needs of the project. Less specialization leads to less constraints, and therefore, less complexity and faster delivery.

Traditional software teams need to address this issue head-on as they consider adopting agile methods. Business analysts, quality testers, and technical writers should be full time members of the development team. Team members should be encouraged to diversify their skillsets so they can help in other areas as necessary.

Do we know what is all of this going to mean for the individual, their development plans, and their career path? If not, we owe it to our people to figure it out.

Some team members will want to stay specialists. Often, what we do becomes part of who we are and change can be uncomfortable. Like any kind of organizational change, this change needs to be managed. We need to shepherd people through the transition, get them the tools they will need to be successful, and encourage them along the way. Some will decide agile is not for them and leave in spite of your best efforts. Wish them well.

We must be intentional about helping everyone make the transition to agile, otherwise we will create a vocal group of detractors that will oppose our efforts to lead change. Let's define the path, point the way, and hope everyone is willing to come along for the ride.

Link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/04/what-about-me.html

Subscribe to this blog

Subscribe to Leading Agile

Inverting the Iron Triangle

I'm curious. Do we all agree that you cannot predetermine the time, cost, and scope of a project and have any hope of being successful? Is it not an axiom of project management that you can fix any two of the constraints but the third has to be variable? Up until recently I had always assumed this was the first law of project physics, the one rule that could not be broken. For some reason I thought that everyone understood this concept.

It is amazing to me how often I find myself talking to people about the triple constraints of project management. I am usually off talking to a group about Agile Project Management when someone raises their hand and asks THE QUESTION:

How does this work on my project where time, cost, and scope are all fixed?

The simple answer is this… it doesn't. The reality is that no project management methodology works when you try to lock all three of the constraints. If this is really true, why is it that Project Managers are constantly asked to manage projects with all three constraints determined in advance? As project managers, why are we so willing to go along when we know we're on a path to failure.

I want everyone to know that I totally understand the desire to have it all figured out up front. It is incredibly appealing to think that we can do enough due diligence and planning such that all three constraints become perfectly clear and manageable. The reality is that it just doesn't work that way. Claiming that this is our reality does not make it so.

Project Managers are in a tough spot. When you have a team of execs that are convinced we can plan our way into certainty, it is very difficult to be the person that raises the flag. Being the guy that draws attention to the elephant in the room is not a formula for career advancement. Put your head down, do the best you can, and hope for the best. Maybe we'll get lucky.

The data is showing us that more often than not... we don't get lucky.

If we are willing to accept the reality of the triple constraints, maybe we can begin to have a reasonable discussion about the kinds of decisions we are making about our projects. Let's talk honestly about what is really flexible and what is not. If we have no room to adjust the plan, what does that mean about the risk to our initiative?

When considering Agile methods, there is a fundamental shift in what we are choosing to assume about our project constraints.

Traditional project management usually starts with a discussion of scope, as in "what's the scope of the project?" From there we estimate the amount of work required to deliver the scope, set the project budget and resources, and determine the timeline. If your lucky, you get some room to negotiate on the front side. More often than not, the discussion ends with someone telling you to get it all done by next Tuesday. Even with room to negotiate, the goal is to lock the constraints and get moving.

Agile Project Management starts with a discussion of time to market and cost, as in "when do we need to get a working product to market and how much are we willing to invest." From there we begin the process of estimating how much scope we think can fit into the window. That estimate is not a fixed commitment. We started with the assumption we wanted to fix time and cost. Scope has to be negotiable.

There are implications to taking this approach. We'll need to look at how we structure contracts, how we forecast revenue, and how we make commitments to our customers. When we plan our portfolios, we have to ask if we can realize sufficient ROI - understanding we might not get every feature we originally hoped for. This is what is means to REALLY manage our projects.

Dealing with reality is not always easy. Agile is not a silver bullet. Pretending is not an answer.

For an interesting metaphor about dealing with uncertainty, take a look at Brian Sondergaard's post on Progressive Refinement of Estimates:
http://blog.softwarearchitecture.com/2008/03/progressive-refinement-of-estimates-aka.html

Link to my post on Agile Chronicles:

http://blog.versionone.net/blog/2008/04/what-about-me.html

Subscribe to this blog

Subscribe to Leading Agile

Assumptions are Made to be Validated

"Every project is conceived and developed based on a set of hypotheses, scenarios, or assumptions. Assumptions analysis is a tool that explores the validity of assumptions as they apply to a project. It identifies risks to the project from inaccuracy, inconsistency, or incompleteness of assumptions." - A Guide to the Project Management Body of Knowledge, Third Edition

Making assumptions is essential in project management. Assumptions simplify our understanding of the problem domain and allow us to move forward in the face of uncertainty. Without the ability to make assumptions, our projects would become paralyzed, unable to deliver the value for which they were created.

The success of our projects is largely determined by the quality of our assumptions. Therefore, by making assumptions on our projects, we are accepting some degree of risk that our assumptions could be wrong. Anytime we assume risk, we need to understand the probability the risk will be realized and it's potential cost to our project. In other words, it is not enough to make assumptions, we need to understand the risks associated with those assumptions, and have a plan should they prove invalid.

Systematic and thorough validation of our project assumptions is the foundation of good project management.

Traditional project management (by that I mean project management as prescribed by the PMI, documented in the PMBOK, and certified through the PMP) makes one key assumption that no one seems to want to address. We routinely assume that our projects are predictable. We assume that with enough planning, with enough forethought, that we can come up with a strategy that will hold through the life of the project.

While I am certain there are some project domains where this assumption holds true, I am equally certain there are many domains where it does not. As project managers, we owe it to our stakeholders to thoroughly assess the likelihood that this assumption is valid and have a mitigation strategy in place if it is not.

If we operate in an environment where market needs change, requirements change, technologies change, and individual performance can vary exponentially; spending effort trying to create a static project plan is wishful thinking. It is just not good project management. We need a mitigation strategy, we need an alternate approach to deliver our projects in the face of overwhelming uncertainty.

Agile methods give us a way of handling projects when the assumptions about predictability just don’t hold. Agile methods give us a way of delivering the most project value, in the least amount of time, with the least investment possible. Agile methods represent a risk mitigation strategy for when our fundamental assumptions about project management no longer prove valid.

Let's apply good project management technique, validate our assumptions, and work to mitigate our risks. Don't be afraid to challenge the assumptions behind our understanding of PM best practice. The assumptions you fail to consider are the most likely to cause you problems in the end.

Click here for my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/04/assumptions-are.html

Subscribe to this blog

Subscribe to Leading Agile

One Team

Why is teamwork such an important part of the agile value system?

As people work together over time they learn each other's abilities and communication styles. They learn how to interact with each other in ways that are more productive. Teams develop a culture and establish norms that allow for very efficient communication. They learn to leverage each other's strengths. Over time, this allows a team to establish predictable throughput and a regular pattern of delivery.

We often underestimate what it takes to bring people into relationship with each other. We seem to think that we can matrix people into teams and expect them to start performing right away. We seem to discount the fact that teams need time to form and get to know each other before they can be productive. We overlook personality and chemistry between team members and expect everyone to operate as if they've worked together for years.

The belief that we can breakdown and reform teams on the fly is a belief in local optimization. It is a belief that if we optimize the abilities of the individual through specialization and optimize the process through definition of best practice, people become interchangeable. Aside from the interpersonal issues we've just discussed, this has led our industry toward an ever increasing level of resource management, project management, and portfolio management complexity.

Our challenge is that we focus too much of our limited time and energy managing complex resource interdependencies rather than solving our real business problems. Simplifying means we focus less on developing individual specialties and more on the overall capability of the team. To optimize our teams we will have to broaden the teams collective skill. We have to let go of our addiction to individuals with specialized knowledge that become a single points of failure. We need more people that know more things.

This will require courage and a commitment to broadening the skills of our people. It will require a commitment to team building. It will require commitment to the belief that a well functioning team can deliver more than a collection of talented individuals.

Link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/04/one-team.html

 Subscribe to this blog

Subscribe to Leading Agile