To Motivate or Not to Demotivate


Some people tell me that “you cannot motivate a person“. You can only “remove the impediments that prevent a person from being motivated”. Or, in other words, “you can only eliminate demotivation“.

Well, I don’t agree!

Can you make a person happy? Or can you only eliminate the things that make her unhappy?

Can you make a person laugh? Or can you only eliminate the things that make him cry?

These sound like silly questions. But I have been told a number of times now that trying to motivate people is a bad idea. Yet, I simply could not imagine this to be true, given the fact that it is quite possible to (try to) make people happy, or to (try to) make them laugh.

Fortunately, I came across this article on Harvard Business Review. It appears that researcher Frederick Herzberg found out (fifty years ago already) that motivation and demotivation are two very different things:

The things that make people satisfied and motivated on the job are different in kind from the things that make them dissatisfied.

Ask workers what makes them unhappy at work, and you’ll hear about an annoying boss, a low salary, an uncomfortable work space, or stupid rules. Managed badly, environmental factors make people miserable, and they can certainly be demotivating. But even if managed brilliantly, they don’t motivate anybody to work much harder or smarter. People are motivated, instead, by interesting work, challenge, and increasing responsibility. These intrinsic factors answer people’s deep-seated need for growth and achievement.

So, it turns out that I’m right after all. Yay!! You cannot motivate a person by “eliminating demotivation”. Only taking away the things that make people dissatisfied, will simply result in people having neutral feelings towards their jobs. But that’s not enough. You also have to introduce things that motivate them. I have depicted this in another blog post as a Motivational Balance Sheet. The stuff that demotivates people (and I know they can always name something…) are on the left side of this balance sheet (which is personal and different for every employee). The things that motivate them are on the right side.


Motivating people means: removing things from the left side and adding things to the right side of the balance sheet.

The idea that you cannot motivate a person is wrong. I suspect that it has grown out of failed “motivational” initiatives like company slogans, posters, pep talks, performance reviews, and coffee cups with the text “teamwork” printed on it. I agree that those practices are probably not the best way to motivate most people. But there are bad ways and good ways to do things. And it’s the manager’s job to find out what the good ones are…

My First Agile Project Part 5: Our Top 5 Agile Mistakes

Picture courtesy of DWQ Online@flickr

In the previous parts of this series (1, 2, 3, 4), I went into a lot of the initial issues of how we ran our project and some of the things we did wrong. For Part 5, I’m going to focus on the 5 big mistakes we made in the project before I move onto another phase of the series.

For some background, the project was to integrate an off-the-shelf (but highly customizable) billing system to replace an aging custom Oracle forms app. This was our company’s first foray into Scrum and Agile as well as the first Agile experience for most of the development team. After we sailed past our second management-imposed deadline I started thinking about how we could correct our process for this project and the next ones we do, which led me to write it all down in this series. Keep reading for the Top 5 mistakes we made (in no particular order). Where possible I also give some detail about how we’ve worked on correcting our process. I hope this list helps you avoid these mistakes and make your own all-new ones. 🙂

1) Not tracking backlog
This was by far our biggest mistake I think. As I mentioned in Part 1, we failed to keep track of how much work we were adding to our backlog as we went along. We all assumed that since we were being Agile, we would add work as we fleshed out requirements and learned new capabilities. The problem came with not tracking how much work we were actually adding and comparing it to how much we were doing in each sprint. Without doing this, another of our mistakes – Scope Control – became much more of a problem than it might have. Not reassessing the backlog periodically meant we didn’t know how scope creep was really affecting the project, which meant a downward spiral of allowing the scope to creep, not knowing the effect of the new scope, allowing scope to creep more, etc., etc.

Since we realized a few months ago we should have been doing this, we’ve been keeping much better track of what gets added to the backlog and making sure we’re being as ruthless as we can about moving features to Post Go-Live and only working on important bugs. As a result we have a much better view of the finish line of the project.

