Collection of articles on people and requirement management

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

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

 

33-gotowe-male
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

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…

Lion
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…

Stats

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

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

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

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.

Developers Aren’t Gonna Read It

Picture courtesy of austinevan@flickr

Developers are the customers – from time to time. They are the customers for product definition/specification team that is preparing technical specification documents. It doesn’t really matter whether you work in an agile or non-agile environment – I’m sure you have some technical documentation and the main goal of it is to answer developers’ questions on technical issues (e.g. how to configure some components to work with others, how to map fields from GUI forms to XML message, etc.) It also helps test or QA team to prepare acceptance tests and to verify whether what developers implemented is what was specified (I know it stinks a bit the waterfall but stay tuned – I will say something about agile documentation soon).

I would suggest you reading an article on TAGRI (They Aren’t Gonna Read It) by Scott W. Ambler – it’s really great. And in my post I’m going to give you real-life example from what I experienced regarding documentation. I will share with you my opinions of what kind of documentation sucks and what documents are really cool and useful (btw. my dream documentation is the one with which I’m able to find accurate information of my interest quickly and be able to put this information into my head in less than 10 minutes – the picture you see is a total contradiction of my dream – it’s a waterfall process).

Developers won’t read it

At the beginning of the project I met with the specification creators in order to discuss what we are going to deliver. They described me the project goals, business value and the requirements, of course. They also showed me two big books (sorry, specification docs) with around 300 pages in total. And the project was quite simple – it was basic CRU (Create, Read, Update) with one type of objects to be stored and queried. Believe me – the system was simple.

I was responsible for the web UI part of this system (100 pages) but had to understand also how the backend works (200 pages). Wow! That’s a lot of, for a simple system, to read – imagine how much time you need to read this. And it’s nothing comparing to how much time and effort it cost to produce it – and you still have no single line of code working.

So, did I read the documentation? I didn’t.

I didn’t have to because I preferred direct communication with the guys who know the system throughout. I didn’t have to read the documentation because the guy who specified the GUI prepared screen mockups and I knew exactly how the pages should look like. And I didn’t need 100 pages of documentation for it. I just needed couple of screen mockups – it was enough for me to deliver the software

Tests and examples are the best documentation ever

And they are not only the best documentation – they also define a design of the system to great extent. When I was integrating UI forms with the XML to the backend I was still not referring to any documentation. I just asked guys responsible for specification and preparation of tests to give me example messages (requests and responses). I got what I needed and basing on the examples I was able to integrate UI with the backend – simple. Here I will give kudos for the specification that explained how to map UI form fields into XML message (XML schema was not self-explanatory in many places e.g. I could store the phone number in different XML tags – I had to know which one I should fill). I also used a piece of documentation that explained what should be the format of input data – I had to validate user’s input somehow. But that was all I needed – I used 5% (roughly) of the overall documentation stack.

KISS (Keep It Stupid Simple)

In that simple project we had three different documents and I was finding discrepancies between them almost every day – yes, some of the fields, data types, etc. were specified in all three documents (often differently). The part developed by me was quite resistant to this because I was still keeping my one source of information. If I didn’t know something I just asked specification team – I wasn’t looking for the answer in the documentation because it would take more time and it appeared that I was asking questions that were mostly not covered by the documentation. Again, verbal communication was the best choice for me – I was able to fix some mistakes in the documentation on the fly – because I reported every technical problem I had to those guys – they were adjusting details according to technical constraints.

To summarize this point – keep it simple. Have one source of information and you will win. I do – every time I follow this rule.

Not all documentation sucks

That’s true – some level of documentation is necessary, as I showed it before. Some mappings are sometimes required, list of required fields, error codes, etc. Many of this can and should be covered by unit tests and automated GUI tests – but it’s pretty hard to record GUI tests not having it. Usually in waterfall-like process documentation is considered as a good – very important good. I don’t understand why? It doesn’t represent any business value for the customer (except the user’s guides) but a lot of people value documentation more than the working software. I think this is the reason they fail so often.

In my opinion the best documentation is the one that is very easily changeable. For example Word documents stored in Lotus Notes folders is a bad idea. Developers cannot easily change or even comment the specification/documentation – they should. I often faced the problem that I saw something really really stupid in the docs and I wanted to change it but I wasn’t able. Wiki is the best option here – it’s easily searchable (through many projects) and changeable. And if you want to have a Word doc – your business – just export the page to the format of your choice.

Solution

My main recommendation is to communicate verbally with people who know your product as often as you need; have one source of information – you will not be surprised by different requirements for the same thing; start with unit testing your code and keep your UI tests up to date; automate as many acceptance tests as possible – consult the results with customers (or customer proxies).

I’m not going to copy-paste the whole article but I totally support the Solution part of TAGRI article – I strongly recommend you reading it. I have nothing more to add.

What is your experience with documentation? Do you read huge stacks of papers your team lead gives you? What is the value of the documentation? Please, share your opinions here.

10 Ways to Save a Slipping Project

