Need training, coaching, or help leading an agile transformation?
email: mike@cottmeyer.com or call: 404.312.1471

Tuesday, December 23, 2008

So... Who Reads Leading Agile Anyway?

Okay... just kidding with the picture. This is my last work day until the new year so I am waxing philosophical and exploring some stuff I have been thinking about for a little while.

This post originated based on some feedback I've received over the past few weeks on the 'Secret to Organizational Agility' post and more recently on the 'Agile PMP: Teaching an Old Dog New Tricks' webinar from last week.

Both sets of feedback, most of it positive... some of it not, prompted me to give some thought to my intended audience and why I am writing to them at all. When you can't be everything to everyone, you better be damn clear who you are and what you want to be for those that care.

Here is my musing on that subject. Be warned, I start to get a little teary eyed toward the end ;-)

I started writing publicly a little over a year ago. When I started, Leading Agile was originally titled Applied Agile Leadership. My thought was to take some of the agile concepts my team had been working with for the past few years and help others apply them more effectively in a range of situationally specific contexts.

Looking back, there was no way for me to really understand what the year would bring or the value writing would have to me as a professional in this arena. Writing this blog has become essential for me to process and understand these ideas and more importantly, express them to others. I am often asked questions about topics I have blogged on, and not only do I have a prepared answer, but a resource that I can point them to for more information. I have often built entire talks around ideas that started off on these pages.

Why Project Management?

My career has been a love/hate relationship with Project Management. The title implies so much yet means so little. Depending on your organization and the strength of its project management team, the skills and competencies of your project management staff can be so radically different. Some teams are filled with glorified secretaries while others are populated with senior leaders capable delivering large programs and effecting significant organizational change.

In my own quest for personal meaning, I have always advocated that Project Managers need to be seasoned, qualified leaders that are not merely passive participants in the act of project management. They need to be knowledgeable in a wide range of project management best practice, they need to know their particular problem domain, and most importantly they need to be able to interact effectively will all levels of the organization. Project Managers need to be strategic problem solvers, not just note takers and meeting schedulers.

At its very core… this blog is fundamentally a call to action for project managers to become better leaders.

I have always felt that the knowledge of project management process was almost trivial. Read a book, study for and pass a test... call yourself a PMP. Take a two day course on agile management... call yourself a Certified ScrumMaster. It's not the facts that are our challenge, its not the techniques… it is the underlying principles. It is the ability to apply these facts and techniques in your own situationally specific context.

Who is My Audience?


To be honest, I don't know much about the folks that read my blog. I have some anecdotal information based on a few of the folks I have met personally at conferences and talks. I get a little information from the people that comment or reference my blog in their posts (which I really appreciate by the way). Based on my passions and what little I know about my readership, I have constructed a mental model of my reader, a persona if you will, of the person I am talking to on the other end.

NOTE: It would be cool if you guys would let me know the accuracy of my assessment. Reply to this post or drop me a line.

As I mentioned before, I see myself primarily talking to Project Managers. I use Project Manager loosely in this context. Often times we have Development Managers and Directors of Development leading projects. We might have a Product Owner leading a project. Sometimes we have Technical Team Leads or even a QA analyst. Basically, anyone that has taken on a project management role, no matter what their title in an organization.

I am fundamentally trying to help the folks out there making it work… make it work.

My typical reader could be a hard core agilist trying to lead change in their organization. I suspect that many of my ideas might help these folks discover a new way of looking at things or presenting concepts to a traditional management organization.

I suspect that many of my readers are people currently performing a traditional project management role, probably a PMP, maybe somewhat new to this whole agile thing, and struggling to understand and implement agile within traditional organizational constraints.

Same problem… different points of view.

What Can I Contribute?


Most folks I meet are wired to think about process in terms of actionable steps and the supporting documentation. I want to help people think about projects in terms of people. I want them to think in terms of complex systems and interdependent behavior. I want to get up underneath process and people and focus on the kinds of stuff that really cause our projects to fail. More documentation and better defined processes steps don't solve the problem. It is our underlying attitudes and values that matter.

So… I am not sure at this point in my public life I have contributed anything really new. I am clearly standing on the shoulders of the giants that have come before me. I really appreciate the though leadership of Cockburn, Highsmith, and Cohn amongst many, many others. What I do is impossible without them. One thing that I think I can do well, and on my best days, maybe even better than most, is help folks understand these ideas in language that project managers can understand... advocating strategies they can actually implement.

I value thinking about problems in the right way. I want to be right, at the very least I want to be in the ballpark. The fun part about writing publicly and thinking out loud is that I don't have to be right... and I am not scared to be wrong.

Most of the time when someone disagrees with one of my posts, it is really a matter of perspective and a difference in our perceived audience. I don't try to be a pure agilist and I am not talking about applying these concepts in an ideal setting. I grew up professionally trying to understand these concepts in large convoluted organizations. I want to help people untangle the mess, one step at a time. I am passionate about helping people breaking down these concepts and understanding the why behind them, and then building them up in a way that helps their organizations understand.

Is it Working?

This year Leading Agile has seen success so I am guessing my approach resonates with some in the community. This blog has grown from just a few subscribers at the beginning of the year to around 600 or so as of this morning.

I thank Brian Sondergaard for encouraging me to start writing at all. I also want to thank Jurgen Appelo, Artem Marchenko, and Glen Alleman for all the great press and links to my site over the year. Thanks also to those of you that have shared my posts through Google Reader, Twitter, and to those that have referenced Leading Agile in their own blogs. You guys know who you are and I appreciate your help.

I hope that this site fills a valuable void in the marketplace of ideas. I read a great and timely quote this morning that I'd like to share:

I don’t wish to be everything to everyone, but would like to be something to someone.” ~ Ali Javan.

Subscribe to this blog Subscribe to Leading Agile

2008 in Retrospective: Mike Cottmeyer Edition

The end of the year is always a great time to reflect. Somehow the prospect of a new year allows us to break psychologically from our past. The new year gives us an opportunity to learn from our mistakes and move toward a better tomorrow. Whether real or imagined there is power in this annual rite of reflection.

The Need to Change

Toward the end of last year I realized I was frustrated. My career had been a slow steady climb but was not yielding the results I had hoped for. Somehow along the way I had stopped playing to my strengths and allowed myself to start playing to others expectations. I needed something in my life that I could own, something I had created. I toyed quite a bit about going out as independent consultant but was not in a great position to take that kind of risk. The kids have to be fed… the mortgage has to be paid.