2) Too much planning upfront, not enough later
In Part 2 I talked about our Inception Phase where we had our initial meetings to get a rough estimate of the integrations we would be doing and business requirements from other departments who would be using or relying on the billing system we were building. The mistake we made here was in the amount of requirements gathering we did and how we did it. We took a “snorkel, not dive” approach where we didn’t get too many details, which is a good approach. But we also made requirements documents complete with flow charts of integration program flow. These documents took much too long to write and didn’t end being used by the developers at all. Once we started sprinting and doing the work, we re-learned, or un-learned, pretty much everything in the documents but it all made more sense since we had the context of our code to work in.

Obviously not getting deep technical requirements up front means you need to get them later and this is part 2 of this mistake. We should have made it our practice to start getting requirements for the next sprint so we could start working without waiting. As it happened, our Product Owner/Subject Matter Expert was busy enough that we spent a lot of time waiting for requirements before we could start.

3) Boring business people with technical demos
I was tempted to make this mistake “Didn’t get management involved properly” but I think the early mistake was our demos. As I said in Part 4, we demoed everything we did that sprint, including infrastructure and behind-the-scenes integrations. This is good for the team to get to show off but it’s boring and turns off the business people and management. Once you’ve turned people off the process, it’s hard to get them back into it when you need their input. They’re still going to give you input, it’s just going to be later than you expect and usually after you think you’re done with the thing they should have seen 3 sprints ago.

Making the demos boring for the business folks also meant we failed to properly engage our upper management. We ignored this problem for too long and once they started getting more engaged, it was after the deadline had been blown and they weren’t aware. Not a good position to be in. Having more business focused demos wouldn’t have guaranteed anything but combining better demos with an insistence that the business / management people attend would have helped immensely.

4) Not estimating product backlog items
Part 1 of this series talked about how we were Doing 80% of Scrum. What we missed was a chunk of related, but separate processes around estimating and planning the backlog. This mistake is tied to a couple of the others because of this but we committed them all separately so I’m listing them separately. Our product backlog was basically just a list of work we had to do. Our Product Owner prioritized her most important items before the sprint planning meeting, then we moved the items we were going to do over and estimated them then. We didn’t estimate the backlog items ahead of time so she could know how hard we thought things were or so we could know how much more work was ahead of us. We had rough ideas that Integration X would take longer than Configuration Y but without real estimates, we couldn’t start harder things earlier in the process or push things that were hard and low priority off until later, both of which are vital for planning.

Since we’re in bug-fixing mode right now, we’re struggling with fixing this mistake more than with any of the others. I got a bunch of Planning Poker cards from Mike Cohn at Agile2008 and we’ve been trying to use those but it’s hard when the issues you’re estimating are bug fixes that only the person who worked on it originally knows about. If you have any suggestions on this, I’d love to hear about it in the comments.

5) Scope control
Not controlling the scope of the project, combined with our lack of estimates and not monitoring the growth of the backlog, constitute by far the largest cause of problems with our project. If we had been estimating our backlog items it would have helped us track the amount of work we had left, which would have helped us know when and what to remove from the backlog and keep to the next release. Since we didn’t do any of those things, the backlog grew too much, which pushed back the set of testing sprints we had scheduled, which pushed back the work that testing revealed, which put us in the position we’re in today, with a late project, lower morale, and lost credibility with management.

One factor I’m struggling to figure out is that the nature of our project seems to limit our ability to control scope. We’re doing an integration of a new billing system to replace an old system. This means there’s a set of existing functionality we have to duplicate in the new system that can’t be pushed to the next release. Also, being a billing system you have to get things right the first time. You can’t send out a partial invoice, for example, just because doing the whole thing will take too long. But I’m sure everybody thinks there are exceptional things about their particular project so I don’t want to fall into the trap of saying we can’t learn anything about how to control scope because our project is the exception. There’s always something that can be pushed back and if you’re doing the right things with estimation and monitoring your backlog it makes finding those things much, much easier.

