Agile Risk Management - Logistical Risk

This is the final installment of a three part series on Risk Management. Part one discussed how I think about business risk. Part two dealt with how to think about technical risk. This post will address some things to think about when considering logistical risk.

Logistical Risk

Logistical risk deals timing and team member availability. These are your people and money risks. Once the business risks are mitigated and we have proven there is a viable solution, this is where the team can really scale the project and build out the bulk of the solution. Here we are answering questions about having the people to do the work. We are monitoring to see if we are making the progress we expected at the beginning. Are we going to have to make any tradeoffs to hit our market date?

Logistical Risks deal with people. Do we have enough people to do the work and are our original assumptions about their capacity going to hold?

In reality, you are dealing with all three types of risk all through the project. The focus becomes logistical risk once you have tackled the other high risk areas of the project and are ready to get down to the business of building out the product. On a large team, you have probably broken your core team up to seed other small teams on the project. As the project scales, you are working to make sure the interactions between the teams are running smoothly. You are concerned with establishing a stable team velocity, grooming the backlog, and making sure that you are regularly delivering business value.

You are working to make sure that the team has everything it needs to be successful. You are actively removing impediments, and interacting with other parts of the business to prepare for your final product delivery. You are probably coordinating the availability of extended team members, managing external dependencies, and possibly dealing with unexpected departures. Logistical risk is about managing the team through the life of project execution.

In Conclusion

I have witnessed too many Project Managers dealing with risk as something external to the project. It is as if the project is on one track and risk management is on another. Risk management is not a separate process that lives outside the way we build software. Risk management needs to be built into the very fabric of the project itself.

Delivering product to customers mitigates all kinds of risk, let's do that a lot. Continuous integration mitigates risk, let's do that too. Continuous testing mitigates risk, let's test all the time. These are not things that the technical team just does, they are things that project managers need to make sure is happening. We need to make sure they are built into the foundation of our project management approach.

Subscribe to this blog

Subscribe to Leading Agile

APLN Seattle Leadership Summit

For the past few years, local APLN chapters have been hosting regional Leadership Summits. These events have been very well received and attract fantastic speakers and exceptional local thought leaders througout the agile community.

The summit targets both new and seasoned Agile leaders at all levels: organizational leaders, product leaders, and project leaders. This is your chance to spend a whole day with some of the leading experts in the area of Agile Leadership, to network with with other agile leaders and to share your experiences and concerns with those who are in the same situation as yourself.

The Dallas Summit was a huge success! Next up is Seattle.

The APLN Leadership Summit format includes:

• Networking opportunities throughout the day
• Speakers addressing how to lead their organizations to become agile.
• "Think Tank" sessions on Agile Leadership with topics addressing advanced leadership tools, experiences, lessons learned, and issues yet to be resolved, decided by the group.
• Networking social at the end of the first day to review think tank solutions and suggestions.

David Anderson is lining up an all star crew to host the event. So far he has lined up the following thought leaders:

• Brent Barton, CTO, Solutions IQ
• Jim Benson and Corey Ladas, Modus Cooperandi
• Bruce Eckfeldt, Managing Director, Principal, Cyrus Innovation
• Mike Griffiths, Founder, Leading Answers
• Lisa Haneberg, Author
• Mitch Lacey, Accentium Senior Project Leader
• David Anderson, Founder of Modus Cooperandi
• also... Luke Hohmann, Jeff Patton, and Arlen Bankston
  

If you are in the area, or able to make a the trip, this event will be well worth attending.

For more information and to register, please visit the APLN Summit home page: http://www.apln.org/summits.html

Subscribe to this blog

Subscribe to Leading Agile

Agile Risk Management - Technical Risk

This is part two of a mini-series on risk management. Part one discussed how I think about business risk. This post will address some things to think about when considering technical risk.

Technical Risk

Technical risk deals with those unproven assumptions in your emerging design that might significantly impact your ability to deliver the solution. Are we planning to use any unproven technologies to build the solution? Have we exercised the significant interfaces between systems? Can we demonstrate a working skeleton of the system? What about performance? What about security? Any technical decisions not validated by working software count as technical risks.

Technical risk deals with feasibility. In other words, have we proven there is a solution that can be delivered within the time and cost constraints of the project?

Technical risk is also dealt with early in the project immediately after you have a handle on the critical business risks. This is where the team really gets engaged for the first time. You bring your resources to bear to build out the system and validate any assumptions you made during planning. The backlog should be prioritized with an eye toward technical risk. Build out those features early that are most likely to validate your architectural assumptions and stabilize your emerging design.

It is worth emphasizing here that technical risk should always be mitigated in the context of working software. We build features to mitigate risk. Proving interfaces, or that one system can talk to another, outside the context of delivered business value does little to prove anything or mitigate any real risk. Testing is an integral part of risk mitigation. Untested features deliver no value.