CheckFree had been a great gig for several years but I decided it was time for a change. Over the previous few months I had been building a relationship with some of the folks at VersionOne. Early December 2007, after several months of talking, I was offered a role on the VersionOne Services team. This was an opportunity to train and consult and fill my non-billable time with writing, community events, and speaking engagements. Taking this position allowed me to live out my desire to be an independent consultant within the confines of a small but well established company.

Over the past year I have learned that VersionOne is just the kind of gig I am cut out for. The day to day monotony of corporate America is just not my thing... at least not right now... and at least in the kind of jobs I'd been doing the past 18 years. I feel fortunate to have learned this about myself and that I had the opportunity to make a change.

There are some life skills I'll need to develop to make this kind of role work over the long haul. The fun stuff is so compelling it is easy to lose sight of other things that must get done. I learned that I have to be more disciplined about leaving time to change a light bulbs, for balancing my checkbook, and mowing the grass. I need to be more disciplined about diet and exercise and getting enough sleep. I will have to find a way to turn off my work brain every now and again. My wife tries to tell me our life is not an agile project (although I am not sure I agree).

With 2008 just a week or so away… I'm thinking a lot about what I'd like to build on in the upcoming year and what I'd like to do better.

What Worked Well...

While I did spend too much time on the road this year, I really enjoyed getting out and talking with customers. Having exposure to a broad cross-section of companies and leaders at every level of the organization has proven invaluable. These people have helped me sharpen my perspective and given me insight that is just not possible working with only one customer at a time.

These interactions have been the engine behind my writing and helped fuel my creativity. I can't tell you how many times this year when I had nothing else to say that I was inspired by a client to do some of my best work. Blogging and writing has become a form of creative expression and I find myself compelled at times to write. Writing has helped me clarify my ideas and become more articulate expressing them. I am really happy with my body of work so far and look forward to building on it in 2009.