We’ve been in bug-fixing / testing mode for the past few months and have tried much harder to keep things out of the backlog if they didn’t 100% need to be there. There’s still things going in, but now we make sure each thing is absolutely needed for go-live and everything else goes on the list for after.

Mistakes != Fail

We’ve made mistakes on our project, for sure. We’re not done yet so I’m sure we’ll make more. But we’re learning, which is the important thing for our next projects. As a team we’re all committed to Scrum and being Agile so we’re going to make the effort to improve our processes where we think it’ll help. The more technical-oriented aspects of Scrum are incredibly appealing to us as developers. Keeping a backlog, committing to work, keeping interruptions to a minimum, sprints; all of this we’ve done mostly correctly and we love how it’s worked over the past year and a half.

I’ve spent the last 5 parts of this series talking about the basics of how we ran our project and the lessons we’ve learned while we chugged along sprinting. Next time, I’m going to start talking about what happened once we missed our first deadline. We changed our process, halfway-unknowingly moved away from Scrum, and suffered for it until recently when we did a reset of our process and got mostly back on course. Stay tuned next week and as always, I’d love to hear any comments you have on this series. Thanks for reading.

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End Of Our Project

Weekly Agile Reading. Pack 15

Here is the top writing that caught my attention this week.

You might like having a look at the previous link packs as well.

Agile Game Development: Shared Infrastructure Teams

Tips on what to do if you work in a shared infrastructure team andwant to use the Agile methods

Why does a Scrum Process grind to a halt? | Kurt Nielsen " Scrum 4 You

A translation of the Kurt Nielsen's article on the reasons for Scrum adoption to decay over time.

Shock Therapy — Tobias Comment " Scrum 4 You

Discussion on the Jeff Sutherland's support for shock therapi as a way for adopting Scrum continues in the blogosphere.

InfoQ: Prioritizing Your Product Backlog

A 75 min long video of the Mike Cohn's talk

Goodbye mocks, Farewell stubs – ISerializable – Roy Osherove's Blog

If mocks and stubs and all the other terms are indeed too difficult to learn, consider going for simpler terms.

Microtechniques: typing

A professional always finds time for sharpening his tools

Google Testing Blog: Presubmit And Performance

Some teams at Google run tests before checking the code in. Including performance tests. They find it useful.

Delivering a Great Presentation

This week I am in London attending the Agile Business Conference. A few weeks ago I got to attend Agile 2008 in Toronto. Over the next few weeks I will be at the APLN Leadership Summit in Atlanta, the PMI Global Congress in Denver, the Vancouver Agile Conference, and the Better Software Conference down in Orlando.

That is a lot of conferences, a lot of speakers, and a lot of presentations.

If you are delivering a talk over the next few months, especially one that I am attending, please ask yourself the following question: are you are talking with the audience or are you talking at the audience? It is not enough to tell me what you think, you need to make me part of the conversation. Great speakers engage their audience, they show empathy, and they understand what their audience needs to take from the experience.

They deliver value.

Sometimes speakers are content to just get through their 45 minutes and be done with it. It is as if the audience does not exist. Far too many speakers don’t know how to really listen to their audience. It is the speaking equivalent of having a big up front design and following your plan to the end. As speakers we need to be able to adapt to the changing needs of our listeners.

In other words, You need to embody the change you are speaking about.

Here is an idea to consider… why not think about your talk like you would a software project? You could prepare your outline to be a high level roadmap… a vision if you will for where you plan to take the audience. Have a prioritized backlog of key points you want to make and information you want to deliver. Deliver your talk in short iterations and seek feedback from your audience. Adapt based on what you hear. Always… always… deliver value.

To hard? Maybe, but that is why you were asked to come talk in the first place!

For Peter’s take on creating presentations using user stories, click here

Predicting the team’s Velocity: yesterday’s weather method

Picture courtesy of aloriel@flickr

“How much software will you deliver in the next Sprints/iterations?” – do you often hear such questions? I do. And this question is really valuable especially for the project/product sponsors. But not only management likes knowing how much software they will deliver in the upcoming Sprints. Everybody (including development team members) likes to know the answer for questions like: “Where we will be in three months from now?”.