As we build features, we will certainly learn more about the architecture and more about what it is going to take to build out the proposed solutions. Stay open to this new information. Re-estimate the backlog if necessary. Share this information with your product owner. Allow them the opportunity to learn along with you and adjust their plans and expectations accordingly. Look for technical tradeoffs that will allow you to deliver within the agreed upon time and cost.

What happens if you prove there is not a solution that can be delivered within the time and cost constraints of the project? Sounds we've just identified a pretty significant business risk. Mitigate your technical risks early and ensure feasibility while your overall investment is still relatively low.

Click here to read my previous post on Business Risk. Next post we'll address Logistical Risk

Subscribe to this blog Subscribe to Leading Agile

Agile Risk Management - Business Risk

As project managers, we must understand how to identify risk and how to put strategies in place to mitigate their effects. To put an effective strategy in place, it is necessary to consider what factors are leading to the risk and when these factors are most likely to impact your project. Over the next few posts we'll talk about three common categories of risk, how we distinguish them from each other, and what we can do to make sure they don't negatively impact our project.

Business Risk

Do we have reason to believe the features we've scheduled for the upcoming release will deliver the value we have planned? Do we have reason to believe the team can deliver that value within the time and cost constraints we have established? What about our customers, have they weighed in that we are building the right product? Is everyone on the team organized around a clearly articulated product vision? Answering these kinds of questions is what it means to mitigate business risk.

Business risk deals with value. In other words, can our project deliver the value we have promised to the business?

Business risk is one of the first kinds of risk to consider on a project. This is often addressed before the entire team really gets going on the project. In this stage, you are setting goals, chartering the project, and getting the project funded. Once the vision is set, make sure that the features you define in the product backlog are focused on delivering that vision. Weed out requirements that are not necessary to deliver that vision, keep things as simple as possible.

Establish a high level architectural approach for the product and use this common understanding as a baseline for estimating and planning. Estimate your backlog, keep it prioritized, and work on the highest value features first. Measure the throughput of the team and assess progress against your backlog. If your team's throughput is less than expected, deal with these issues immediately. Give your product owners the opportunity to adjust the scope of the release or negotiate detailed feature functionality.

Constantly reevaluate the product backlog in light of what we are learning from the emerging solution. Don't assume that the original features are the right features to deliver the vision. Stay open to new information and be willing to learn. If you find that what you are learning is moving you away from the original product vision, ask the hard questions about the project and help the business decide if this new direction is consistent with the organizations goals. If not, what does this mean for the product?

Dealing with business risk involves balancing the product vision, market needs, and the emerging solution. Maintaining the right balance between these three factors is how we guide the project into a successful outcome.

Next post... Technical Risk

Link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/05/agile-risk-mana.html

Subscribe to this blog

Subscribe to Leading Agile

Straw Men and Red Herrings

Whenever I get into a discussion on Agile Project Management, I inevitably find myself contrasting Agile methods with "Traditional Project Management". I use the phrase "Traditional Project Management" as a label for that style of project management advocated by the PMI, documented in the PMBOK, and certified through the PMP. It's the kind of project management we often characterize as big up front planning followed by a blind adherence to the plan.

Setting up the conversation this way gives me an easy way to establish contrast and teach about Agile methods. The problem with this approach is that reality is never quite so simple.

A well run "Traditional" project does adapt and respond to its environment. A good "Traditional" Project Manager does lead and empower their teams. While good "Agile" teams are structured and disciplined, many are unstructured and chaotic. Establishing an us vs. them mentality isn't going to lead us any closer toward developing more adaptive project managers or more adaptive project management practices.

We will always be able to find examples of misapplied process no matter what management or leadership philosophy we happen to hold.

Rather than setting up the "Traditional" crowd to take the fall for all our project management problems, we should acknowledge that there is a time and place where it does make sense to apply a more "Traditional" approach. Let's focus on making the Project Management community aware of those domains where it doesn't. If we can clearly communicate what makes some software projects different, in a language the "Traditional" crowd understands, we will be better positioned to open minds.

Agile is pretty risky for people that have been immersed in 30-40 years of conventional project management wisdom. As Agile becomes more mainstream, we are going to need to deal with people that are not ready to drink the Kool-Aid. If we want the PMOs out there to see Agile as a viable project management approach, we need to meet people where they are and guide them gently into this new way of thinking.

So here is my new formula for having a discussion on agile project management

1. Validate the traditional project management processes
2. Explain why these processes break down in certain problem domain
3. Listen for objections and understand their point of view
4. Explain how agile project management solves some of these problems.

What do you think?

Subscribe to this blog

Subscribe to Leading Agile

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