For as much time as I spent traveling this year, I can honestly say that my relationship with Kimi and the kids did not suffer. Catch me offline and you can check in with her yourself, I am confident she will agree ;-) As we move into 2009 I plan to continue my involvement with our school (http://www.hopespringscs.org), with the Boy Scouts of America, and doing many more fun things with my wife and kids. We took some great trips and had some really good experiences. I look forward to more of these special times in 2009.

What I Want to do More Of...

My friends and family give me tremendous grief over the amount of time I spend on Twitter and Facebook. Fortunately, they don't even know about LinkedIn and Plaxo or I'd never hear the end of it. While at least people realize that blogging is part of what I do for a living... my wife is still concerned with the amount of personal information I publish about our family. I find it really hard to separate my personal persona from my professional persona... this is just what I do.

The emergence of social networking is really fascinating and I am excited about the idea of marketing my personal brand. Over the course of the next year I'd like to spend more time developing my message and being better at communicating my unique value in the agile idea space. I can't be everything to everyone but I want to get really good at speaking to my target audience and understanding what they need.

Closely related to the idea of social networking and building a personal brand, 2009 is going to be about spending more time with my real network. You know... the one that has actual people in it? Relationships are going to be key to growing my presence in the agile community and I'd like to create space to actually talk with more people and share ideas face to face. Unfortunately for me and my family, that often means time out speaking and doing community events. My goal will be to make the very most of a lesser number of events.

One of the things that took a hit this year was my involvement in our Church. I am fortunate to have a rich community of people I really like and my soul needs to spend more time with them. One of my goals for the upcoming year will be to find a way to contribute. That contribution needs to be life giving and play to my strengths... without consuming an inordinate amount of time. I want to be involved, but I just can't live there... it is easy to get sucked into doing everything.

Things I Need to do Less Of...

Travel is a necessary part of what I have chosen to do for a living but this year I need to be really careful about what I sign up for and how I pace myself. 2008 was pretty manageable until conference season hit and then I found myself in Toronto, London, Denver, and Orlando over two month period. That would have been fine except that I had to prepare content and do my normal work engagements during that time as well. The net result was that I was on the road, or frantically preparing to be on the road, about 80% for over four months.

My goal for the upcoming year is to be more careful about what I agree to do and how I time the events. This year I was like a kid in a candy store. I was unable to decide on what was important and unable to prioritize... so I tried to do it all. I am still living with the tummy ache from all that fast living. There are some things I would like to do in 2009 that I am just going to have to decline. It is all about prioritization, making good choices, and maximizing value.

In the upcoming year I need to do less procrastinating, deferring, and avoiding. This year I allowed a lot of noise and clutter to accumulate in my life... and that detracts from the joy of living. It is difficult to live in the moment when there is always something else to do or someplace else you need to be. Part of this is prioritization, part is just saying no, and part is being really proactive with those things I choose to let remain.

The Power to Change


Overall… 2008 has been a great year. I am not sure I would have changed a thing. Sure… there are a few things I could have done better… but each of those things taught me a valuable lesson that I really needed to learn. I am thankful for my job at VersionOne and all the great people I have met and worked with this year. I am thankful for my supportive family and a great network of friends, twitter followers, and blog subscribers.

There are days when I am surprised that anyone gives a damn what I have to say. I cannot tell you how thankful I am that any of you guys are willing to listen.

I believe in the power of change and I believe we all have the ability to create change in our lives. We can't fix everything overnight. To me it is a matter of being at peace with where you are but still putting time and energy on where you want to be. Even small steps in the right direction can make a difference.

Have a merry Christmas, a fantastic holiday season, and a happy new year!

Subscribe to this blog Subscribe to Leading Agile

Thursday, December 18, 2008

The Unified Process and Scrum

Earlier this year I did a presentation at Agile 2008 on using RUP as a scaling framework for Scrum. The talk was pretty poorly attended and clearly controversial. Earlier this morning I was up on my Slideshare account, pulled the talk up, and did a quick walk through on the presentation.

I really think the concepts here are solid and central to any serious conversation about scaling agile in the enterprise.

If you get a minute over the holidays, take a look at the presentation and give me some feedback. How could we take these foundational concepts and make them more palatable to the broader agile community?

Subscribe to this blog Subscribe to Leading Agile

Friday, December 12, 2008

But They Like It When I Tell Them What To Do!

This is a re-post from my article on Agile Software Development. Re-posted here for my Leading Agile readers.

Okay… I am unexpectedly out on a client site this week and I have not had time to think, let alone write, let alone write anything interesting or worth reading. So, in lieu of a writing a meaty blog post, I am going to tell you guys a little story.

Earlier today I was talking with a traditional project manager trying to get her head around what it will mean to make the switch to agile. Keep in mind, I have been on this client's site the past two days. We have been breaking down traditional notions of requirements, engineering practices, quality assurance, organizational structure, and team structure. We have discussed self-organization, empowerment, and individual accountability.

As we were wrapping up this afternoon I could see that this lady was struggling. This transition was really going to impact her job and force her to reevaluate her management style and approach to project leadership. We talked briefly again about the idea of empowerment and self-organization and how she was going to have to learn to let go.

She turned to me and said… but Mike… they like it when I tell them what to do.

It was such a profoundly honest comment that told me volumes about her and the state of the team. This project manager derived a certain sense of self-worth from being the person that told everyone what to do. The team liked being told what to do because they were fundamentally absolved from any responsibility for the outcome. They were perfectly content to let the project manager do their thinking for them.

It was a great reminder to stay focused on what often runs underneath the arguments against agile. It is not always rational or logical. More often than not, people find themselves in situations of their own making. They are comfortable just where they are and many have been very successful under the current way of doing things. And you know what? Change can be scary… and it is always uncertain.

A year or so ago I was going through a rough time and came across a great passage from Machiavelli's "The Prince". This passage has often provided comfort when I've grown weary of leading change:

"And let it be noted that there is no more delicate matter to take in hand, nor more dangerous to conduct, nor more doubtful of success, than to set up as the leader in the introduction of changes. For he who innovates will be have for his enemies all those who are well off under that existing order of things, an only lukewarm supporters in those who might be better off under the new?"

Original Post at Artem's Agile Software Development.

Photo Credit: http://max-redheads.blogspot.com/

Subscribe to this blog Subscribe to Leading Agile

Monday, December 8, 2008

The Secret to Organizational Agility

Are you ready... here it is... to be agile you must... break dependencies at all costs!

Dependencies are created when any two discrete elements within your organization require each other to do all or part of their job. At the enterprise level, dependencies are everywhere. They are created by the very way we have decided to structure our businesses and how we setup and execute our project work. This makes them very hard to identify and even harder to remove.

I believe that breaking our dependency on dependencies is the core challenge associated with orchestrating any sustainable enterprise agile transition.

Agile transitions don't fail because Scrum is insufficient. They don't fail because people have not sufficiently applied the right XP engineering practices. Our problem is not a fundamental misunderstanding of the Agile Manifesto nor an unwillingness to become the right kind of agile leaders.

While any given organization may have some or all of these problems, they are not our primary concern.

The underlying issue is that agile project management principles, agile engineering practices, and agile leadership philosophies assume you have already eliminated your dependencies! Most teams are trying to become agile without validating that core underlying assumption, no one has even told them they should try!

Think about how we describe our ideal agile implementation...

First, we start with a small team of cross functional individuals with sufficient skills such that anyone can work on any part of the system. Next we allow this team to only work only on a single project during any given sprint.

We then grant this team a dedicated product owner empowered to make decisions on behalf of the business. We allow them to work on small independent functional requirements which can be reprioritized at any time.

We give this team an empowering individual tasked with removing any organizational challenges the team might encounter. We remove any process constraints and allow them to do the work any way they want as long as they deliver working software.

Lastly, we assume they have an object oriented architecture that lends itself to test driven design, continuous integration, and constant refactoring.

This scenario perfectly describes a team with no dependencies. They have 100% of everything they need to get the job done.

Let's look at what many teams deal with trying to adopt agile...

People are typically part of a team of specialists that are matrixed into a cross functional project team. Because these people are specialists, their services are not needed 100% of the time. To maximize the utilization of the individual, they are assigned to multiple projects and any number of teams.

Product owners are doing market research, meeting with customers, and attending trade shows. The team is left with a less than empowered business analyst to make the decisions for the business. In reality, the product owner was just a proxy for a large group of uninvolved stakeholders anyway. No one gets access to real customers or real market data.

Many teams are trying to sprint through product development using a traditional MRD or PRD. They are not using requirements written as functional threads of system behavior that can fully tested at the end of the sprint. These requirements are not able to be reprioritized as we learn more about the evolving system.

Many teams are working with traditional project managers who are doing their best to be agile, but have been trained to manage dependencies and tell people what to do. Even if they want to be agile, they are not usually empowered to do anything about the real impediments the project teams are working through.

Teams are trying to be agile with tightly coupled software architectures, insufficient test coverage, legacy code bases, and unable to do a daily build.

This perfectly describes a team operating under the crushing weight of dependencies created by flawed organizational assumptions.

Let's look at some of our common assumptions that lead to unnecessary dependencies….

We assume that we must optimize for individual performance and therefore we matrix team members across projects. This creates dependencies between projects that did not have to exist. We find ourselves managing who is on what project and when they will be available for other projects. We create a network of dependencies [between projects] that restricts our ability to change course. Any change has a series of painful cascading impacts on our portfolio.

We assume parts of our solution are just too complicated and must be handled by specialists. We choose to assign certain people to specific components. By default, we create dependencies between products that share the same components. We also create dependencies between requirements that impact the same component. We create project dependencies between teams (and between team members) when we have these specialists assigned to a team of specialists.

We assume that our product owners are too busy for the team so we assign someone else to proxy for the business. We create a dependency between the team and the business that results in a tendency to over-document and manage the relationship between contracts. When contracts are used we create dependencies between the team and the business that must be maintained, enforced, and put under change management.

We assume the market is demanding all the features at one time so we do not focus on small functional slices across the entire systems architecture. Why bother, it all has to be done anyway? This thinking leads us to consider everything before we can consider building anything. When the requirements are all dependent on each other, there is no need to prioritize, no ability to change our minds, and no ability to learn from the emerging system. That big up front design document starts to look pretty reasonable.

We assume that architectures cannot be decoupled or that test coverage is too expensive. This causes us to think about making every change when we are making any change. Batched changes are made outside the context of working software. They are integrated and tested all at once... probably near the end fo the project. By creating dependencies between code changes, we loose the ability to learn from our mistakes, refactor, and hold teams accountable for outcomes.

Dependencies force us to measure hours worked, or modules delivered, or lines of code, when what we really want to measure is working software.

Why does all this matter?


Some of these dependencies are real. Many could take years to overcome. Just realize that every dependency you accept, every one you choose to leave in place, is going to fundamentally limit your ability to adopt agile methods.

Every single one will require a trade-off that will reduce your effectiveness and ability to respond to change.

By focusing on project management technique, engineering practices, or even leadership philosophy first… we miss the mark. We are inclined to pick from a smorgasbord of tactics and choose what can work for our particular organization. We are not forced to deal with the foundational problem, and therefore pick and choose our way into a meaningless agile implementation, one that will not deliver the essential value the organization is trying to deliver.

By focusing on the relentless pursuit and elimination of dependencies, we position our organization to potentially adopt ALL of the agile best practices. We can then pick and choose based on our values and principles, not on the constraints of our tangled up dependency based organizations!

Reduce dependencies at all costs. This is going to become my mantra for 2009. Expect to hear more on this topic as the year unfolds!

Subscribe to this blog Subscribe to Leading Agile

Monday, December 1, 2008

Why Project Managers Like Documentation

Reposted from Artem's Agile Software Development Blog

Most software project managers have very little power in an organization. They are on the hook for delivery, but have very little control over the actual resources required to get the job done. Project managers have to broker agreements, hold people accountable, and get people to do things that they are not otherwise incented to do.

Fixed Constraints and Up Front Design

Requirements documents are created early, and often with little input from the delivery team. Budgets are set and timelines negotiated, prior to the project team even being engaged.

In other words… project managers are in a pretty bad spot. They are trying to manage in a situation where the triple constraints are all set for them, they have little direct control over resources, and the resources they have are matrixed across several projects with competing priorities and differing agendas.

Project Managers Want to Succeed

Project managers are often very driven people. They are detailed oriented and focused. Believe it or not, project managers don't want to fail. Project managers are people that are committed to being successful… they want to deliver and do a good job.

So… what can a project manager do to ensure success? Focus on paperwork and process.

Paperwork and Process Defines Success

Because project managers are in an impossible situation, they retreat into self-preservation mode. They focus on comprehensive documentation and sign-off to hold people accountable. They put process and documentation over working software because the constraints of the organization ensured failure from the very beginning.

Over time, people get used to operating in this manner. Project managers get promoted and run PMOs. They run development organizations. They become a part of the business. The challenge is that they carry these self-preservation attitudes with them as they move up the ranks.

We have ended up with a bunch of leaders that think this is the way software gets created. They think that paperwork and process is the way software gets delivered to market. The thinking is so pervasive, no one even questions how we got here.

Changing Behavior Will Take Time

If we want to change this behavior and begin to tear down these walls, we need to encourage transparency and create an environment of trust. Project managers need to be able to bring the difficult issues to the business and be assured that the business will not punish them for their integrity.

Companies need to create a culture where assumptions get validated, and when they are not valid, the plan changes. We need to create a culture where risk is managed, but when it is realized, we accept responsibility for our mitigation strategies. We can talk about change management, but we have to understand that change is not free.

I understand it is difficult to run an uncertain business. We can't wish that uncertainty away and we need structures and frameworks to help deal with it. Agile project management is just such a framework. Agile help us embrace uncertainty and deal with it.

Holding Project Managers Accountable

Hold project managers accountable for effectively managing assumptions and risk, good decision making, and proper escalation to the right people. Hold them accountable for how well they communicate and keep the business informed. Reward them for coming up with creative proposals and implementing effective strategies.

Unless we want mountains of documentation no one will ever read, let's stop holding project managers accountable for plans that should never have been laid in the first place.

Subscribe to this blog

Photo Credit: www.polaricecapz.com/books_b.html Subscribe to Leading Agile

Wednesday, November 26, 2008

Agile PMP Webinar

If you missed my talk on the Agile PMP: Teaching an Old Dog New Tricks, the one I did down in Orlando a few weeks ago, you are going to get a second chance. I am doing a shortened version of the talk for the ASPE webinar series. The talk will be on December 18th at 12:00 PM Eastern time.

I'll look forward to having you join us... here is a brief abstract and info on how to register.

PMI / Agile Transition Webinar:
The Agile PMP: Teaching an Old Dog New Tricks
(Live Event: December 18, 2008 | Speaker: Mike Cottmeyer)

Building on the principles of PMI® and the Project Management Body of Knowledge (PMBOK), Mike Cottmeyer 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.

Webinar Title: The Agile PMP: Teaching an Old Dog New Tricks
Date: December 18, 2008 12:00 pm, EST
Cost: Free
Register: HERE

Additional Resources:

  • Mike Cottmeyer's blog post going over some of the base information for his presentation at Agile Development Practices in Orlando, FL
  • Mike Griffith's blog on the PMI/Agile SIG.

The picture on this post is also from Mike Griffith's blog.

Subscribe to this blog Subscribe to Leading Agile

Friday, November 21, 2008

Watch Out for Excessive AT&T/iPhone Roaming Charges

Not an agile post, I originally did this for my personal blog, but thought I would share this story anyway... hope you enjoy!

The past couple of years I have had the opportunity to do some pretty cool business travel.

Early in 2006 I had the opportunity to take a business trip to India. We travelled to Pune through New York and New Delhi. We were fortunate to have a day of sightseeing in New Delhi and an extra day for a side trip to see the Taj Mahal. The way home included an extended layover in Paris where we visited the Louvre and the Eifel Tower.

The following year, I took a similar trip to Pune, but travelled through New York and Mumbai, rather than New Delhi. The trip home included an extended vacation with my wife through London and Paris. At that time I had been using a Blackberry 8700 and was amazed that no matter where I went, even in remote areas of India, I almost always had coverage.

At the time I was not too concerned about the cost of international data because I knew it was expensable through the company. Once the bills came in, they were higher than normal (that would be expected) but not outrageously high. As I recall, both two week trips cost around a couple hundred dollars.

This year I made the switch from the Blackberry to the iPhone and have learned a few hard lessons about the differences in how these devices pass data.

A few months ago I spent a week at the Agile 2008 conference in Toronto Canada. While there I made very few phone calls but figured I would use my iPhone for email and internet, rather than worry about connecting my laptop to the hotel WiFi. Bad mistake. 5 days into the trip I got a text message from AT&T telling me my international data roaming was getting very high. I called AT&T and found out I had already racked up over $800 of international data usage.

You can imagine, I was totally floored. I had traveled all over India and Europe for weeks at a time and only incurred a few hundred dollars. Here I am in Canada with an $800 data bill. Pretty shocking.

Here is something to keep in mind when you are traveling to Canada planning to use your iPhone: International voice roaming in Canada is $0.59/minute. High, but pretty much to be expected. International data roaming is $.0195/KB. That is about $20/MB. 1 MB is about the size of a small digital photo downloaded in an email attachment. No wonder my data bill was that high.

AT&T offers global data add-ons for the iPhone, they are price as follows:

  • $24.99/month: 20MB Data Global Add-On gives you 20MB of usage within over 65 countries
  • $59.99/month: 50MB Data Global Add-On gives you 50MB of usage within over 65 countries
  • $119.99/month: 100 MB Data Global Add-On1 gives you 100MB of usage within over 65 countries
  • $199.99/month: 200 MB Data Global Add-On1 gives you 200MB of usage within over 65 countries
Just to give another example from the AT&T website. Opening an email with a 5 megapixel picture in it, or downloading a 3 minute video on YouTube, each takes about 2MB of data. The cost would be almost $40, based on pay-per-use international data rates of $.0195/KB. That same photo downloaded on an international data plan would cost between $2.49 and $1.99.

One AT&T customer cautions that these plans are not intended for the occasional international traveler. Overseas data charges can take up to 90 days to post to your account. If you cancel your data plan when you return from an overseas trip, the charges will be billed to your account at the rate currently active on your account, not at the time the data was actually used. Had you paid $59.99 for a 50 MB rate plan in January, cancelled the plan in February, and the data usage hits your bill in March… you would be charged over $800 for the usage, even though you had the plan at the time the usage was incurred.

There seem to be several factors that caused the difference between the telecom expense from my previous international travels and my most recent trip to Canada:

The iPhone is a much better Internet browsing device that the Blackberry (at least a couple of years ago). It is also much faster in that the 3G speeds allow you to hit full blown web pages at desktop speeds. This encourages more frequent use on higher bandwidth sites, and therefore more data charges. Also, this is unsubstantiated, but I have read that the Blackberry servers compress data before it is sent to the Blackberry. To the best of my knowledge, there is no such compression mechanism for the iPhone.

In short, be careful when you travel internationally that you do not get hit with any unexpected data charged. I have learned how to turn off all locations services, push email, and I no longer use web browsing when I am abroad.

The AT&T website publishes a set of iPhone tips for international data roamers. Here is the URL and I have attached a copy for your reading convenience:

http://www.wireless.att.com/learn/popups/international-iphone-tips.jsp

How iPhone Users Can Minimize International Data Charges:

  • Turn Data Roaming "OFF": Be sure to download and install the latest version of iPhone software from iTunes. By default, this setting for international data roaming will be in the "OFF" position. To turn data roaming "ON/OFF" tap on Settings>General>Network>Data Roaming
  • Utilize Wi-Fi Instead of 3G/GPRS/EDGE: Wi-Fi is available in many international airports, hotels and restaurants to browse the web or check email.
  • Turn Fetch New Data "OFF": Check email and sync contacts and calendars manually instead of having the data pushed to your iPhone automatically. This way you can control the flow of data coming to your iPhone.
  • To turn off the Auto-Check functionality tap on Settings>Fetch New Data, change Push to “OFF” and Select to Fetch Manually
  • Consider Purchasing an International Data Package: Purchasing an international data package can significantly reduce the cost of using data abroad. AT&T now offers four discount international data packages. The 20 MB package is $24.99 per month, the 50 MB package is $59.99 per month, 100 MB package is $119.99 per month, and the 200 MB package is $199.99 per month. See att.com/worldpackages for details and international roaming rates.
  • Reset the Usage Tracker to Zero: When you arrive overseas access the usage tracker in the general settings menu & select reset statistics. This will enable you to track your estimated data usage.
  • To reset Usage Tracker to Zero tap on Settings>General>Usage>Reset
Subscribe to this blog Subscribe to Leading Agile

Tuesday, November 18, 2008

Slideshare Beta.... The Agile PMP: Teaching an Old Dog New Tricks

The past few days, I have been trying to figure out the best way to upload (and share) slide show presentations with my Leading Agile readers. LinkedIn offers a SlideShare plug-in but I have to send people to my LinkedIn profile in order to see them. I would rather direct traffic someplace that adds more value.

I am experimenting now with a full blown SlideShare account to see if I can embed a link right into this blog post. Please give me you feedback on how it works out. Once I test this out on http://www.leadingagile.com... we'll give it a try on http://blog.versionone.com.

This is my deck from last weeks Agile Development Practices conference titled 'The Agile PMP: Teaching an Old Dog New Tricks. The talk went really well and got outstanding feedback. Please post a reply if you have technical difficulties


Subscribe to this blog Subscribe to Leading Agile

Monday, November 17, 2008

More Talking to Project Managers

Here is my last post for Artem's Agile Software Development... republished here for the benefit of my Leading Agile readers.

Last post we explored some ways to introduce agile concepts to traditional project managers and how to make a case for agile in a way that has a chance to really resonate. We explored how to discuss time, cost, and scope… talked a little about dealing with uncertainty… and a little about the factors that are really constraining our projects.

If you are interested in catching up with the conversation, go back and take a look at my post "How to Talk to Project Managers" at http://agilesoftwaredevelopment.com/blog/mcottmeyer/how-talk-project-man...

This past Tuesday, I was up in Vancouver doing a workshop on these very topics. About half the class self-identified as a PMP certified project manager… the others were either uncertified project managers or development leads. Most of the folks rated themselves a three or four (out of ten) on their agile expertise. We had a few folks in the class that rated their knowledge in the five to eight range, and after doing the course, I agreed with their assessment.

Most of the people in the course were there to learn more about agile or to learn how to sell agile in their organizations. They wanted to understand the agile value proposition and how to go back and communicate agile in a way that really resonated with their businesses. We were off to a good start.

My talk generally followed the outline from "How to talk to Project Managers". People were taking notes and seemed engaged... but, sometime around lunch things started getting more difficult. After laying the foundation around the triple constraints, uncertainty, and project drivers; I had hoped to move into agile principles and project management techniques. What I found is that I had left out a critical component of the discussion.

I had not addressed how their organizations were currently structured and the barriers this would introduce to agile adoption. I started talking about teamwork and collaboration and they were thinking about matrixed organizations, task sequencing, and resource management… I had needed to address this issue head on and my failure to do this caused the class to spin a little out of control.

We ended up spending a great deal of time talking about merits of generalization and the challenges associated with specialization. We talked about how to deal with agile teams when some degree of specialization is required. We explored what it meant to be a team and what creating teams would mean for their organizations. We talked about the differences between iterative and incremental development versus agile development. We explored what it means to be a project manager in an agile organization.

What I learned was that there is a bunch more we needed to talk about before we could move to agile principles and practices. We needed to introduce a few more concepts before we started talking about agile project management. We needed to address matrixed organizations, building teams with specializing generalists, and the role of the project manager on an agile team.

Here is some thinking I've done on these topics over the past year:

http://www.leadingagile.com/2008/07/managing-too-much-complexity.html
http://www.leadingagile.com/2008/04/what-about-me.html
http://www.leadingagile.com/2008/10/agile-or-iterative-and-incremental.html
http://www.leadingagile.com/2008/06/project-managment-is-not-enough.html

Happy reading. Please comment on how you are talking to your organization about agile and what messages you have found that resonate. If I use something you submit in a talk, I make sure to credit your contribution.

Subscribe to this blog Subscribe to Leading Agile

Tuesday, November 11, 2008

Evolution of a Project Schedule

If you happen to be down in Orlando this week, and are planning to come to my talk on the Agile PMP, hold off reading this post. I am revamping my talk based on some feedback I received last week in Vancouver. I may use some of the images and explanations contained in this post to help explain agile project planning and how it is different. I wanted to write this out to clarify some of my thinking and get a feel if this line of reasoning will work.

You are getting the benefit of my trying to develop a thought ;-) Nothing better than thinking out loud to a few hundred people. I'll let you know how it goes after the talk. If you have any suggestions before tomorrow, I might be able to get them into the talk. If you have a comment, now is the time to post it.