If you track your team’s Velocity you are able to answer such questions somewhat accurately, which is great. I personally don’t know better tool for answering presented questions than tracking development team’s Velocity.

Let me now explain how you can compute how much software your team will deliver in the next Sprints basing on the current team’s Velocity.

In Scrum, Velocity is how much product backlog effort a team can handle in one Sprint. Velocity is usually measured in story points or ideal days per Sprint – see Measures of size article. This way, if the team delivered software for 30 story points in the last Sprint their Velocity is 30.

What will be the weather today?
If you had to answer such question the best one would be that the weather today will be the same (or very similar) as yesterday (I assume you are not weather professional and you can only guess). The same is with Velocity and the amount of work you can predict doing in the upcoming Sprint. How much can you deliver? The same amount (or very similar) as in the previous Sprint – simple. You should take into account only the yesterday’s weather i.e. only the last Sprint. Note that the yesterday’s weather is one but not the only method to predict team’s Velocity.

Let’s consider the following example. Development team is composed of Mike, Martha, Paul, Josh and Julia. They worked on the project we are estimating following numbers of days (Sprint length is four weeks):

Team Member Days Worked
Mike 16
Martha 10
Paul 14
Josh 16
Juila 14

Sum: 70

They delivered software worth 25 story points (sp) i.e. the team’s current Velocity is 25. They claim that story for 3 sp is 80% done but this story is not DONE from the user’s perspective. This story is not and cannot be taken into the final sum of delivered software – therefore we still have 25 sp instead of 28 sp.

To summarize – the team delivered software worth 25 story points in 70 work days.

How many story points we can deliver next Sprint?
If everybody in the team is available exactly the same amount of time in the project in the upcoming Sprint you can assume that the Velocity will be about 25. Depending on the team’s experience in Scrum and their estimation skills it can vary i.e. if the Velocity of the beginner team will be 20 or 30 in the next Sprint it’s still OK. The Velocity usually stabilizes after few Sprints (but it can still fluctuate slightly – you will probably never have the same results in two subsequent Sprints) but even if we consider experienced Scrum team we can expect that the Velocity in the next Sprint can be slightly lower or higher than 25.

If the team members will not be available in the next Sprint the same amount of time because of many reasons, or the Sprint itself will be shorter (e.g. because of some national holidays) you should verify planned Velocity.

The following example is based on techniques used in a real project that was developed be me and my teammates at Intel. Of course, names and numbers are not real.
The first thing to do is to sum team members’ availability in the next Sprint. In four weeks we have 20 work days but there is one day of national holiday, therefore we have 19 work days. I also assume that team members can spend their 20% of time on developing some fresh stuff, learning, researching new technologies, etc. I will subtract 20% of time available for each time member separately. Let’s take a look at the following table:

Team Member Days Planned Days Available (-20%)
Mike 19 15
Martha 15 12
Paul 19 15
Josh 10 8
Juila 10 8

Sum: 58

If the team delivered software worth 25 story points during 70 work days it means that they can commit to ~21 story points during 58 work days in the next Sprint (58/70 * 25 = ~21). So, predicted Velocity is about 21 story points.

I assume that you have prioritized backlog of stories you have to deliver. I also assume that you know that you have to deliver them ordered by priority. This way you can start picking the stories until you collect about 21 story points in this example. It is really important to say about word – we are still in the estimation level, we don’t know the accuracy of our estimates. That’s why teams should commit to deliver about N story points.

What if the granularity does not allow you to hit exactly 21 story points? In this case you should take one smaller user story that is not at the top of your current backlog (still close to the top priorities ones) or exceed planned Velocity if and only if the team feels that can deliver selected stories. It is also pretty natural that the team can commit to 20 or 19 story points if they feel 21, 22 or 23 will be too much. Team is the most important here and they have the strongest deciding voice. At any rate the Velocity will be verified in four weeks i.e. at the end of next Sprint.

