Agile Chronicles

Refactor Your PMP

In software engineering, refactoring a module of code means that you change its internal workings while leaving its external interfaces intact. A developer might do this to make the internal workings of their software simpler, more efficient, or easier to understand. The key is that refactored code maintains it's contract with the surrounding system. Everyone can still get what they need from the refactored system component in exactly the way they have always gotten it.

There is something here we can draw from as project managers. As we make the switch to agile project management, we must stay plugged in with the language of the organization. We need to maintain the contract the business has come to expect. Over time we may be able to influence how our organizations think about project management best practice. At some point we may even be able to renegotiate the contract.

For now, we need to take what we know about adaptive and traditional project management and establish a framework for delivering in the language of the business. The PMI process groups and knowledge areas provide a well thought out and disciplined foundation on which to build. Our challenge is to approach the discipline of project management with an agile mindset. To figure out how to leverage agile practices within the constructs of the accepted project management best practices.

Over the next few weeks we'll break down the PMI process groups, knowledge areas, and processes to explore how we can build an effective agile framework using the established contracts.

Can We Do Better?

On several of the Scrum & Agile boards that I frequent and regularly post, there has been some pretty lengthy discussion about team optimization and how organizationally, we can be certain we are pushing at our maximum level of efficiency.

I had a recent encounter with someone who provided this scenario: " Within our organization, we manage large scale projects. I have multiple teams that each contain offshore resources. I have a clear understanding that agile practices and principles teach that the team should be recognized as a whole for work they complete or do not complete. Where I am beginning to struggle is that upper management feels this team could be doing more with their time. I have now been tasked with finding those individuals who are not pulling their weight on the team and helping them make needed adjustments. How do I begin capturing individual metrics without disrupting the overall team productivity which is for the most part very good?"

Before I even attempted to tackle this scenario, I thought back on all of the books I have read, classes I have attended, conference sessions I have hosted or attended, and none of the book knowledge out there could adequately address this issue. This is not to say there are not hundreds of publications that have addressed a similar topic. I truly believe that each team is different as is the team composition. The only practical solution was to give advice based on real-world scenarios I have seen in the past. It was time for me to play the role of doctor.

I remember early on in my relationship with scrum I had a conversation with one of the thought leaders and the counsel I received went something like this. Being a good scrum master or project manager is a lot like being a doctor. When the team comes in and says they do not feel good, it becomes your responsibility to ask the right questions and make a diagnosis. Just because someone has a bad cough, it does not mean the have full blown pneumonia. Most of all remember, just like every person is different when it comes to health related issues, so is every team! Each may have a pre-disposition to cause us to think that the ailment could stem from a certain root cause, but it is not fair to assess one against another as their composition and surroundings could be very different.

This could have been the best advice I have ever received as a scrum master, agile coach, or mentor. Now all I needed to do was provide an eloquent answer that combined my real-world solutions with this nugget of pure knowledge.

With this, I turned to the individual account above and offered the following advice. It is the responsibility of a good scrum master, project manager, or team leader to effectively use the daily meetings, team burndowns, and in rare cases individual burndowns to give clear visibility into the team's progress over the course of an iteration. It is the team's responsibility to take ownership of their work and be accountable for what they commit to. It is each person on the team's responsibility to take the agile oath and ask them self, "Can We Do Better?". The answer will come and the team will feel gratification when they feel they have provided a voice and their voice was heard.

The key to increasing the success and efficiency of any team is contained in three short meetings:

1) Have a 15 minute daily meeting with each team. This serves as a great pulse check and makes teams feel accountable for their daily activities.

2) Hold a demo at he end of each iteration. Allow the team to take pride in what they have created and give them the forum to showcase their work. This instills teamwork, increased collaboration, and team empowerment.

3) Conduct a meaningful retrospective at the end of each iteration. This meeting should be short and be a recap of the team health. This in essence is the equivalent of a yearly well health exam at the doctor. In an agile environment we do it more frequently.

Now that I have provided each of you with the tools you need to get the team on track and motivated, stop reading and go get some work done.

Agile is Risk Management

There was a great question last week in the comments of one of my blog posts. The reader asked if agile offered any unique proposals for managing risk on a project? I've been blending my traditional background in project management with agile for several years now and sometimes I have to remind myself of what I've taken from what sources.

After reviewing the PMBOK section on Project Risk Management, I had to conclude that Agile doesn't really offer anything new. Surprised? The PMBOK has processes for developing a risk management plan, identifying risks, performing qualitative and quantitative analysis, conducting risk response planning, and monitoring and controlling risks.

You can clearly make the case the agile might take a lighter approach to risk management, maybe rely less on documentation, but fundamentally you are doing many of the same activities on an agile project as you might on a traditional project. Why are agile methodologies so good then at identifying and mitigating risk?

Agile is so effective at managing risk because risk management processes are built into the very fabric of how we run the project.

There is an implicit understanding that risk is EVERYWHERE on a project. Risk cannot be contained in a risk list. Risk cannot be mitigated in a team meeting or a periodic risk review session. Dealing with risk has to be an obsession. Our mitigation strategies don’t live outside the project, but influence the very nature of how we structure and plan our work.