Before I get going I want to explain a few things and give a few disclaimers. I used MS Project to create a series of illustrations that describe how a traditional project schedule might evolve into an agile project schedule. Let's be clear, I am not recommending that you use MS Project to manage agile projects. I don't need anyone freaking out that some agile guy is recommending MS Project for agile projects. That is not the case.

The reason I chose to start with MS Project is because the Gantt chart is the language many project managers understand. When the agile community talks agile to traditional project managers, we need to start where people are with tools they currently understand. It is not impossible to manage an agile project with MS Project, it is just that the underlying paradigm of the Gantt chart does not really work. The tool itself is not designed for collaboration

Traditional Waterfall Project Plan

Many project managers start with this level of understanding of a software development project plan. It makes good sense... you understand what you are going to build... you decide how you are going to build it... you build it... you test it... you see if the customer likes it... and if they do, you deploy it. Simple, huh?

I have managed projects this way and have had some success. To make this kind of project successful you need to have a great deal of certainty around what you are going to build. Change is not the friend of the waterfall project. You also need a great deal of stability in your project team. You can't have people going on and off your project, getting pulled into other work.

This typically means that your project better be pretty high in the organizational priority queue.

Often, our reality is that requirements do change and people are working on other projects. This makes our projects late and unpredictable. What is even more troubling is that we often don't find out they are late and over budget until it is too late to do anything about it. We need drive up predictability, deliver on shorter cycles, and get product to market faster. We need to change how we are thinking about delivery and change our project management approach.