Wrap up
I hope this post helps you, I explained what Velocity is and how useful it is. I also hope you will be now able to answer the question “How much software will you deliver in the next Sprints?”. Use the force which is Velocity in this particular example.

If you need more detailed information about agile estimation, planning, Velocity and all similar topics you should read Mike Cohn’s book: Agile Estimating and Planning. It is brilliant and written with a very accessible language.

If you have some comments, want to ask some questions, something is not clear then comments section is all yours.

You may find following links valuable:


Creating the Scrum Product Backlog: Start with the Users!

When defining a product, it’s easy to write down list of features and call it the product backlog. It’s much harder to build a product which so deeply and profoundly meets the needs of its users that they just have to buy it. An agile team can use a three workshop process to create the Scrum product backlog. Workshop 1: Identify the users. Workshop 2: Figure out what they want. Workshop 3: define the feature mix which will get you to a product that the customers want as quickly as possible. Let’s start with Workshop 1, the Users.

Workshop 1: Who are the users?

A team of 3 or 4 people brainstorming can identify the potential users of a system very quickly and effectively. The ingredients:

  1. At least 2 people who understand the business
  2. At least 1 person with technical experience with similar products
  3. Desirable: the team who will implement the product
  4. A supply of cards or Post-Its
  5. A flip chart
  6. A pin board

Why should the whole team be present? Doesn’t that cost of lot of money? You are creating information about the product. If the team is present, they will have that information first hand. Otherwise, they will get the information transmitted later. Knowledge is like eggs. It spoils quickly and can (will!) be damaged in transit. And refrigeration costs money too. So it’s better to have them present, if possible.

Step 1: Brainstorm.

Everybody takes 3 to 5 minutes and writes down “users” – 1 user per card. When the time is up, everyone sticks their cards on the flip chart.

Step 2: Discuss.

Each person in the room describes “their” users in one or two sentences: who they are and what each one does or wants. 3 minutes per person should be enough.

Depending on the product you may need to differentiate based on roles or demographics. Continuing the earlier example, Congo Lomarate (CL) wants to optimize its processes and value chain integration. In this case, it is probably sufficient to talk about roles within the various companies, e.g. CL-Operations Staff, CL Operations Staff, Supplier Sales Manager, Supplier Operations Staff, Customer Operations Manager, Customer Sales Staff, and so on.

For a consumer product, the roles may split along demographic lines. For a dating site, users’ needs might depend heavily on sex, age, nationality, country of residence, marital status, sexual orientation, dating preferences, etc.

Sometimes it is useful to consider “extreme” cases: How would a spy find a date? Or a celebrity? What about a single who is HIV+ positive? Although the cases may be too narrow to target explicitly, they may bring out good ideas which are applicable beyond the immediate context.

Step 3: Consolidate and Prioritize

Some cases will be so similar, that don’t need to be considered separately. Group them together as one user.

Which of the users are going to generate or save money for the company? Which users can influence the success or failure of the product? These people may not need much functionality, but if you give them real exciter functions, they can have a deciding influence on the success of the product.

In the case of Congo Lomarate, operational staff at customers and suppliers will be the primary users. But their managers (and probably their executive management) will decide whether to deploy the system, so some good reporting features will help close the deal. The dating site will target people looking for a date, but other users, e.g. advertisers or marketing partners may play a critical role in the success of the system. They need functions, too.

Step 4: Review

Look at the whole. Are you happy with the users you’ve identified? Have you missed anybody? If you haven’t included them already, now is the time to add “administrative” users: The system administrator, support, system developers, Googlebot (a proxy for search engine optimization), etc.

I recently had a project in which discussions about the role of the system administrator lead to a discussion of who will do routine user administration. We discovered that it was possible to make the system largely ‘self-service’, reducing the role of customer support and thereby saving costs.

Administrative users will not earn money directly, but how the system handles their needs can have a substantial impact on the success of the system.

Next Steps

