Agile Software Development

5 tips for Iterating through the holidays

peterstev — Wed, 03 Dec 2008 06:00:57 +0000

As we get closer to the holiday season, external factors threaten to disrupt the sprint rhythm. People go on vacation, sprint meetings fall on or between the holidays, and company events pull the team away from project commitments. At the same time, the pressure rises to get affairs wrapped up by the end of the year. It’s time to get that release out, time to close that deal, time to define the next version.

Here are a couple of tips to help you get the through the holiday season with a minimum of additional (job) stress.

1. Shut down during holidays

Where I live, many companies shut down production during the holidays, and that might be an option for your team. Particularly if the product owner is not available, it is not possible to hold the sprint planning or review meetings.

There is a certain fairness to this approach. People need down time, and so does the Scrum Master, perhaps more than anyone else on the team. So if the product owner is going to spend two weeks on the ski slopes, why should you and the team do otherwise?

This approach is not without some drawbacks. It may be difficult to schedule the sprint review on the last day before the holidays, so you may have be some unstructured time or a sprint with a hole in it.

Obviously, there are contexts in which the end of the year is release time. I have met organizations which like to upgrade their IT infrastructure between Christmas and New Years, when most of the staff is on vacation, but that is a special case…

2. Extend the Sprint to skip the holidays

My first Scrum team had a 3 week sprint rhythm. This put our sprint review right between Christmas and New Years. Neither the Product Owner nor half the team members were available at that time. So we simply extended the sprint by a week, until after the year end holidays were finished. It turned out that after adjusting for vacations, the total capacity was about the same as a normal three week sprint. (Use this with caution, however. Breaking the rhythm is a challenge for everyone.)

3. Release Early

The same team was under pressure to get a release out before the end of the year? But when? The day before everyone goes off duty for 4 or 5 days or longer? In our case, that was the wrong answer, because of the support issues involved.

If you have high confidence in your test driven development, continuous integration and automated release process, then you can probably push a button to automatically install. Everyone will be happy, so you probably don’t have to worry about this.

But if your users include the general public and user support after deployment is an issue, then you probably want to release safely before (or after) the holidays. On call support during the holidays can be expensive and slow, compared to support during the course of normal development.

4. Expect a velocity hit

Even if you extend the sprint so that the number of working days is the same, your team will be less productive. Some of this is related to the distractions of the holiday season, both this is mostly due to the inefficiencies of not having the team together. Critical capacity (most especially the product owner) is not there, the team members cannot help each other with problems, and it always takes time to get back in the flow after an absence. It’s normal, don’t worry about it. Velocity is an average measurement, not an instantaneous one.

5. Pay down your [technical] debt

If your team is under a bit less pressure, now is the time to invest in better practices and raise the quality of your product. Improve your test coverage, experiment with Test Driven Development, automate your build process, or try out something else from the XP cookbook to improve your team’s capabilities.

A good place to start is a retrospective. Over the last 6 months, what has your team done well? Where does it need improvement? What is the biggest strength it can build on? Pick a topic and work it through during vacation period, so that when the New Year starts, you can actually apply these techniques to have a positive impact on your velocity and quality.

Summary

The holidays are anything but normal, but with a little forethought, you and your Product Owner can keep the team intelligently occupied and contribute effectively to the development of the product, even during the holiday season.

What Motivates (Some of) Us

JurgenAppelo — Tue, 02 Dec 2008 06:00:02 +0000