The first evolution of the waterfall project plan is to break the project into smaller phases.

Delivering in Phases


This approach is designed solely to make our projects smaller and get product to market faster. Smaller is almost always better, but the phased plan suffers from many of the same problems as the waterfall plan. To make this approach work, you still need very stable requirements and a very predictable project team. This approach does not fundamentally solve the problem but it does help you realize it faster.

One of the core problems with the phased approach, as with the full blown waterfall approach, is that people are specialized and their specialty is not required 100% during the life of the project. This results in matrixed project teams and matrixed management. When people start working on other projects, and those projects run late, this impacts your ability to get people back when you need them.

To solve the problems with the phased approach, we need to not only deliver in shorter cycles, we need to keep people dedicated to our projects longer.

Overlapping Project Phases

This is where the overlapping phased approach comes in. A smart project manager will try to take some of the wait time out of the projects and overlap many of the activities. This is a good move, it keeps people focused on our projects, they stay busy more often, and are less likely to get pulled into other initiatives.

You can also see from the illustration that this kind of overlapping can have a significant impact on your timeline. You can usually get the work done sooner. This approach is a step in the right direction (from a utilization perspective) but does not solve our problem with brittle project plans that are resistant to change.

Shorten Phases into Iterations


This next step is an evolution of our project planning model but does not solve any more of our fundamental scheduling problems. It does allow us more focus on delivery and learn from the process of delivering working software. The thinking goes, if shorter phases are better, and overlapping phases make work go faster, then let's put this approach on steroids.

