If anyone is going to be down in Orlando for Agile Development Practices, it is shaping up to be a great event. The conference is November 10-14 at the Shingle Creek Resort. Click here for more information or to register.
I will be speaking this year on the whole Agile/PMP thing I have been rambling on about the past few months. The talk is called "The Agile PMP: Teaching an Old Dog New Tricks". If you are coming to town for the event, come look me up, I would love to meet you.
Here is the abstract and my bio for the event in case you are interested:
Agile methods put a great deal of emphasis on trust, empowerment, and collaboration. Agile moves us away from command and control project management towards an approach designed to harness the passion, creativity, and enthusiasm of the team. A successful transition to agile project management hinges largely on how well traditional project managers are able to adopt new ways of thinking about project structure and control. Building on the principles of PMI® and the Project Management Body of Knowledge (PMBOK), Mike will explore how a PMP can adapt their knowledge and experience to become an effective agile project leader. Mike will tackle the hidden assumptions behind the PMBOK and explore a more agile approach to managing time, cost, and scope. He will take an in-depth look at the PMI Processes and Knowledge areas and explore how to adapt them on agile projects. Project managers, business analysts, and other stakeholders will leave with new way of thinking about project management best practices and new tools for delivering value in the face of uncertainty.
Mike Cottmeyer is a product consultant and agile evangelist for VersionOne. Prior to joining VersionOne, Mike was a senior project manager for CheckFree Corporation where he managed a portfolio of projects for their online banking and bill payment business unit. Mike has a background in traditional project management but has worked primarily with agile methodologies for the past four years. Mike is a certified PMP Project Manager and a Certified ScrumMaster. Mike co-created the DSDM Agile Project Leader certification. He holds this certification at the Foundation, Practitioner, and Examiner levels and was recently named an honorary member of the DSDM consortium. Mike is currently on the board of APLN as Treasurer.
Subscribe to this blog
Tuesday, July 8, 2008
Mike's Abstract for Agile Development Practices 2008
Thursday, June 26, 2008
Project Management is Not Enough
Are you a software project manager? If so, your job is changing. It is no longer enough to keep the risk list up to date. It is not enough being the person to schedule the meetings and do the minutes. Knowing how to calculate earned value and critical path is the price you pay to even call yourself a project manager.
Great project managers take those skills for granted. Great project managers are defined by how well they lead their teams. Great software project managers establish context. They create organizational alignment and guide their projects toward successful project outcomes. Great project managers focus on team building, they open lines of communication, they trust people, respect and empower them, and maintain sufficient control to hold everyone accountable for project outcomes.
In my experience, project managers tend to look at themselves in one of two ways. Some PMs want to be at the center of the project, in control of everything, in the middle of every decision. Like the illustration on the right, they try to be the center of the wheel with all team members connecting through them.
Others lead from the boundaries, they create the context. They establish the parameters of the project, the outer limits. They trust the project team to deliver the desired outcomes within those limits. These project managers build teams, get them what they need to be successful, and remove any barriers that could stand in their way. The project manager on the left is intentional about creating and maintaining connections between team members and acting as the buffer to the rest of the organization.
Traditional project management tends to focus more on the science of project management and less on the leadership and team aspects. Agile can sometimes focus too much on the softer side. It's my view that the process driven, scientific side of project management should be a given. That is your ticket in the door. Its time we start hiring great project leaders. It's up to us to get serious about becoming great leaders.
Otherwise, don’t call yourself a project manager.
Here is a link to my post on Agile Chronicles: http://blog.versionone.net/blog/2008/06/project-managem.html Subscribe to this blog
Photo Credit: http://www.projectstrategy.com
Monday, June 23, 2008
Announcing the 3rd Annual "State of Agile Development' Survey
It is that time of year again - Version One has launched it's 3rd Annual 'State of Agile Development' Survey.
Subscribe to this blog
Thursday, June 5, 2008
Agile Managers?
What are we going to do with all the managers when we realize the vision of fully self-organizing teams? What incentive to managers have helping teams become more independent if they are in effect working themselves out of a job? I was up at the Agile Coaches Camp this past weekend in Ann Arbor, Michigan. A few of us bounced this idea around a bit and came up with a proposal.
On a self-organizing agile team, the resource manager is responsible for supporting their team's career development, personal growth, and training; they are also responsible for removing organizational impediments that hamper their team's ability to perform. Just as a ScrumMaster protects and supports the project team, the Resource Manager protects and supports the resource team.
What do you think? Too simple? Subscribe to this blog
Wednesday, June 4, 2008
Refactor Your PMP: Time Management
The first knowledge area we are going to tackle is Time Management. According to PMI, time management involves those processes that contribute to the on-time completion of the project. This knowledge area includes six project management processes designed to accomplish this goal. We'll explore all six and see how we can adapt these processes to make them a little more Agile.
Activity Definition
PMI Definition: Identifying the specific schedule activities that need to be performed to produce the various project deliverables.
To make this process more agile, you first need to think in terms of defining the features of the system, not the activities. Up front we want to know how the system is going to behave. These feature specifications need to be small and independent of each other. Agile teams usually call these features a user story or a backlog item. Collectively the list of product features is called the product backlog. The backlog represents the scope of an agile project.
Activity Sequencing
PMI Definition: Identifying and documenting dependencies among schedule activities
While discussing activity definition, we stated that the backlog items need to be independent of each other. The reason they need to be independent is because we want to have the ability to change requirements as our understanding of the evolving system changes. By definition we are seeking to minimize the dependencies between the work items on our project. Sequencing on an agile project is based less on dependencies and more on risk and business value. We want to focus on sequencing based on which features are going to reduce the most risk and deliver the most value as early in the project as possible.
Activity Resource Estimating
PMI Definition: Estimating the type and quantities of resources required to perform each schedule activity.
In traditional project management approaches, we are usually trying to determine the type and quantities of resources when we know the least about what it is we are going to build. Spending time and money to get a better understanding of these variables is not going to yield a substantial return. Agile approaches use a technique of estimating that relies on the collective understanding of the team to determine a relative size estimate of the feature, often measured in units such as story points or ideal engineering hours. These units only asses the size of the feature relative to the other features in the backlog.
Activity Duration Estimating
PMI Definition: Estimating the number of work periods that will be needed to complete individual schedule activities
We've discussed that each feature in the backlog needs to be small. Our goal is to have every backlog item small enough that it can be delivered within a single iteration. Agile teams build in this constraint and then measure how many features they are able to complete in a given iteration. By measuring how many story points, or ideal hours, they are able to complete each iteration, the team can predict how many iterations it will take to complete the backlog.
Schedule Development
PMI Definition: Analyzing activity sequences, durations, resource requirements, and schedule constraints to create the project schedule
Typical agile projects begin with a time constraint, iterations are fixed periods of time and release schedules are usually established at some fixed interval. Each of these are set by the team and the product owner, but once set do not change. That language might sound a little strong but agile is about building trust with your customer. Good agile teams can always make their date, it is the scope that will vary.
Schedule Control
PMI Definition: Controlling changes to the project schedule
Because the iteration and release timeframes are fixed, it all comes down to a discussion around scope. These discussions are a constant collaborative effort between the product owner and the team. The product owner always has the option of adding additional iterations to include more features. Because the features are discrete, and the team is always working on the highest priority features first, the product owner also has the option of calling the project complete at the end of any iteration.
As always, if you think there is anything I left out, or should have dealt with in more detail, please let me know via response to this post. I speak on this subject quite a bit so anything you have to contribute to make this brief explanation more understandable would be really appreciated.
Next up we'll deal with cost management processes.
Here is a link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/06/refactor-your-p.html Subscribe to this blog
Thursday, May 29, 2008
Mike's Agile2008 Abstracts
The Agile 2008 conference is just around the corner. This is a great opportunity to hear some fantastic speakers and get to know the broader Agile community. It is a blast getting together with other folks that are passionate about Agile and want to make a difference. You can get more information about the conference by clicking here.
For those not familiar with the content selection process, the entire community was encouraged to submit session proposals. These proposals were publicly reviewed and all comments were available to everyone. Some people really did not pull any punches, it was pretty brutal. After a period of review, the selection committee took a crack at the proposals and made their decisions. Everything was very transparent and I was really impressed with the process.
I will be giving three talks over the course of the week, all three on topics I am very passionate about and have blogged on over the past few months. If you happen to be at the conference, I would love to meet you and hear your feedback on my writing at Leading Agile or over on Agile Chronicles.
Here are the session titles and abstracts I've submitted for the conference proceedings:
Leading Volunteers With Agility
Volunteer organizations are unique because people are not paid for their contribution and your organization is in competition for space in an already over-booked schedule. By necessity, volunteer organizations require a more human-centric approach to leadership. This workshop will explore the 10 things you better be doing if you want to harness the passion and enthusiasm of your team of volunteers. Topics such as empowerment, self-organization, and short-cycle delivery will be addressed using real world scenarios.
Wednesday August 6th from 2:00 - 3:30 in the Huron Room
The Good and Bad of Agile Offshore Development
Companies today are attempting to lower costs and increase their staffing flexibility by taking some [or even all] of their development activities overseas. Simultaneously, many of these same organizations are exploring agile development practices in an effort to increase quality and to improve project performance. This report explores the intersection of these two significant trends common in today’s software development organizations. We will show how our team built an effective agile offshore development capability, what we learned along the way, and what we would do differently next time around.
Thursday August 7th from 4:00 - 5:30 in Conference Room H
Using the Unified Process as a Scaling Framework for Scrum
One of the common complaints about the Unified Process is that it is too prescriptive and document focused. An often heard complaint about Scrum is that it does not scale to large projects and you never quite know where you are going until you get there. What if we could leverage the best of both methodologies? What if we could deliver with just enough structure and documentation to scale the project but maintain the collaborative, human centered approach of Scrum? This talk will show you how it’s done.
Friday August 8th from 8:30 - 10:00 in Conference Room C
My Bio
Mike is a Product Consultant and Agile Evangelist for VersionOne. Prior to joining VersionOne, Mike was a Senior Project Manager for CheckFree Corporation where he led a portfolio of projects for their online banking and bill payment business unit. Mike has a background in traditional project management but has worked primarily with agile methodologies for the past four years.
Mike is a certified PMP project manager and a certified ScrumMaster. Mike co-created the DSDM Agile Project Leader certification. He holds this certification at the Foundation, Practitioner, and Examiner levels and was recently named an honorary member of the DSDM consortium. Mike is on the board of APLN and the current Treasurer. Subscribe to this blog
Tuesday, May 27, 2008
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 my next few posts 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. If you are interested in a little pre-reading, check out the following posts from my blog and a few others:
Sunday, May 18, 2008
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. Subscribe to this blog
Thursday, May 15, 2008
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! Subscribe to this blog
Friday, May 9, 2008
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
Tuesday, May 6, 2008
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
Thursday, May 1, 2008
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
- Validate the traditional project management processes
- Explain why these processes break down in certain problem domain
- Listen for objections and understand their point of view
- Explain how agile project management solves some of these problems.
What do you think? Subscribe to this blog
Thursday, April 24, 2008
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
Monday, April 21, 2008
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.
Friday, April 18, 2008
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.
Wednesday, April 16, 2008
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
Saturday, April 12, 2008
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
Wednesday, April 9, 2008
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
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