A number of weeks ago I asked readers to tell me what motivates them. The most original/inspiring contribution was awarded with $100 worth of software development books. Some of my colleagues acted as an independent jury, and Russell Ball, the author of the Caffeinated Coder blog, was selected as the winner, because of the great blog post he wrote on this subject. (And Russell's blatant attampts at unashamed begging did not even make a difference!)

In this post I want to share some highlights of the many emails that I got. The list below should serve as a reminder that your team members' motivation is often very personal, and as undefineable, unpredictable (and ridiculous) as their tastes in food, music, and (wo)men. On the other hand, the list can also serve as a sanity check for our own motivation. Software development is a great profession. If you look at this list, isn't it hard to be not motivated...?

The original question:
What is it that gets you motivated to do your job really well?

Note: most people sent me large emails with many reasons for motivation. But these particular lines, hand-picked from those emails, somehow grabbed my attention...

Seeing you have made a difference in this transient life. (James Soh)
The feeling of control that I have over the computer when I code. (Hrishikesh Barua)
The main part of my motivation comes from knowing that I can implement things that make people's lives easier. (Jeremiah Dodds)
The biggest motivation is pride. [...] It's the honor code that binds and also, and most importantly, you. You're the biggest motivation to yourself. (Bogdan Nicolau)
The personal desire (or more like the attitude) to become better on both a professional and personal level. You want to become a better person. (Angelo Anolin)
To participate in the design process, give my opinion and get listened to, even if I'm still young and newly arrived. (Sébastien)
My boss tries to motivate me with books. I make a list of what will be ordered, and when the books arrive they will be first on my table. When I see the pile of books it makes me happy. (Marek)
When I am so absorbed in my work that time flies by and I suddenly realize that 4 hours have gone by when it only felt like 10 minutes. (Russell Ball)
"It's not the strongest of the species that survive, but those most able to adapt." - My answer is Adaptation. (Minseok Choi)
Treating me as a human and not as another "Resource" by project managers. (Krishnan Thodla)
Success - It has a self-catalytic effect. One success will boost your confidence. (Rejeev Divakaran)
For me there's nothing more rewarding than others who like what I'm creating. (Florian Feigenbutz)
Basically, the end result of my work is an expression of me, much like a painting is an expression of its painter. (Rolando Caloca Olivares)
The rush of finding the solution to that problem that everyone else was frustrated by. (Bill Colacci)
The CEO of the company I work for. [...] He is the shining example I try to live up to. And he inspires me to do my work just that tiny bit better every day. (Sonja)
A word of "Thank you" from end-users. (Sung)
When a task/business trip/debug session or something else is finished. [...] Doing my job REALLY well and feeling that I deserve free time is for me the main motivation. (Vadym Shkil)
Simplicity! To create something as simple as possible, but still delivering enough value. (Carl Byström)
I'm motivated by the fact that, compared with all those google engineers and a-list bloggers, I still suck. That's ok, since I'm still at the beginning of my career, but I want to get better constantly. (Michael)
When I meet someone who actually uses our web sites, and really really likes them. (Jan Miczaika)
Money. I know, this doesn't sound like a great inspiration to many. [...] I know there are people who can't be motivated by money. Kudos to them. I, on the other hand, am living in a real world, with house mortgage to pay, myself to feed, and bills to cover. [...] If I can get a large sum of money for doing a good job, then that will definitely boost my morale. (Ngu Soon Hui)
Trust from a manager. I am especially referring to the time after a project is completed... if the project was done successfully, being trusted with another critical project and more responsibility on the project. (Brad Schafbuch)
My passion for software engineering, especially in PM methodology & Process. (Red River)
Adding a real new value to the world, by doing something I enjoy. (Emad Alashi)
An active collaborating, self-improving and happy development team, using new technologies to bring our products and new features faster to market. (Henk J. Meulenkamp)
Seeing the most jaded, beaten-up, grumpy grey haired old waiting-for-retirement public servant in the institution I work at break out of the boundaries they'd created for their position and create something new. (Karl Katzke)
A token of appreciation from all the stakeholders when a milestone is achieved. (Ramesh)
My love for software. (Vasileios Dimitriadis)

As I said, I received much more than this. (I trust you will thank me for not copy-pasting everything.) This is just a non-random sample, but it nicely reflects the diversity of people's motivation in software development.

(photo by Martin Kingsley)

Collection of articles on people and requirement management

Artem — Sun, 30 Nov 2008 15:53:43 +0000

Our web-site is publishing advices on Agile software development for over 3 years and there is a large set of useful articles that are not very easy to find. This weekend I digged through our archive and gathered the best of the best articles to the new pages focused on managing people and things in Agile. Enjoy!

Also it would be very kind of you to take a moment and tell (in the comments) what you think about the usefulness of these link collections.

"I know it doesn't work but it's done" - a story about the definition of done

pbielicki — Fri, 28 Nov 2008 08:42:24 +0000

Picture courtesy of orinrobertjohn@flickr

Some time ago I was talking to engineers responsible for some part of the software and I was asking when they will be ready for production. In other words I asked them when their features will be ready. They told me that they are ready now. What was my surprise when I tried to test their software and discovered that about 50% of cases were not working at all. So I asked them why they told me that they are "done" when they haven't even implemented half of the planned features? They answered me: "We know it doesn't work but it's done - we implemented something so it's done. Now we have to work on quality i.e. implement rest of the features."

When I heard this I think I might have looked like the lady from the picture. I couldn't believe someone can think like this - if we implement one use case out of one hundred we can consider the project done? The rest is the "quality"? I don't think so.

In this post I'll try to explain once again what is definition of done and why it's so important to have the same definition at least among all the people involved in the development of a single project.

Let's define "Done"

I would say that there is no one, good and universal definition of done. You can find some discussions in the Internet about it but you can see that everyone has it's own variation. So do I - in my view the most important things are (I will use "user story" word meaning every variation of request, use case, user story, etc.):

user story has to be implemented, today (no 99.9% is accepted)
user story has to be tested and no known bugs should exist
user story is ready to go into production, today
user story has to be ready to be presented to customer, today

Some explanation

User story has to be implemented - means that the code has to be committed to the version control system (like CVS, SVN, etc.), documentation should be available on Wiki or in the VCS, etc. It means that the output of the work done (whatever the work to be done was) must be available for anyone in the company to be downloaded in some way and checked. There must not be "I have it on my box - will publish it soon". Work must be committed and available for others.

User story has to be tested and no known bugs should exist - means that if you know about any bugs in the user story you're going to deliver - it's not done. If it exists in some subpart of the user story and you really need to deliver the working stuff, maybe you should split this user story into two, smaller ones. You must not deliver bugs to your customer - I'm talking about bugs you're aware of.

User story is ready to go into production - it means that it is ready to be deployed at any time from the time you stop talking. The wise thing would be if the working software is already deployed and tested in the production system - if it works - it's really done.

User story has to be ready to be presented to customer - it means that within 30 minutes (max) you are able to prepare presentation of working software to your customer. Of course, it requires you to have list of acceptance test ready and you know how to demo your software. The last point of it is very very important. Remember about it when defining all your user stories - you have to know HOW TO DEMO USER STORY - it will probably help you defining acceptance tests (e.g. user adds new item to the database using HTML form, then goes to the search panel and is able to find newly created item by its name, ....).

Wrap up

As I mentioned above good and universal definition of done probably does not exist but at least many resources agree on base principles. My definition of done is simple but I consider it quite powerful.

If you are interested in diving more into the subject I would recommend those two links from ScrumAlliance:

What do you think about my definition of done? If you have your own I would gladly read about it. Please share your opinions here.

Stories From The Battlefield: #1 - Make It Awesome

Janusz Gorycki — Thu, 27 Nov 2008 06:00:25 +0000

Photo (c) Janusz Gorycki

I would like to start a series of posts, named "Stories From The Battlefield". As the title suggests, I will be describing trails and tribulations of the agile team I am a part of. I want to write about our successes, failures, things we do right, things we struggle with - the real deal, sometimes great, but sometimes rough at the edges.

I hope such a series may be of value to many of our readers, especially those beginning their agile journey and hoping to learn on somebody else's mistakes.

There won't be much theory in here - this is being covered in sufficient detail by other authors on this site. Rather, I will concentrate more on "soft" aspects of what makes an agile team.

Let's start with a fundamental question of "Why?". This question is so basic and simple, that it sometimes eludes many of us in our day-to-day work routines. So why bother with an agile process? It does not make you produce software faster - despite popular myth. It does not necessarily bring higher quality - at least not automatically. It does not let you work less hard - on the contrary, you are supposed to be an efficient long-distance runner. Why then?

It all boils down to the fact that agile processes and practices let you deliver awesome software, much easier than any other processes.

The reason why your customers want you to write some software for them is that they want to get good value for their money - and that's pretty much the only thing they know. Requirement specs? They don't usually match the real needs of your customers. Even (especially?) if they make you sign contract that requires you to implement everything in the specs to the letter.

On numerous occasions, I have spent time reading hundreds if not thousands of pages of requirements specs, prepared over the course of several months, which don't define any sort of useable product. I had product backlogs with tens and hundreds of user stories, all properly prioritized and thought over. Yet - this backlog didn't last more than a couple of months before the original ordering and feature list fell apart and became irrelevant.

And you know what? This is normal, expected and you should be prepared for it every single time you sit down to start a new project.

Conversations with my daughter (the kid in the photo) before preparing breakfast in the morning, usually goes somewhat like this: "What do you want for breakfast honey?" "Well, I would like scrambled eggs. No, make it boiled. No, make it an omlette. You now what dad? I will have whatever you get me, just make it yummy". This is the key point - "make it yummy". Make it awesome, make them love it and make them come back to you for more good stuff.

How do you "make it awesome" then? Well, this is where it is important to remember that software development is an act of creation rather than manufacturing. You have to become a bit of an artist to make great software. Good taste and critical eye are important. User stories are not everything, they don't give you the full picture - despite the name, they don't tell "the whole story".

However, you don't need agile to be a software artist. What agile does make easier is facilitating good old-fashioned conversations. Conversations with the customers and inside your team. Actually, maintaining the efficient channels for conversation is the only valid reason to have a process (any process) for developing software. All other reasons are unimportant - even if your ScrumMasters tell you otherwise. In order to create awesome software, you have to spend time talking to many people about what you are doing, discuss how it addresses the needs of your target audience and make damn sure to present the customer with results of your work as often as possible.

Being profficient in communication is much more important than being a guru programmer, master-level Java-wrangler whose neurons run on CRL and who has written his first Lisp program at the young age of 6. More important even than having Six-Sigma Black-Belt, CMMI 10 Certified ScrumTrainer certifications.

Welcome Janusz

Artem — Thu, 27 Nov 2008 05:56:56 +0000

Dear readers

We just got a new regular contributor for AgileSoftwareDevelopment.com – Janusz Gorycki

Janusz Gorycki is a developer and team manager with over fourteen years of experience. He has spent most of that time at Intel Corporation, working in many areas, from telecommunications and embedded systems, to internal IT software development. While working for there, he was working together with our other regular contributor – Przemyslaw Bielicki. Janusz has left Intel with a group of colleagues to start a software development and consulting company Spartez where he works to this day. Janusz and his team have been using agile development methods for the last three years and you can find basic details about his company in the recently published interview.

Please, welcome Janusz and comment on his writing.

Artem, Editor-in-Chief

P.S.
If you are thinking about becoming a regular contributor to this site, shoot me an e-mail. We are particularly interested in joining forces with people with testing and UI-related experience.

You Weren't Meant to Have a Boss, But It Helps...

JurgenAppelo — Tue, 25 Nov 2008 06:00:17 +0000

When software development gods like Paul Graham tell you that people should not be managed, it makes you wonder what we need bosses for. However, after reading You Weren't Meant to Have a Boss I felt the terrible urge to justify my own position as a manager. (And if this post is not going to convince you, then at least it will make me feel better about myself.)

In his post Paul Graham compares employees to lions. He (rightfully) says that lions are not meant to be kept in zoos, and that lions in the wild seem to be "ten times more alive". (He probably meant "ten times more awake," a statement that, according to research, has some truth in it.) Similarly, Paul says, people are not meant to live in big companies. They seem to be "ten times more alive" as entrepreneurs in small startups.

Unfortunately, Paul's analogy is as far away removed from being accurate, as my mother is from being Yahoo's next CEO.

The small but not important fact that Paul Graham has overlooked is that many of the lions in Africa are living in managed ecosystems. These lions can live their "ten-times-more-lively" lives because there are ecological managers out there who are actually concerned about the well-being of Africa's wildlife. The wild animals that are not being managed find it very hard to survive and thrive in our dangerous world full of looters and poachers.

For entrepreneurs the world of business is just as hard and dangerous. I know. I've been such an entrepreneur. And even though it can be very motivating to be accountable only to yourself, having to take care of your own protection and survival is a task that's simply too daunting for most of us.

Some weeks ago, in another blog post, I asked readers to rate their motivation on a scale of 1 (bad) to 5 (excellent). I also asked them to rate their manager on a scale of -12 to +12 (using questions from the book First, Break All the Rules). My hypothesis was that bad managers will have both unmotivated and motivated people working with them, while good managers would have more motivated people. Well, here are the results of the test...

I regret that the number of actual respondents to the original post was ridiculously low, as compared to the number of readers. It seems you guys would rather enjoy a good laugh than actually do some honest thinking. Well, never mind. I believe these results are good enough to confirm what I already thought... good managers have only motivated people working with them. Bad managers have both motivated and unmotivated people. It turns out that good managers really make a difference! Bad managers don't, and their people will simply have to motivate themselves (if they can).

Now, I fully agree that people weren't meant to have a boss. But I also agree that, originally, people weren't meant to have a doctor, a dentist, and a hair dresser. (The only ones people were meant to have are their mother and a tax collector.) But having a (good) boss should certainly help people to feel good about their jobs. And of course, how to be a good boss is an entirely different subject altogether. But Paul Graham's conclusion that you're better off not having a boss, is as wrong as Jerry Yang holding hands with Steve Ballmer.

Lions weren't meant to be bossed over by natural reserve managers. But it's certainly helping...

(picture by giordanocapibaribe)

My First Agile Project Part 13: Reflecting on The Decline of Agile

mattgrommes — Mon, 24 Nov 2008 06:00:27 +0000

Picture courtesy of J.H.C. on flickr

Recently James Shore wrote an article called The Decline and Fall of Agile where he talked about how Agile, and Scrum in particular, is failing many companies. The main reason I started writing this series of articles on our team's experiences was to help myself examine why we'd had such a hard time with Scrum in various ways. In this part of My First Agile Project I'm going to go through Mr. Shore's article and compare it to our experiences.

In the article, Mr. Shore focuses mostly on the engineering aspects of Scrum, or lack thereof. In our experience, Scrum's lack of proscriptive engineering processes is hardly the biggest problem. It could be that we haven't had enough time to run into the walls of difficult-to-manage code that he's seen but thanks to some of the other problems we've had with shifting requirements and the like, we've all revisited chunks of our code during the project and we aren't slowing down because of it. Read on for more on Mr. Shore's essay and how I see it through the lens of our project. It may be that Agile is declining, but if so it isn't for the reasons he's seen.

According to Mr. Shore, our project should be failing due to the fact that we don't do the recommended XP-style engineering practices like Test First, or pair programming. At least, that's what I assume he's talking about since he never mentions which practices we should be doing. But I don't see that at all. I see our project having trouble because of incomplete control of the backlog and other "project management" centric issues that I've talked about many times (see Part 5: Our Top 5 Agile Mistakes).

I won't go so far as to say our code is a paragon of beauty or anything, but even without coding Test First (indeed, without many unit tests at all in some cases) and working mostly by ourselves we have a good code base. I've gone into my coworkers' code and made changes without spending all day on it and we've all taken over things from each other with usually just a minimal knowledge transfer. And since we've been working on this project for a year and a half now, we've gone back to old code multiple times. Despite the essay basically saying Scrum is deficient because it doesn't have XP's engineering practices, this hasn't been a problem for us.

I've always thought one of benefits of Agile was that it wasn't a bunch of rules you "had" to follow but Mr. Shore doesn't seem to feel the same way. He disparages the idea of taking Agile as a "Chinese buffet" where you take what you want and leave what you don't. Unfortunately for our project, we didn't know about some of the important things in Scrum/Agile but we also left behind things that we didn't and haven't needed without looking back. I like that there's wiggle room in Agile. I like that there's no checklist of approved procedures and methods for us to follow. In my experience everyone picks and chooses parts of methodologies that work for them, no matter what. Not every piece is going to fit your puzzle so you can't force it.

If not doing every part of a theoretically perfect "Agile method" means somebody is going to say we aren't doing Agile, fine. We'll still call it Agile, as I've never seen the problem that some people seem to have with the name. We're being agile in the dictionary definition so we'll call it Agile. It works for us, we like it and we're going to keep with it. We're also going to work on making it better for us if we can. And if we want to try out pair programming or writing tests first, we'll do that too and maybe we abandon it. We're being agile.

This brings me to my final point. Maybe he and I are looking at this from different perspectives but I don't like the talk about 'rescuing Scrum' and rehabilitating the Agile brand. The point of Agile is to help teams. If a team is having problems, the point should be to help them, not to make Agile look good. If parts of Agile or Scrum are helping, great. If something isn't going to make a team's life better, it should be left behind. I won't say anything about the certification parts of the essay beyond saying that if somebody thinks they can take a course and apply methods X, Y, and Z to their project and succeed, they're deluded. You have to live with it to determine what works and what doesn't. Then you can keep the parts that work. But if somebody wants to say we're not Agile because we're only doing what works for us, they can keep Agile and we'll keep working.

Thanks for reading. If you have comments on this post, and based on the sea of commentary around the web about it so far I imagine some of you do, please leave them in the comments below. I'm curious what you think. Thanks again and stay tuned next week for more of My First Agile Project.

The rise and flourishing of Agile

Artem — Sat, 22 Nov 2008 06:00:55 +0000

Picture courtesy of tommoka@Flickr

Lately the agile blogosphere buzzed with responses to the James Shore's article on decline and fall of Agile.

The article discusses the qualitative change in the way people apply Agile methods nowadays comparing to the past. Earlier people were asking coaches for learning Agile from scratch, were taking the complete XP or real Scrum package and were happy. Nowadays they install the basics of Scrum themselves usually taking into use just backlogs and stories, fail to get on the engineering practices, shared workspaces and the all important Deming’s Plan-Do-Check-Act (PDCA) cycle, struggle and, well, sometimes blame Agile for their pain. So is such contemporary Agile bad?

Well, yes and no. When more people start going to gym and do just their preferred exercises instead of preparing a program with the help of a coach and proper measurements, is it good or bad? In most of the cases these people will become healthier, than they were while doing just minor stretching at home. Sometimes they might get problems related to the unbalanced muscle development. For some of them the act of being in the gym and maybe this unbalanced muscle development will, however, draw attention to what other people do in the gym, maybe they'll look for a program on the web, or hire a coach. That might be too late, the people might miss the biggest benefits and some will just do the favorite hand exercises forever even if their legs can barely deliver them to the gym. However, majority of people will become at least a bit healthier.

To me the analogy to agile is rather straightforward. Agile has crossed the chasm indeed. The most guys trying agile nowadays are no early adopters willing to get all the benefits and carefully reading books. For those misapplying Scrum it might take a lot of time to get on the fully fledged Agile and some might never get there. So what, should they stay doing cowboy coding or waterfall despite the biggest ever market turbulence? Or should they wait until they learn enough to understand their real needs and hire a coach? I believe that frequent and reliable replanning, rapid cycles are good, not bad. The more companies try them, the more will find their way to making it also sustainable, dive into PDCA and improve greatly.

Nowadays I spend more time practicing SW development, than coaching different teams, however I stay in contact with huge amount of teams adopting Agile. Very rarely I hear that Scrum made them fail. At most I hear that people don't like Scrum much, but they don't like the idea of going back even more.

The fact that more companies are pursuing the direction is not a fall of Agile, but the rise of it. Every next round of new ideas in software development makes us better. There clearly will be the next hype and the next idea that will make us all even better (Lean to be the next hype, anyone?). Meanwhile the majority will get the small, but benefits of the current topic.

Why Project Managers Like Documentation

mcottmeyer — Fri, 21 Nov 2008 06:00:00 +0000

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.