This approach is where I came to know iterative and incremental development. Early in my time as a software project manager, I understood iterative and incremental delivery as a series of shorter, overlapping waterfall projects. As a project manager on these projects, one of my main jobs was to manage that overlap and make sure that people understood what we were working on and when they needed to be available.

Even with this level of sophistication in our project planning, even with the resource utilization and timeline gains we have realized, our projects are still going to suffer when requirements change and schedules do not go according to plan. We have solved some of our resource and prioritization issues, but in the process have created a web of interdependencies that only serve to decrease our ability to effectively deal with change. In some ways, our project schedules become even more brittle than they were before.

Make Iterations Cross Functional

Iterative and incremental development is not supposed to be a series of overlapping waterfalls. The purpose of iterations is to have all skillsets on deck working toward a common iteration objective. Each iteration has a goal and a set of functionality that it is supposed to deliver. By having everyone focused on the same set of deliverables, we are able to deal with changes within the iteration itself... no one has moved onto other work... no one has to backtrack.

Dependencies are contained and cascading impacts can be kept to a minimum.

The iterative timeboxes are fixed and do not overlap. The team develops the set of functionality planned for that iteration and reviews the outcome of the iteration as a team. There is opportunity to learn from our progress and take any corrective actions before the next iteration begins. If change is introduced into the project, it gets planned for in the next iteration, and the impact of that change cascades down the project.

Most teams that are adopting agile find themselves at this level of project maturity. They have introduced iterative and incremental development but have not embraced some of the other organizational changes that are necessary to make it work. At this point, we still have not solved the problem of people being pulled away from our projects. We are at risk of being impacted by competing priorities... we are not able to function as a cohesive team.

Also... there is nothing particularly agile about this approach. We might still be doing a big up front design, traditional change management, and predictive project control. We can acknowledge it is a step in the right direction, but it is not agile.

Shorten Iterations Further and Focus on Value

Moving from iterative and incremental, to something that begins to look agile, you need to shorten even further your delivery cycles and create cross functional teams that are allocated to your projects 100%.

By shortening delivery cycles, the project manager can focus less on how product gets delivered and more on what is getting delivered and how fast. The team becomes accountable for meeting delivery objectives, and has more ability to decide what gets done and when. The team can make decision on how to best use their time to meet the goals of the iteration. The project manager gets real empirical data about how the project is progressing in the form of working software.