Especially if demographics play a role in your user roles, it may be desirable to create “personae” for each of the roles you consider important. So for a dating site, you might have “Jane, single, 25, attractive, wants to find a long term relationship” or “John, single 18, nerd, is afraid of girls but would like to find a geek chick to hack with.”

Whatever. Find a photo or draw a cartoon, and put the portraits up on the wall so you can identify with them as people.

So in about 2 or 3 hours you have created a list of users for your system and identified their primary objectives. Any surprises? Do you have other strategies? What works for you?

How to Handle Many Simultaneous Projects

Agile software development methods tell you how to run your projects. But they all do that from a single-project perspective. What if your organization runs multiple projects at the same time? Do the agile practices still hold in such a case?

Our organization consists of 220 people, spread over two locations. We specialize in doing small fixed-price projects, most of them web-based. At any time we have at least fifty different projects running simultaneously, with lots of other projects in “sleep-mode” (either waiting for resources, or waiting for customer input). Handling fifty different projects creates a lot of noise. There are always conflicting resources, conflicting constraints, and conflicting planning requirements.

So, the question is: What do Scrum and Lean say about such a multi-project situation?

Well, the answer is: Nothing! (But maybe they don’t need to…)

Let’s see… Our people are working on fifty different projects. But is that so much different from other organizations where they have 220 people working on just one big project?

Many Small Projects = One Big Project
I could claim that working on many small projects is similar to working on one big project. In both cases there are simply different teams working on different feature sets. And in either case the teams don’t know much about the details of the code being produced in the other teams. Therefore, it seems to me that running many small projects is similar to simultaneously developing many parts of just one big project.

Many Small Projects != One Big Project
However, I could also claim that working on many small projects is different from working on one big project. With many small projects you don’t have just one customer to talk to. You have fifty of them! It is easy to agree on a sprint backlog with one customer. But it’s much harder to have fifty customers agree on the allocation of your resources.

Optimize the Organization, not the Project
Lean Software Development has taught us an important lesson: don’t do local optimization! Optimization should take place at the project level, not at the level of individual people, processes or components. But as I said, running many small projects is similar to simultaneously developing many parts of one big project. You should not try to optimize the development of the individual parts. You should optimize the entire project. In our case, with fifty small projects, the entire project = the entire organization. Therefore, I believe we should optimize the organization, and not the individual projects.

It’s the same with traffic regulation on a busy road. By trying to make all cars adhere to a speed limit, the throughput can be increased significantly for everyone. But car drivers often try to optimize only for themselves. And then the system breaks down and everyone finds himself caught in a traffic jam, which could have been prevented by synchronization of the participants.

Synchronize All Projects
How can you perform optimization on the organizational level?

  • Perform the sprint planning meetings on the same day for all projects (Mondays, in our case).
  • Let all projects adapt to the same sprint length (weekly, in our case).
  • Collect up-to-date project performance stats every week for the organizational resource planning.

A little (mandatory) synchronization can go a long way in speeding up all the participants. There is much less noise about resources, constraints and planning requirements across our projects when every single project is required to step in phase with the others. Sure, this might not be optimal for some of the individual projects. But we’re not trying to speed up individual projects to their highest velocity. We’re trying to speed up the entire organization, so we can improve velocity for all projects simultaneously.

The Organization is the Project
I believe that you can solve some resource planning challenges by treating the entire organization as one big project. When planning your resources, it shouldn’t matter whether your people are working on many small projects or on many parts in one big project. This means that you can apply the agile and lean principles to the organization as a whole, and let them solve your problems at the appropriate level.

My First Agile Project Part 4: How to lose credibility and jeopardize your project with lack of management buy-in

Picture courtesy of shaz wildcat@flickr

Welcome to Part 4 of My First Agile Project. If you haven’t read the others in the series, don’t worry. Each part should stand alone. If you want to read the whole story though, the other parts are available: Part 1, Part 2, Part 3.

In Part 3 of this series, I talked about our demos and I mentioned how they unfortunately turned people off the demo with presentations about mostly behind-the-scenes features. My first instinct was just to say that those people lost their right to have input since they weren’t involved in the demo. In reality, the business world just doesn’t work like this, much to my chagrin.