If anyone is looking for proof that agile and waterfall
are from different planets, you just need to check out this article
by Tom Mochal at TechRepublic, 10
ways to get a slipping project back on track
. Overtime was top of
this list, even if the deadline is months away! My first reaction was
to roll my eyes. But this raises the question, what do you do to save
a slipping project, especially if you are trapped in a waterfall?

Some of my "favorites" from TechRepublic’s
list were:

#6. Crash the schedule

#7. Fast track it

#8. Prevent all scope
change

#10. Scale back the scope
of work

"Crash the Schedule" and "Fast track
it" — They sound like something Dilbert’s manager would come up
with. Actually they amounted to adding people. Brooks told us long
ago in the Mythical Man Month that this is a sure recipe for
making a late project even later. "Prevent Scope Change" —
That’s what the change management system has been trying to do all
along. Why should it work now? "#10. Scale back the Scope" — you mean you are going to be honest about not being able to
deliver every whim of the customer for the time and money he
authorized? When all else fails, tell the truth! Better late than
never!

Is there a better way to get (even) a non-agile
project back on track? Absolutely. Even non-Agile projects can apply
agile principles! Here is my list (and yes, this is how I approach
challenged projects):

  1. Be there for your team.
    Nothing is more demotivating than a project leader who finds subtle
    ways to remind his team how much more important he is than they are.
    So come to meetings on time and stay until the end. Answer requests
    for information quickly, uphold your commitments (i.e. promises you
    make to the team), and look for ways to make yourself useful to your
    team. Recognizing and removing impediments to their progress is a
    good place to start.
  2. Ask the team.
    They know what problems they are having and can help identify
    solutions.
  3. Focus.
    Get everybody to agree on the priority of getting a release out,
    especially people outside the project. These people may have other
    priorities, in which case you will have to stand up to them, refuse
    work and eliminate distractions which is not related to getting the
    project done.
  4. Fix the target.
    What are the stories ("work flows" in waterfall-speak)
    which are really needed for the release? This is not quite the same
    as freezing the scope, because you might still eliminate features to
    make the deadline.
  5. Hold a Daily Stand-Up Meeting.
    15 Minutes, 3 Questions — What happened yesterday? What is your goal
    for today? What’s getting in the way? Ask, don’t tell. This helps
    your team focus on what they are doing and helps you recognize
    impediments to progress. Don’t criticize people for their
    answers and don’t tell them what to do. Otherwise it’s
    micro-management and your team may not tell
    you the truth. Let them identify the need to communicate with each
    other. Identify impediments that need your attention. Don’t discuss
    issues during the stand-up, but let people (including yourself)
    discuss things bilaterally afterwards as the need arises.
  6. Manage Progress with a big, visible task board
    Forget the electronic stuff. Use cards and corkboard. Put the
    highest priority functions at the top of the board. Make a card for
    each task needed to complete the feature, including testing and
    customer sign-off. Track the progress of each task from "Waiting",
    to "In Progress", to "Task-Finished." When all
    the tasks are done, then the feature is "Really-Done."

    Update the board daily. This gives you and everyone else an
    immediate, obvious picture of the state of your project.

  7. Prioritize.
    Decide what functionality is most important and get that finished
    first, then move on to lower priority features/issues/bugs.

  8. Make features, not inventory. Demonstrate finished (really-done)
    functionality at least every two weeks. Finished means tested and
    production quality code. After each demo, plan the functionality to
    be delivered in the next iteration.
  9. Leave the team alone.

    Once you have agreed with them what is to be delivered in the next
    two weeks, let them do their work. Don’t disrupt them with unplanned
    work, requests for new estimates, changed priorities or other
    distractions.

  10. Streamline decisions.
    Reduce the number of people empowered to make decisions about what
    should be in the product and what people should be working on. The
    closer to 1, the better.
  11. Build quality in.
    Get every function *really* done before handing it off to QA for
    acceptance testing. QA should confirm that the program works, but
    finding actual bugs should be the exception rather than the
    expectation. This way you don’t waste time fixing it later. The more
    time remaining until release, the more this one will pay off.

Well, that was eleven points. But
making a project successful is not about satisfying the bean
counters. It’s about producing value for your
customers and users. It’s about producing a success for your company.

Bonus Points

Bonus point one: upgrade you engineering practices. XP
offers an extensive tool box which can be applied to any software
development project. Test Driven Design, Test Driven Development,
Continuous Integration and Pair Programming head up a long list of
engineering practices which you can use to build better software.

Bonus point two: upgrade your management practices. My
experience has been that projects which start to adopt Scrum (even
without changes in the overall project structure) see positive
results almost immediately. These improvements become visible to the
customers within two to three months.

What About Overtime?

Let us remember the Maxwell Curve: Peak productivity in a Waterfall project occurs at around
60 hrs/week. In an Agile project, the peak productivity is much
higher and occurs around 35 hours/week. So I guess Waterfall project
management really does live on another planet. But given that
agilists can be substantially more productive, shouldn’t you be
trying to make your waterfall projects more agile?