By keeping people 100% allocated to our projects, project managers need to focus less on activity sequencing, this can be delegated to the team. Giving this responsibility to the team allows them to be more creative solving problems. They stop being accountable for doing tasks, they become accountable for delivering value and meeting objectives. Project managers become more focused on tracking the flow of value, removing obstacles that could get in the way, and communicating and collaborating with the rest of the organization.

At this level of maturity, project managers are often still thinking with a predictive mindset. They are still trying to predict the flow of value and schedule all the iterations in advance, but have moved to a value focused planning model rather than an activity based planning model.

The Agile Project Plan

The agile project schedule is really just the sequence of project releases and iterations. It is the basic cadence of delivery the team has decided to organize around to deliver product. Features are kept in a sequenced backlog and scheduled iteration by iteration based on what we have learned about the evolving product. Project managers measure the flow of feature delivery, iteration by iteration, to communicate to the organization how the team is making progress.

If a change needs to be introduced to the project, it can be added to the backlog just like any other feature. The team collaborates with the business to frequently reprioritize. Because we focus on delivering working software on incredibly short cycles, the business gets to decide exactly when it wants to take product to market.

Shameless plug for VersionOne...

From a purely structural perspective, a tool like MS Project can be used to manage an agile project. When teams try to do this, they are usually at a step just before full blown agile adoption. They are still in a place where they are trying to predict the build order of features rather than managing the flow of value in collaboration with the business.

An agile project management tool like VersionOne Enterprise is focused more on creating a space for teams to collaborate, plan on short cycles, measure and assess their progress. Agile tooling is focused much less on predictive project planning and more on enabling communication between the team and between the team and the business.

In Conclusion

Explaining agile to traditional project managers can often be pretty challenging. You might get the core ideas across, but chances are you are going to get some blank stares and glassy eyed looks. These are smart people, it is not that they don't understand your words... they are struggling to find out how to get from here to there. They don't fully get why the kinds of activities they have always done don't always apply.

I hope this helps you understand how and why fast changing projects are different from traditional projects and why they cannot be managed using traditional approaches. Again, don't think of agile as replacing what you know, but adding to it, adding additional tools to your toolkit to help you deliver reliably in the face of uncertainty.

After writing all this, I am actually reconsidering using it tomorrow. I am not sure I can pull off this many words in light of what else I need to say. And like they say, this is long because I don't have time to make it any shorter. Thanks as always for reading!

Subscribe to this blog Subscribe to Leading Agile

Monday, November 10, 2008

Heading to Orlando for Agile Development Practices

Later today I am heading down to Orlando for the SQE Agile Development Practices Conference and the APLN Leadership Summit. Both should be fantastic events and I am looking forward to spending time with some of the industry's most influential thought leaders.

This is also a meaningful week for me, because after this trip, I have nothing else on the calendar for the remainder of the year. It has been a difficult past three months and I am glad that the ride is over. Some travel is just part of what I do, but these past few months have been really challenging for me personally. Normal work travel is beginning to look like pretty lightweight ;-)

So... in the absence of anything interesting or new this week, I wanted to point you guys to the abstract for my talk. I am following my passion with this one... helping non-agile types understand and make the switch to agility. If you are going to be in town, please come see me at my talk (I am on Wednesday afternoon). If you happen to miss my talk, make sure to stop by the VersionOne booth or even the Agile/PMI SIG discussion area. Hopefully by the time you find me at the VersionOne booth, I will know where the Agile/PMI SIG discussion area is located. I am looking forward to meeting you.

The Agile PMP: Teaching an Old Dog New Tricks

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.

Quick Bio:

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 Subscribe to Leading Agile

Thursday, November 6, 2008

A clarifying thought on agile adoption patterns...

When it comes to agile adoption, I have been thinking about this as a binary equation. Do you start with agile project structure or agile culture. I tend to be in the camp of people that think putting in agile structure can help foster agile thinking and behaviors.

My main point has always been that you create an environment where teams are delivering software on short cycles, throw in some good leadership and a solid vision for the future, and the agile behaviors will follow. My problem, is that as a project manager, I tend to think about things at the project level.

The past few weeks I have been out talking with a bunch of traditional project managers who are working in organizations trying to make the switch to agile. After spending time with these folks, I have had a clarifying thought (not a new thought) because on many levels I have understood this the entire time.

It is not so much project structure that is important, it is organizational alignment that really matters.

There are simple things at play like silos of functional teams, too much specialization, and matrixing people across several projects. We are also dealing with HR policy, career paths, and how we incent and reward our employees. When we say that agile cannot survive without executive level sponsorship… we are not asking for permission and a pep rally, we are asking them to lead change.

We need our executives to drive the hard change that will actually align our business with our software development and project management processes. Our leaders need to remove the organizational impediments that cause agile adoption to fail. Unless we are willing to make those kinds of changes, what can we really expect our project teams to do?

So... I still fall into the structure before culture camp. We just need to think about agile structure at a much higher level, a level where we have the ability to effect significant organizational change.

Subscribe to this blog Subscribe to Leading Agile

Thursday, October 30, 2008

How to Talk to Project Managers

Last week, I had had the distinct pleasure, the rare opportunity, to attend the PMI Global Congress in Denver, Colorado. I missed the deadline to propose a talk but there were at least 5 agile presentation happening over the course of the event. That is really good news. The PMI crowd is interested and trying to understand what this agile stuff is all about.

I was working the VersionOne booth, so while I had a full conference pass, I did not get to go to any of the talks... bummer.

Note: This post was written last week, so I am writing like I am there now. I decided to leave the language that way... hope it is not too distracting!

Talking to Project Managers

It has been really fun talking to all the folks that have come by to see our software. The people that stop to talk to us have already been exposed to agile on some level, so my perspective might be biased, but there are many more agile friendly people that I expected. Again, people are interested and want to know more.

After my first full day of meeting and greeting the conference attendees, there is one thing I would like to share with the agile community. When you talk to a traditional PM about agile project management, you need to be prepared to speak their language. While teamwork and collaboration are important, that is not the language of the PMI crowd. Empowerment is essential but can be very threatening to someone that is accustomed to being "in control".

I've found that a good place to start is with a discussion of the triple constraints.

Managing the Triple Constraints