Many project managers take a boiler plate approach to risk management. They deal with the easy stuff, the obvious risks that could be assigned to almost every project. Are we going to run out of money? Are we going to lose a key contributor? What happens if the project is late? While these are all important, they only represent a small slice of the kinds of risk we need to consider.

As project managers, we tend to assume that the business vision is accurate. We assume that if we deliver to the spec we'll satisfy the market needs. We gloss over technical uncertainty because the technology guys are responsible for making all the code work. More detailed planning and designs do not mitigate risk. The only thing that really mitigates risk is delivering product.

Agile mitigates risk by building project frameworks that encourage frequent delivery, constant inspection and review, and allow us to adapt when things are not going as you expect.

In short, agile is risk management.

Taking Agile Offshore

Companies today are attempting to lower costs and increase staffing flexibility by taking some, or even all, of their development activities overseas. Many of these same organizations have teams that are using agile development practices in an effort to increase quality and improve project performance. Some teams might find themselves in a situation where they didn't choose to take their teams offshore; but that decision was, in fact, made for them.

What happens when these two trends in our industry intersect?

There are tools and techniques that you can draw from agile that are essential for any kind of offshore endeavor. Development practices such as test driven development, continuous integration, and pair programming can be a powerful risk reduction mechanism to ensure the quality of your product and reduce uncertainty.

Defining requirements as user stories, building out thin slices of the product, and frequently reviewing those features with the customer can go a long way to making sure you are building the right product. Using these techniques help mitigate timeline risk because the product is always in a nearly releasable state. Daily stand-up meetings, sprint planning, and sprint closedown provide essential visibility into the development process and create an environment where you can inspect progress and adapt based on that feedback.

You never get too far off before you have the opportunity to adjust.

Teams working across dramatically different time zones, separated by thousands of miles, are going to need more documentation to stay in synch. There is not enough communication bandwidth to keep everyone busy and on the same page. Documentation needs to be viewed as a means of communication and not the deliverable. It is overhead. Keep doc as simple as possible to get the point across. Having a solid architectural description, very specific story descriptions, and clearly articulated acceptance criteria are key.

You'll need to adapt some of your agile leadership philosophies to accommodate the unique characteristics of your offshore team. You might have to take a more prescriptive approach as the team is coming up to speed. Not everyone may be culturally ready to accept the level of responsibility that agile requires. You may need to have a senior team member hand out stories, rather than having the team self select, to accommodate background and experience.

Be intentional about these deviations and have a coaching strategy for moving team members where you need them to be.

Taking an agile approach to offshore development is going to expose you to more junior staff than you might be used to working with. The market, especially in India, is very tight. As developers gain experience, many of the best people will move into management. You may experience 2-1, 3-1, or even 10-1 productivity differences between your more senior onshore guys and the offshore team.

These differences, coupled with increased documentation, increased communication delays, increased management and tracking burdens, and increased coaching overhead; create a much more complicated financial picture than just hourly rate. Using offshore talent will result in increased working hours and increased demand on the capability of the onshore developers. If cost savings are your primary driver for going offshore, you might want to look very closely at the numbers and measure if you are really getting the savings you expect.

The hourly rate is not all you need to take into consideration.

If you have had a different experience with agile in an offshore model, please feel free to comment, especially if you disagree with my conclusions. If you are a developer working for an 'offshore' outsourcing firm, please let us know if you think these experiences here are typical. Do you have any thoughts on how the typical offshore relationship will evolve, over time, as rates and technical experience go up? These are all interesting questions.

I will be sharing an experience report with the community at Agile 2008. If you feel strongly about these topics, please come find me. I would love to hear how using agile with an offshore team has worked for you.

The Agile Edge Conference

Next week Valtech and VersionOne are co-sponsoring a one day conference called the Agile Edge. This will be an intense introduction to Agile designed to give attendees tools they can use to drive organizational transformation and breakthrough performance. David Anderson will be kicking off the event so it should prove to be a very informative and exciting day.

The conference will offer three tracks, each covering a different role on the project: product owners, developers, and project managers. I have the honor of doing the talks on the Agile Management track. We've prepared three presentations that are geared toward traditional project managers making the switch to agile.

Refactoring your PMPs
Successfully moving to Agile Project Management will hinge largely on how well we adopt new ways of thinking about project structure and control. Building on the principles of PMI and the Project Management Body of Knowledge (PMBOK) we will explore how a PMP can adapt their knowledge and experience to become an effective Agile Project Manager.

The Agile Power Shift
Agile methods build high-performing project cultures and put a great deal of emphasis on trust, empowerment, and self-organization. Agile moves us away from command and control project structures and toward structures that help us tap into the passion, creativity, and enthusiasm of the team. This team centric approach can leave the traditional project manager wondering about their new role on an agile project. This talk will explain the essentials of agile team dynamics, how teams contribute to project success, and what we must learn to become effective agile project leaders.

Agile Project Management Explained
Agile represents a dramatic shift in thinking about project management. It also represents a pretty radical shift in what a project manager does. At some point project managers have to transition from thinking about Agile to actually making it happen. This talk will explain the mechanics of running an Agile project and how these techniques support the principles behind Agile methodologies.

For those that cannot make the talk next week in DC, we'll be offering this conference in other cities around the country. Next up is New York on June 25th. Click here for more information and to register for the event. Looking forward to seeing everyone there!

APLN 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

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.

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

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

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?