What happened was the people who didn’t care to come to the demos just came later with changes and “suggestions” for new work we had to do. Also, since a lot of the ones who were supposed to be coming were upper management, their lack of knowledge about the Agile processes we were using led to a lot of problems and misunderstandings later in the project. Read on to hear more about how we failed to get our management on board as much as we should have. Hopefully you can avoid that mistake and some of the problems we’ve faced.

Consequences of Boring Demos

Our tendency on the project was to demo everything. We wanted everybody to get credit for their work and the audience to get to comment on everything. We wanted to be transparent so we showed everything, even though we knew it was sometimes boring for the business people in the audience.

At first, I didn’t think this was as big of an issue as it really was since I thought people understood the process and would pay attention because this was their chance to give feedback. Instead, we got comments from people like “I’m not going to waste 2 hours sitting there listening to IT clap for each other.” This wasn’t to our faces but behind our backs when higher-level people were asked to explain why they didn’t bother coming to the demos.

I’m not sure what the answer is to this. It’s valuable to have these kinds of demos so people can show off their hard work and get the team on the same page. And it does give people the chance to give feedback, but in practice, demos for stuff that happens behind the scenes can turn people off the whole process, which we learned can be worse than just not getting some feedback. Once somebody decides they’re not going to come to the demos any more, it’s hard to get them to reconsider when you get to the stuff they should be seeing. What ended up happening was that we would get feedback many sprints after we thought we’d “finished” some piece of functionality as word got back to somebody about what we’d built. We had to do a lot of rework due to this. Even things like finding out later what paper we were going to use for printing invoices came back and caused rework.

Getting Management Involved

Beyond rework, not having management involved is an even more important consequence of turning people off the project. At our company, managers and directors do a lot of the work so we invited a lot of upper level people to our demos. Getting these people on board and understanding the process is more important to an Agile project than I originally thought. Our project was the first exposure that our company had to Scrum and Agile processes so we tried to explain what it all meant so everybody would know. It was clear early on that the Agile ideas weren’t being understood at the higher levels of the company so at our second or third demo I gave a small presentation about the Scrum process and thought that some upper management people would be there to learn about it but they didn’t end up coming. We tried as we went along to get everybody on the same page as well but we mostly used the demo as the communication channel so with people not attending the demos knowledge of the problems didn’t get out there like they should have. In retrospect we were not as forceful as we should have been in getting the information out there. You just can’t expect that business people will be interested in something like Agile without a lot of hand-holding about it.

When we got down the line and were in trouble with problems on multiple fronts our management just saw the project was late and we were responsible. The clash between how a company wants to work with big projects (set deadlines, set budgets, etc.) and how Agile deals with big projects is real and if you don’t work hard to get people to understand the differences, you can’t come in after the deadline has been blown and expect to educate anybody. You need to start early with planning and estimating, make sure everyone involved knows where the project is at all times, only then can they reconcile how the project is going with the budgets and the deadline. See Part 1 of this series for more on the problems we had with not estimating and planning correctly. But you can do all the planning in the world and if the information isn’t getting to management or if they don’t know what it means, it’s just noise and people will ignore it, to your peril.

If we’d been communicating all along, we’d be in a much better place. As it is now, I can see that we as a team have lost a lot of credibility and I believe our ability to continue using agile processes is probably in jeopardy.

Team Responsibility

We can argue that a lot of the problems we’re having are because of bad 3rd party vendors, complications in the product we were integrating, problems converting data, etc. but at the end of the day we’re a team and this is our project so the responsibility is on all of us. Agile isn’t just about getting management off your back or freeing the team from over-documenting. It’s about the team taking responsibility and part of that is not giving up power over your project any more than you can help. Good managers don’t just shrug their shoulders and let things happen to their projects and that includes self-managed teams. We should have insisted that certain people attend our demos and keep up on our project status just like we insist that our fellow team members don’t slack off and endanger the project. That takes some courage, to be sure, but it’s important. When you’re building a product for internal use, the users and management are a part of the development process just like the development team is. This is a change for a lot of people but the team has to insist that everybody participate if the outcome is going to be a good one. We’ve certainly learned this lesson the hard way but sometimes the hard way makes the best teacher so we won’t soon forget.