Most traditional projects start with some assessment of scope; an assessment of what the stakeholders want to be built and what they are willing to invest money to have. From there the team does some analysis, figures out how big the request is, and what will be involved in building it. We do an assessment of the team, understand who is available (and when), and begin to lay our dependencies and calculate the critical path. From there we determine a date.

Ask your PM friend if that sounds much like their personal experience? They will inevitably nod 'yes' because that is what project managers are taught to do. Next ask them what happens after they communicate the project costs and delivery date of the project? I would bet money that their response will be somewhere along the lines of: we are given a date, we are given a budget, and then we start de-scoping the project.

Sometimes, if management really does not care about successful delivery, they are just given the date, and the budget, and are made to deliver all the requirements anyway.

Our Real Project Drivers

This is where you can explain that they are given the date and the budget because those were really the project constraints to begin with, not the requirements. We pretend the requirements are the constraint because, like most people, stakeholders hope that we will be able to get everything we want for what they are able to spend. Most of the time that is not the case.

So, where do we go from here? I will typically explain that agile project management starts with time and cost as the primary constraints and introduces techniques that enable the business, in partnership with the team, to decide what is the best set of requirements to build. After delivering this line, be prepared for the blank stares.

But I Have to Deliver Everything

The blank stares are because project managers are trained that they have to deliver everything. The executives demand it and the stakeholders cannot take the product to market unless they have everything. Now it is time for more questions. Ask them if that approach ever works? The answer is always 'no'. Ask them what happens when projects start this way. They will answer that the project is always late or over budget.

The reality is that by demanding ALL the scope, in the face of data that says otherwise, the business is making the implicit decision that their project will be late. You are generally not rewarded, or very popular with your stakeholders, if you bring this to their attention. Project managers are often incented to keep their heads down, do their best, and take their lumps when things are late.

As a quick aside this is the main reason most project managers rely so much on process and documentation. It allows them to cover themselves and be 'successful' in an impossible situation.

Most Project Managers Don't Make the Call

The reality in many businesses is that the project managers are not empowered to make the time, cost, and budget decision; and even if they bring these issues to the attention of senior management, they may be forced to proceed with the project anyway. This is your hook to talk about why agile can be such a valuable addition to their PM toolkit.

Delivering in short cycles and measuring done gives you real data about the health of your project. Managers often assume the team has overinflated the estimates. They assume the team is sandbagging. Agile gives you real empirical data about the status of your project and what the team is capable of delivering. Agile gives the business real data, and real options; options that go beyond just how late and over budget do you want the project to be.

Put the Business Back in Control

Agile gives the business the opportunity to effectively de-scope on the fly, to change their mind, to increase the cost of the project, to lower the cost of the project, to deliver early, to deliver late, or to kill the project all together if the business objectives cannot be met. They get this information early, when there is still time to deal with it and make a rational business decision.

The senior managers I have worked with will make good decisions when presented with good data and real alternatives. Bad decisions are made in low trust environments with poor information.

Now Let's Talk Agile

So, with that groundwork in place, you can start talking about teamwork, collaboration, and empowerment. You can start talking now about pair programming, continuous integration, and test driven development. Those things just don't mean much to the PM community until you help them understand how agile will fundamentally put them in a position to deliver quality projects: on time, on budget, and with the highest value that can possibly be delivered.

Until then, people are just not going to get it. So next time you are talking to someone with a PMP next to their name, make sure you are speaking a language they can really understand. The traditional community is willing to listen, we need to make the most of our opportunity.

Reposted from Artems Agile Software Development blog: http://www.agilesoftwaredevelopment.com

Subscribe to this blog Subscribe to Leading Agile

Wednesday, October 29, 2008

The Agile Project Plan

When we think about a project plan, what do we typically think about? Most people I talk with think a project plan is the schedule…. they think about the Gantt chart… the dependencies... and the critical path. The project plan can contain the schedule, but it is bigger than that. A project plan is a project manager's strategy for how the project is going to be run. It is a tailoring of the project management framework and describes what processes are going to be applied to run the project.

Business Case and Charter

My approach to writing project management plans is certainly not unique, but I am also not sure it is 100% standard. A good project management plan should start off with the business case and charter. This is a statement of the value we expect from the project and your authorization to move the project forward. These documents set context for the product vision and development activities. They establishe the project constraints, known risks, and any assumptions the business is making that could have an impact.

The Product Vision

The vision should describe the customers of the product and the value they will derive from using it. It might address the market segments you are going after and any business constraints the project is operating under. There can be quite a bit of overlap between this document, the business case, and the charter depending on how your team uses these artifacts. I like to think of the vision as the place we really get specific about the product and what it needs to actually do.

You can think of the vision as describing the actors or personas that will use the system, the major product themes, and major epics that are going to be delivered to market. I might also consider delivering a high level release plan to communicate the overall project schedule.

A Note on Documentation

When talking to an agile audience, I always try to be careful to state that these documents do not have to be 100 page monsters. If you are working with a small team and with an embedded and empowered product owner, these documents can live on a whiteboard or a wiki. If you are running a large, and possibly distributed program, you may want to leverage a wiki or some other lightweight electronic communication tool. If you are working in a traditional document driven organization, you might have to create something in document form. Just keep it as lightweight as possible.

The PM Knowledge Areas

Now comes where we describe how we are going to deliver to the expectations of the business. We need to state how we are going to manage cost, time, and scope and explain how our project will manage risk. We need to let the business know our strategy for communicating progress and how will we will ensure quality. We need to communicate what we are going to do if we need to buy anything or hire anybody into the team. We need to get on the same page about how we are going to make staffing decisions and how we will handle any HR issues along the way. We need to communicate how we are going to make sure everything is working together to deliver value.

These are not questions only for traditional teams, agile teams have to answer them too. Often, we assume these things because agile processes have the answers built in. It is just part of the process. Sometimes we need to be willing to explicitly communicate how we are going to proceed in language that the business understands. A lightweight project plan can be just such a tool.

It's all about communication

Sure... the plan might change... we want to preserve the ability to inspect and adapt. That is why we keep the artifact as lightweight as possible. The act of writing this stuff down makes sure that we think it all through, that we don't take anything for granted, that everyone has a common understanding of how we are going to approach the project.

I have had great success in the past walking my PMO through each of the PMI knowledge areas and documenting how our agile techniques are going to manage time, cost, scope, risk, quality, procurement, human resources, communication, and integration management. The point of the exercise is not about the document, it is about getting everyone on the same page, it is about communication and understanding.

After all... that should always be the point of documentation… communication and understanding.

Subscribe to this blog Subscribe to Leading Agile