If you’ve had issues with getting management involved on your project, please share. I think it’s in the nature of most developers to not place the importance on management participation that the issue deserves so if you’ve learned this lesson, or if you think I’m putting too much emphasis on it, I’d like to hear about it. Thanks.

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End Of Our Project

Weekly Agile Reading. Pack 14

Here is the top writing that caught my attention this week. More links, than usually and not everything is exactly about Agile, but who cares as long as it is related and interesting.

You might like having a look at the previous link packs as well.

If you happen to encounter another interesting content published since last Friday, please, post links in the comments.

» How we do Sprint Planning 2 " Scrum 4 You A short guide to the second part of the sprint planning. Concise and clear
» 5 min on Scrum | Sprint Planning 1 " Scrum 4 You A short guide to the first part of the sprint planning. Concise and clear
» Agile Thoughts " Blog Archive " Shock Therapy… or Compassion? Criticism of the shock therapy as the Scrum adoption method.
» Scrum Log Jeff Sutherland Bootstrapping the self-organization by.. dictatorship? Opinion of the Scrum co-founder.
» Stack Overflow Launches – Joel on Software A new programming Q&A site started. Quite different from the usual discussion forums and backed by Joel Spolsky.
» Rands In Repose: Impossible When insane management requests may make sense. Or may not.
» NOOP.NL: Managing Software Development: Top 100 Blogs for Development Managers (Q3 2008) Usually I don’t publish links to this site and this site contriibutors’ blogs, because of the ethical reasons, but this particular blog list by our Jurgen is very interesting. It is nice to see this site in the same list with many other blogs that I enjoy. We ranked quite low though. Maybe need to invent a similar linkbait list to raise the PageRank again.
» A good JUnit tutorial in pdf. Several years old, but still makes a lot of sense.

Taking customer risks fable

Disclaimer: All events and situations are imaginary. Any coincidence with reality is accidental.

Picture courtesy of law_keven@Flickr

Once upon a time there was a web development shop. One day a customer from a mobile phone and laptop company called Nokapple came to the shop asking to build a web site for selling music. The project was supposed to change the whole market and appealed to the company much, the team never worked on that big project, but had relevant experience and agreed.

The development started actively and everything was going more or less smoothly. The customer’s requirements did change during the course of the project, but the team managed to cope with that and was still targeting the original release date. Customer was so happy to see the evolving project that two months before the release date he decided to change his business plan and start targeting not only US market, but to go internationally.

Unfortunately the original plan was to have a US-only service and the team never considered the non-latin alphabets. In particular their text processing routines were never tested with the multibyte characters and there were no testers who were able to verify the Chinese or Japanese versions. Under the deadline pressure the team decided to quick-hack the routines and hire local Chinese students for testing. The hard work was not wasted and the system was done on time. The US launch went smoothly and competitor shares went down.

One week later Nokapple started offering the service in Asia. The next day the system text processing and sorting modules clinched trying to process the user comments and the US-based customers suddenly noticed a lot of Chinese songs in their favorite lists and it became impossible to search for the songs by Metallica and Madonna. Tabloids thrashed the company.

Two months later the team was able to fix all the glitches, but Nokapple had to return a lot of monthly payments, lost many existing and potential customer. The brand suffered greatly and the competitors got chance to enter the market actively looking for the competitive solutions. A stunning success turned into almost a failure. The web development shop was sued and might need to go bankrupt.

The moral

Risks are rarely if ever on one side of the project. There always are uncertainties that require trade-offs to be made by the customer. Customer wouldn’t ever want to know how your modules handle the string data, but he has to be aware of the risks and he has to make the decision on whether he wants to pay for eliminating some of them.