The Regenerate Web

Example 3: Using a Project Manager with Iterations and Kanban and Silo’d Teams

Here, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore. The Indian testers were very smart, and unfamiliar with the product, so the developers suggested the testers test feature by feature inside the iteration.

The project manager suggested they use cumulative flow diagrams and cycle time measurements to make sure the developers were not developing “too fast” for the testers. The developers, still smarting over the loss of “their testers” were at first, peeved about this. They then realized the truth of this statement, and developed this kanban board.

You can see in this board, that four items are waiting to go into system test. Uh oh. The developers are out-producing what the testers can take. This is precisely what a kanban board can show you.

The testers aren’t stupid or slow. They are new. They cannot keep up with the developers. It’s a fact of life, not a mystery of life. The developers have to act in some way to help the testers or the entire project will fail. The reason they are working in timeboxes as well as using kanban is that they have several contractual deliverables, that management, bless their tiny little hearts, committed to. The timebox allows the team or the product owners to meet with their customers and show them their progress. (They were deciding who would meet when I last worked with the team.) The kanban board help make the progress even more transparent.

Iteration planning: The product owner and the project manager jointly work on the agile feature roadmap, and the product owner owns the roadmap responsibility for it. The product owner owns and generates the backlog. The product owner and the agile project manager present a strawman iteration backlog to the team at the start of the iteration. They have had difficulty finding iteration planning time that allows everyone to be awake and functioning, bless the senior managers’ little hearts.

Daily commitment: They do a handoff, asking each other what they completed that day and what the impediments are. If you have read Manage It!, you know I modified the three questions to “What did you complete, what are you planning to complete, what is in your way?”

Measurements: cumulative flow, average time to release a feature into the product. They are experimenting with burnup charts and impediment charts. They are still having trouble bringing the testers up to speed fast enough.

Yes, they do retrospectives at the end of each iteration. Yes, the product owners own the backlogs.

I’ll summarize in the final part, the next entry.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

I was talking with a client recently, who was professing his desire for younger candidates.

“Can anyone older than 35 or 40 really know anything?” was his concern.

I sat there, a little nonplussed. “How old do you think I am?” I paused. “No, don’t answer that. Just remember that age is not the issue. You want people who know how to learn and work well with you. You want people who don’t have the same year of experience year after year after year.”

Those of you who have read Age and Agile are Orthogonal know what I think about age and agile. It’s not how old you are. It’s about how well you think. It’s about what you have learned and applied during your career.

In my recent post about Why an Agile Project Manager is Not a Scrum Master, I talked about the ongoing learning I expect a project manager to have. Of course, not all project managers have that. But the project managers who don’t continue to learn have the same year of experiences every year, year after year, do. (The goal of the PMI certification PDUs is that the PMP continue to learn, year after year.)

So, remember, it’s not about how old a candidate is. It’s about how well they they think, and how they have applied what they have learned.

And, you young turk hiring managers: yes, people that old might just know something. And, they might have more maturity than you give them credit for. And, they might not want your job. You can’t tell what a candidate’s value is until you read the resume. So, stop playing age discrimination before the older candidate even gets in the damn door and give them a shot.

Sheesh. Repeat after me. It’s not about how old the candidate is. It’s the value the candidate brings, regardless of the candidate’s age. Young people might not be able to learn anything, either. Sheesh.

A reader asked why the lifecycle in Agile Lifecycles for Geographically Distributed Teams, Part 1 is not Scrum. It’s not Scrum for these reasons:

1. The project manager and product owner start the release planning and ask the team if the release planning is ok. The team does not generate the initial draft of release planning itself. In Scrum, the team is supposed to generate all of the planning itself.
2. The checkin is different from the Scrum standup and the objectives of the checkin are different. I did suggest to the teams that if you want to create a cross-functional team where the functions are separated, if you ask people how they are working together, you might help them work together. Sometimes those questions work, and sometimes they don’t. It depends on the team and whether the people want to work together.

I didn’t mention retrospectives or backlogs in my examples so far, because I took them for granted. Yes, both examples of these teams do perform retrospectives and have product backlogs. They also have agile feature roadmaps, which are on my list to blog about.

The real difference is the difference between a Scrum Master and an Agile Project Manager. A Scrum Master is not a project manager. A scrum master does not manage risk by him or herself. A project manager will take on the risk management responsibility without asking the team.

A Scrum Master has only allegiance to the team. A project manager has responsibility to the team and to the organization. That means that the project manager might feel torn when the organization pressures the project manager to do something stupid. (Although, I just downloaded the Scrum Guide, and the Scrum Master’s responsibilities have grown considerably since I took my CSM with Jeff way back in 2006.)

But agile provides transparency when the organization asks the agile project manager to do something stupid, so it’s easier to retain your integrity as a project manager.

Want to move a feature higher in the backlog? Change the feature roadmap with the product owner and then change the backlog with the product owner. I expect the agile project manager to collaborate on the feature roadmap and the backlog with the product owner.

Want to change the velocity of the team to please some crazed manager? Both the Scrum Master or the agile project manager protects the team in these ways:

• Explain that velocity is not a productivity metric
• Say No and explain why
• Play the Double Your Velocity schedule game
• Or choose some other way to remove this management obstacle.

Agile makes it easy to protect the team. The question is this: does the Scrum Master have other responsibilities in addition to protecting the team or is the Scrum Master full time? An agile project manager tends to be full time on a geographically distributed team. Even on a geographically distributed team, a Scrum Master is not seen as a full time position. Bless their tiny little hearts, managers don’t seem to understand that transitioning to agile, especially for silo’d distributed teams with different cultural norms is non-trivial. They will make room for a project manager, but a Scrum Master? Oh no. Makes me nuts.

Cut corners on quality? I don’t see how. The team doesn’t meet the acceptance criteria on the stories and doesn’t meet their criteria of done for an iteration, and can’t show a demo. How does that serve anyone?

Help a team go faster? This is the one place where a project manager may have an edge over a Scrum Master, and that’s only because of education. An agile project manager is a project manager. That means he or she is actively studying project management, which means he or she is studying lean also, looking into work in progress. (I realize many project managers do not actively study project management.) I have high expectations of an agile project manager, and that is to limit WIP, work in progress, to measure cumulative flow. But, Johanna, that’s a lean project manager. Yes, that’s correct. Why not use all of the tools available to us at all times? This is not to help a team actually go faster, but to provide feedback to the team about their WIP. If everyone takes a story at the start of the iteration and everyone always works on their own story, it’s likely the team is at the slowest possible velocity. It’s worth knowing that, or at least retrospecting about the data. A project manager will gather the data. A Scrum Master, especially one who was not a trained project manager, may not know to gather the data.

I have nothing against Scrum Masters. Some of my good friends are CSTs (Certified Scrum Trainers). However, they are not all project managers, and have not been project managers, and have not studied the field of project management. Some have been. And, the real issue is this: In a two or three day workshop, they cannot convey to a person who may or may not have been a practicing project manager all of their project knowledge.

Organizations do not always pick project managers to be Scrum Masters. And, with good reason. Some project managers are command-and-control project managers. I suspect back in my long-ago past, I was. I gave it up long ago because it didn’t work. Some people never gave up command-and-control project management. Those people are not good project managers for agile projects. They are terrible project managers for geographically distributed projects, where you must work through influence.

You can have self-managing teams that are geographically distributed. You can have self-directed teams that are geographically distributed. But, they don’t start that way. They evolve into self-directed and self-managing teams. They start as management-led teams.

And, especially when they are silo’d teams, they need the coordination of a project manager, someone who will manage the risk between the silos, and someone who has the organizational backing, and yes, someone who has the allegiance to the organization to say, “We need to do this project” to write the project charter.

In a geographically distributed team, the agile project manager writes the project charter either with the team, or as a strawman for the people to edit and approve. Shane and I recommend that the people get together to write it together. We like it if people get together in person. We know how rarely that happens. (Penny wise, pound foolish.) So we teach people how to write a project charter when they are divided in space.

Because until there is a project charter, there is no organizing principle for the silo’d teams. Those developers in France, testers in Belarus, product managers and project manager in San Francisco, they all need something to coalesce around. The charter, which includes the project vision provides that. The iterations provide the project heartbeat.

So, that’s why I don’t think Agile Lifecycles for Geographically Distributed Teams, Part 1 is Scrum. It’s close, but no cigar. I respect Ken and Jeff’s work too much to call it Scrum when it’s not.

Now that I’m mostly recovered from my cold, I can continue the series about lifecycles.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

Example 2: Using a Project Manager with Kanban, Silo’d Teams

This is a product development organization with developers in Italy, testers in India, more developers in New York, product owners and project managers in California.

This organization first tried iterations, but the team could never get to done. The problem was that the stories were too large. Normally I suggest smaller iterations, but one of the developers suggested they move to kanban.

The New York developers had a problem biting off more than they could chew. So nothing moved across their board. The Italy developers had a board where the work did move across the board. The teams took pictures of their boards every day and shared the work across a project-based wiki. That allowed the New York-based developers to see the work move across the Italy board. And, that encouraged the New Yorkers to call the Italians and ask some questions. That helped the New Yorkers to change the size of their work by working with the product owners.

Now, why did the New Yorkers have such trouble originally? Because the developers “knew better” than the product owners, so they changed the stories into architectural features when they had originally received them. (Now they don’t. They leave the stories as real stories.)

Release planning: Management in California plan with agile roadmaps. They have features planned specifically week-by-week for the next 6 weeks, and have more of a quarter-by-quarter approach after that.

Iteration planning: No iteration planning because they are using kanban.

Daily commitment: No daily commitment needed because they use kanban. They do have a checkin a few times a week with each other as a technical team to make sure they don’t create bottlenecks and that they respect the WIP (work in progress) limits.

At one point, both the New York and Italy developer teams created automated tests so that the testers could catch up and stay caught up with regression tests. They add a story like that every couple of weeks, and they are paying down their automated testing debt.

The Project manager keeps an eye on the WIP, work in progress. Project manager also shepherds the product owner into keeping the queue of incoming work full and properly ranked. The product owner is notorious for changing the incoming work queue all the time. Project manager makes sure the team does retrospectives and is a little unclear how to do them in such a distributed team. The project manager is not so sure their retrospectives are working, and has started an obstacle list, to make sure the team has transparency for their obstacles.

Measurements: cumulative flow, average time to release a feature into the product.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

I’ve been working with geographically distributed and dispersed teams for the past couple of years. Some of them on quite large programs, some of them reasonably small. What they all have in common is that they all want to transition to agile.

Most of them start this way: someone takes a Scrum class, gets all excited. This is good. Then reality hits. Scrum is meant for collocated geographically cross-functional teams. Uh oh.

Almost all of these teams are separated by function: the developers are in one place, the testers are in another, the business analysts are in a third place, the project managers are in a fourth places, and if there are product owners (or what passes for product owners) they are often in a fifth location. It’s not uncommon for every single function of the team to be separate from every other member of the team. So, the teams don’t fit the Scrum criteria. Uh oh.

Since Scrum has so much brand recognition, these people think if they can’t do Scrum, they can’t do Agile. Nope, not so. What they need to do is start from the values and principles of the Agile Manifesto, and go from there. They create their own lifecycle, and their very own brand of Agile.

When I worked with one client, that client thought they could extend their iteration. Nope, if anything, that means you keep the iterations even shorter, because you need more frequent feedback when no one is in the same place. Well, there were words. And more words. But, if you start from the values, you see that short iterations are the way to go if you want to be agile. Otherwise, you get staged delivery, which is a lovely lifecycle, but not agile.

I’m blogging a series of examples. Please don’t ask me why the people ended up in these locations. I have no idea. All I know is that’s where the people are.

Example 1: Using a Project Manager With Iterations, Silo’d Teams

One IT organization has teams with developers in the Ukraine, testers in India, product managers and project managers in the UK, and enterprise architecture and corporate management in the eastern US.

This organization moved to two-week iterations. The developers were 3.5 hours ahead of the testers, which was not terrible. This organization had these problems:

1. The product managers had to learn to be product owners and write stories that were small enough to finish inside one iteration.
2. The enterprise architects had to stop dictating the architecture without features to hang off the architecture.
3. The developers and testers had to learn to implement by feature so the architects could help the team see the evolving architecture.

This organization had a ton of command-and-control to start. The project managers needed to facilitate the teams, not control them. The architects needed to help the teams see how to organize the product, not to tell the developers what to do. The testers needed to not be order-takers, as in taking orders from the developers.

You might ask why the organization wanted to move to agile. Senior management wanted agile because the releases got longer and longer and longer, and could not accommodate change. Agile was a complete cultural shift. The two-week iterations, along with an agile roadmap of features helped a lot.

The pilot project team consisted of the developers, testers, a product manager, and a project manager. The team rejected the enterprise architect as a member of the team because the architect refused to write code.

Release planning: The project manager and the product manager do an initial cut at release planning as a strawman and presented it to the team. “Can you do this? What do you think?”

Iteration planning: The team does iteration planning together, making sure every story is either small, medium, or large, where a large story can be done by the entire team in fewer than three days. The team makes sure they get every started story to done at the end of the iteration.

Daily commitment: The team does a daily checkin, not a standup. They timebox the checkin to 15 minutes. They ask these questions:

• What did you complete and with whom yesterday? (reinforces the idea that people work together)
• What are you working on and with whom today?
• What are your impediments?

The project manager who acts as a servant leader, not a command/controller manages the impediments.

The pilot project has two experienced agile people: the project manager and a developer. Both act as servant leaders.

Measurements: burnup charts, impediment charts

The pilot team has been together for six months now, and is successful. This is not Scrum. It’s not Kanban. It’s agile and it’s working. They are ready to start another project team, working by attraction.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

I’m so pleased to announce that Shane Hastie and I are leading a workshop on Working Effectively In Geographically Distributed Agile Project Teams, April 17-18, 2012 in Pleasanton, CA. Yes, that is Elisabeth Hendrickson’s Agilistry Studio.

Shane and I first delivered this workshop last year in Australia, when I was there for Software Education‘s SDC. We had a great time, and so did many of the participants. We have since evolved the workshop, to address the needs of the participants who did not have a great time, and to make sure we covered the topics we need to cover.

This is an experiential workshop. You will learn by doing and debriefing. If you’ve taken my one-day versions over the past year, you’ve had a taste of what we do in the two-day. You will learn even more from both of us. Remember, we developed this as a geographically distributed pair.

One of the benefits of signing up for the workshop is the informal consulting you can obtain, not just from us, but from the other people there. You’ll hear what other people are doing, what’s working and what’s not working. If you want, you can hear from Shane and me about what’s working and not working at our clients as they transition to agile and explore more agile approaches.

Do check out the syllabus. And, if you’re ready to sign up, please register.

I have posted last week’s Pragmatic Manager, Are You Being Guilted Into Doing More?.

At Agile 2011, I had a great video conversation with Shane Hastie about agile project portfolio management. The chair is big, I’m not so short. The chair is big, I’m not so short. How many times do you think I have to say that to make it true? The chair is big, I’m not so short. That ought to do it.

If you’re looking for a job, and you have more than two years of experience, you can consider using a recruiter. Some recruiters have entry-level jobs, but that’s rare in this economy.

The more experience you have, the more senior you are, and the more specialized your experience is, the more you need a recruiter. You are more likely to be looking for a position that is unique and less likely to be advertised.

So how do you find and use a recruiter?

Use Someone Who Helped You Find a Position Before

Did you find your current or most recent position through a recruiter? Was it a good experience? Call that person again. If it was not good, don’t call that person.

Ask your friends for their references. Ask your LinkedIn colleagues for their references. Ask people who have found positions through recruiters who they like. Word-of-mouth referrals for recruiters is the best kind of referral.

You can even ask the hiring managers in your organization which recruiters they use, although that starts to put the recruiter in a sticky situation if you are still employed.

Use Someone Sourcing for Your Open Positions Now

If you’ve been a hiring manager, you can use a recruiter you’ve trusted to find you people before. And, you must be careful if you in the middle of hiring others for your department and looking for a new job yourself. You don’t want to put the recruiter in a no-win position. Discuss this with the recruiter.

Ask the recruiter if he or she has jobs at the level you want. Not all recruiters have jobs at all levels. Maybe you are not qualified for the level you want. You need to work with someone who will provide you honest feedback. You may need someone in the same organization as your current recruiter, but not someone who is sourcing for your open positions.

What About a Recruiter Who Cold-Calls You?

Some of my best ongoing relationships through the years have been from recruiters who cold-called me. They had heard of me, as a senior engineer, or as a manager who had open reqs, so they called. I listened to some of them. When I was a hiring manager, I let them prove themselves to me. I now have a short list of six trusted Boston-area recruiters, whom I refer and recommend.

Good Recruiters are Not Like Bad Car Salespeople

Yes, recruiters are salespeople. Yes, they serve the hiring organization. And, that doesn’t mean that you can’t both win from a long and lasting relationship. Bad salespeople exist in all industries. And, the great recruiters are not like the bad car salespeople, or like ambulance-chasing lawyers. You can trust great recruiters.

I cultivate my recruiting colleague relationships. I refer people to them. In exchange, I hear about new positions early, increasing my value to my network. I can’t always make a connection, and when I do, it’s great.

If you are senior enough, consider a recruiter. Choose one recruiter, maybe two. Do not use more than two recruiters at a time–they will be showing you the same jobs, especially in a down economy. Decide how long you want to give the recruiting relationship. If at the end of that time you’re not happy, end the recruiting relationship and move to another recruiter. And, consider the feedback the recruiter has provided. Are you taking advice on your dress, your resume, your interview style? Because, your inability to land a job could be about you, not the recruiter.

Recruiters can help you iterate on everything in your search, if you let them. They can hold up a mirror, if you let them. The question is this: Will you?

 

This fall New York City will open The Academy for Software Engineering, the city’s first public high school that will actually train kids to develop software. The project has been a long time dream of Mike Zamansky, the highly-regarded CS teacher at New York’s elite Stuyvesant public high school. It was jump started when Fred Wilson, a VC at Union Square Ventures, promised to get the tech community to help with knowledge, advice, and money.

I’m on the board of advisors of the new school, which plans to accept ninth graders for fall of 2012. Here’s why I’m excited about this new school:

1. It’s a “limited, unscreened” school.  That’s Board of Ed jargon. It means that any student who is interested can apply—their grades and attendence record are not taken into account in deciding whether or not to admit them, only their interest. I think this is the best thing about the school. A lot of kids are just not interested enough in other academic subjects to get good grades, but they would make great software engineers. A lot of immigrants (especially in New York) are not yet proficient enough in English to get good grades in all their subjects, but they’re going to make great software engineers, too. And in my humble opinion, a school that accepts a cross-section of students is bound to be more enriching than a school that only accepts academic superstars.

2. OMG do we ever need more software engineers. The US post-secondary education system is massively failing us: it’s not producing even remotely enough programmers to meet the hiring needs of the technology industry. Not even remotely enough. Starting salaries for smart programmers from top schools are flirting with the $100,000 mark. Supply isn’t even close to meeting demand. This school is going to be pretty small (in the 400-500 student range) but the Board of Ed has promised that if it’s successful it’ll be used as a template for more schools or for special programs inside larger schools. I predict that they will be overwhelmed with applicants and this will be the most popular new school in New York City in years.

3. And we need more diversity, too. One of the reasons the elite US colleges seem to turn out so few computer science majors every year is that they are only drawing from a narrow pool of mostly white and asian males. Minorities and women are embarrassingly under-represented. Hopefully an unscreened school in New York City can pump a lot more diversity into the pool.

4. It’s not a vocational school. Unlike traditional vocational schools, this new school will have a rigorous academic component and will prepare students for college. But college is not for everyone—many of the best programmers I know were just not interested enough in a general four year degree and went straight into jobs programming.

I’m pleased to be involved in this project, but it needs more help: they’re still looking for qualified computer science teachers and a principal. If you’re interested drop me an email and I’ll make sure it gets through to the right people.

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

My new Gantthead column is up, Who’s Playing Agile Schedule Games?

If you liked the schedule games from the more traditional projects, you’ll love the agile schedule games. Please comment over there.

I posted my most recent Pragmatic Manager: Are Your “Shoulds” Driving Your Decisions?

Yes, in case you couldn’t tell, I am doing a series on project portfolio management, so that you do take a look at my Peer Project Portfolio Coaching. Several people took advantage of the early bird pricing. We’re in the not-quite-early-bird pricing now. And, if you sign up with a buddy, you can still get early bird pricing for the two of you. It’s a steal.

If you are struggling with too much to do, sign up. If you are overwhelmed with your workload, sign up. If you are trying to do it all, sign up. You cannot succeed. You are making yourself crazy.

We will use agile and lean approaches and help you overcome the guilt, the sunk cost syndrome, and the “you’re not playing with the team” nonsense that other people will pull on you. You’ll get the support you need from your peers.

Join us. You won’t be sorry.

I’ve met a few people recently who wanted positions as agile project managers or Scrum Masters. I asked them if they belonged to any Agile LinkedIn groups. No, they didn’t know those groups existed.

It’s easy to not know. And, if you’re looking for a job, it has to be your business to know. Part of the problem is that the groups I know of today may not be the groups you need to know about tomorrow, so I’m not going to provide you a list of groups. Instead, I’ll suggest a way you can find the groups you need to discover.

1. What do you want to do? Is it project management? Testing? Development? Start looking around for a LinkedIn group that seems like it has the right words in the title. For example, if you’re a Ruby on Rails developer in St. Louis, and you find a Ruby on Rails group in St. Louis, that seems like a group you might want to join.
2. Now, read the discussions. Are there past discussions? Do people use the group? Or, is the group partly moribund? Is the group new and the group needs someone to help move it forward? Maybe that’s you. Maybe not. Your choice.
3. Look at the past jobs. Have the posted jobs been at your level? Higher? Lower?
4. Look at the group statistics. Are people joining? Leaving?
5. Do you know the people in the group? Will you be able to add to your first level connections by joining this group?

Remember, you want looser connections rather than tighter connections so you can network more effectively. Maybe you don’t want Ruby on Rails in St. Louis. Maybe you want Ruby on Rails. Maybe you want Ruby on Rails in Missouri, or Midwest, or Central. Or, if you are from Canada or  Europe, maybe you want Ruby on Rails in Canada or Europe and the heck with the crazy USA folks. The reason I’m focusing on geography is that I’m assuming you have a preference for or against relocation. If you find a group with with a geographical location, you can be more assured that the posted jobs are relatively close to that location.

If you are looking for a job, look for active LinkedIn groups. If you are a hiring manager, look for those same LinkedIn groups. Some groups are really active, some not so much. And, the groups on LinkedIn are a treasure trove of networking. You have to use them to your advantage.

Just a few months ago, we launched Trello, a super simple, web-based team coordination system. The feedback has been overwhelmingly positive and adoption has been very strong, even in its early, 1.0 state.

Trello is new kind of development project for Fog Creek. It’s 100% hosted; there will never be an “installed software” version of Trello. That allowed us to modernize many aspects of our development process; I am happy to announce that there is absolutely no Visual Basic code involved in any part of Trello. What’s next, flying cars?

The biggest difference you’ll notice (compared to our previous products pitched solely at software developers) is that Trello is a totally horizontal product.

Horizontal means that it can be used by people from all walks of life. Word processors and web browsers are horizontal. The software your dentist uses to torture you with drills is vertical.

Vertical software is much easier to pull off and make money with, and it’s a good choice for your first startup. Here are two key reasons:

• It’s easier to find customers. If you make dentist software, you know which conventions to go to and which magazines to advertise in. All you have to do is find dentists.
• The margins are better. Your users are professionals at work and it makes sense for them to give you money if you can solve their problems.

Making a major horizontal product that’s useful in any walk of life is almost impossible to pull off. You can’t charge very much, because you’re competing with other horizontal products that can amortize their development costs across a huge number of users. It’s high risk, high reward: not suitable for a young bootstrapped startup, but not a bad idea for a second or third product from a mature and stable company like Fog Creek.

Forgive me if I now divert into telling you a quick story about my time spent on the Microsoft Excel team way back in 1991. (Yes, I know you were not born yet, but I assure you that computers had been invented. Just hop up here on my knee and shut up.)

Everybody thought of Excel as a financial modeling application. It was used for creating calculation models with formulas and stuff. You would put in your assumptions and then calculate things like “if interest rates go up by 0.00001% next year, what percentage of Las Vegas homeowners will plunge into bankruptcy?” For example.

Round about 1993 a couple of us went on customer visits to see how people were using Excel.

We found a fellow whose entire job consisted of maintaining the “number of injuries this week” spreadsheet for a large, highly-regulated utility.

Once a week, he opened an Excel spreadsheet which listed ten facilities, containing the name of the facilities and the number 0, which indicated that were 0 injuries that week. (They never had injuries).

He typed the current date in the top of the spreadsheet, printed a copy, put it in a three-ring binder, and that was pretty much his whole, entire job. It was kind of sad. He took two lunch breaks a day. I would too, if that was my whole job.

Over the next two weeks we visited dozens of Excel customers, and did not see anyone using Excel to actually perform what you would call “calculations.” Almost all of them were using Excel because it was a convenient way to create a table.

(Irrelevant sidenote: the few customers we could find who were doing calculations were banks, devising explosive devices called “derivatives.” They used Excel to maximize the bankers’ bonuses on nine out of ten years, and to cause western civilization to nearly collapse every tenth year. Something about black swans. Probably just a floating point rounding error.)

What was I talking about? Oh yeah... most people just used Excel to make lists. Suddenly we understood why Lotus Improv, which was this fancy futuristic spreadsheet that was going to make Excel obsolete, had failed completely: because it was great at calculations, but terrible at creating tables, and everyone was using Excel for tables, not calculations.

Bing! A light went off in my head.

The great horizontal killer applications are actually just fancy data structures.

Spreadsheets are not just tools for doing “what-if” analysis. They provide a specific data structure: a table. Most Excel users never enter a formula. They use Excel when they need a table. The gridlines are the most important feature of Excel, not recalc.

Word processors are not just tools for writing books, reports, and letters. They provide a specific data structure: lines of text which automatically wrap and split into pages.

PowerPoint is not just a tool for making boring meetings. It provides a specific data structure: an array of full-screen images. 

Some people saw Trello and said, “oh, it’s Kanban boards. For developing software the agile way.” Yeah, it’s that, but it’s also for planning a wedding, for making a list of potential vacation spots to share with your family, for keeping track of applicants to open job positions, and for a billion other things. In fact Trello is for anything where you want to maintain a list of lists with a group of people.

There are millions of things that need that kind of data structure, and there hasn’t been a great “list-of-list” app before Trello. (There have been outliners, but outlines are, IMHO, one of the great dead ends in UI design: so appealing to programmers, yet so useless to civilians).

Once you get into Trello, you’ll use it for everything. I use about thirty Trello boards regularly, and I use them with everyone in my life, from the APs (Aged Parents), with whom I plan vacations, with every team at work, and just about every project I’m involved in.

So, ok, that was the first big difference with Trello: horizonal, not vertical. But there are a bunch of other differences:

It’s delivered continuously. Rather than having major and minor releases, we pretty much just continuously push out new features from development to customers. A feature that you built and tested, but didn’t deliver yet because you’re waiting for the next major release, becomes inventory. Inventory is dead weight: money you spent that’s just wasting away without earning you anything. Sure, 100 years ago, we had these things called “CD-ROMs” and we shipped software that way, so there was an economic reason to bunch up features before we inflict ‘em on the world. But there’s no reason to work that way any more. You already knew that, of course. I’m just saying—I stopped using Visual Basic about five minutes ago. Brave New World.

It’s not exhaustively tested before being released. We thought we could get away with this because Trello is free, so customers are more forgiving. But to tell the truth, the real reason we get away with it is because bugs are fixed in a matter of hours, not months, so the net number of “bugs experienced by the public” is low.

We work in public. The rule on the Trello team is “default public.” We have a public Trello board that shows everything that we’re working on and where it’s up to. We use this to let customers vote and comment on their favorite features. By the way, while Trello was under development, it was secret. We had a lot of beta testers who gave us customer feedback so that the development team could use lean startup principles, but the nine months we spent building version 1.0 in secret gave us a significant lead in a competitive marketplace. But now that we’re shipping, there’s no reason not to talk about our plans.

This is a “Get Big Fast” product, not a “Ben and Jerry’s”  product. See Strategy Letter I. The business goal for Trello is to ultimately get to 100 million users. That means that our highest priority is removing any obstacles to adoption. Anything that people might use as a reason not to use Trello has to be found and eliminated. For example:

Trello is free. The friction caused by charging for a product is the biggest impediment to massive growth. In the long run, we think it’s much easier to figure out how to extract a small amount of money out of a large number of users than to extract a large amount of money out of a small number of users. Once you have 100 million users, it’s easy to figure out which of those users are getting the most value out of the product you built. The ones who are getting the most value will be happy to pay you. The others don’t cost much to support.

The API and plug-in architectures are the highest priority. Another way of putting that is:  never build anything in-house if you can expose a basic API and get those high-value users (the ones who are getting the most value out of the platform) to build it for you. On the Trello team, any feature that can be provided by a plug-in must be provided by a plug-in.

(The API is currently in very rudimentary form. You can already use it to do very interesting things. It is under rapid development.)

We use cutting edge technology. Often, this means we get cut fingers. Our developers bleed all over MongoDB, WebSockets, CoffeeScript and Node. But at least they’re having fun. And in today’s tight job market, great programmers have a lot of sway on what they’re going to be working on. If you can give them an exciting product that will touch millions of people, and let them dig deep into TCP-IP internals while they try to figure out why simple things aren’t working, they’ll have fun and they’ll love their jobs. Besides, we’re creating a product that we’ll be working on for the next ten years. Technology that’s merely “state of the art” today is going to be old and creaky in five years. We tried to go a little bit beyond “state of the art.” It’s a calculated risk.

None of this is very radical. TL;DR: Fog Creek Software develops an internet product using techniques that every Y-combinator startup has been using since spez was sleeping with his laptop so he could reboot Reddit when Lisp crashed in the middle of the night. If you haven’t tried Trello yet, try it, then tell me on twitter if it worked.

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

Imagine this scenario per a comment: you’ve been contracting or consulting while you’ve been looking for a job. A potential hiring manager asks you, “What was your gross income?” as part of the interview. What do you say?

“Oy vey” is not a good answer. Although it might be precisely what you are feeling.

This is the start of the salary negotiation. Are you ready for the start of the salary negotiation? Have you built rapport with the hiring manager? You can always say, “I’m open to negotiation. What level is the job, and what is the midpoint of the level?” See What Salary Do You Expect is Another Bad Question.

Now, how do you wiggle out of the question?  You might say something like, “I’m not comfortable telling you that right now. Gross income as a consultant or contractor is nothing like an employee’s yearly wage. When we get to the salary discussion, I’d like to know what the position is worth to you, and what you think I am worth to you. I haven’t been working full time; I’ve been working enough to pay some bills. I’ve been looking for a job close to full time. I’d hate for you to think you could base an offer on my part-time contracting or consulting income.” I would say this with a smile on my face, if at all possible.

If a younger HR person or hiring manager asks this, I would chalk it up to naivete. If an older HR person or hiring manager asks, I would chalk it up to stupidity. If a senior manager of either stripe asks, I would wonder about working there. If you were successful as a contractor/consultant, why would you be looking for a full-time job?

No matter what, remember this is the start of the salary negotiation. You get to decide when to answer the question. You don’t have to answer at the beginning of the interview process. It’s sort of like being asked when you meet a blind date, “Will we sleep together tonight?” Ooh ick. Sometimes I’m very glad I’m married and self-employed.

I have an article posted at Techwell, Management Myth #1: The Myth of 100% Utilization. This myth has always been a problem. It’s even more of a problem now as more organizations transition to agile.

People need time to think. They need time to adapt to their current circumstances. They need time to create their teams. Some of the time, people are thinking about this iteration’s stories. Some of the time, people are thinking about the product roadmap. Some of the time, people are thinking about the next iteration’s stories.

Thinking is work. Not all work occurs when fingers touch a keyboard. Not all work occurs when mouths are open and moving. Even I have learned to sometimes think with my mouth shut, although that is an infrequent occurrence.

The more “utilized” a person is, the less a person can think. And that means a person is not going to innovate. A person cannot provide the best they can for their organization, which is not why you hired that person.

If you are one of those people who is working with a manager who still thinks in terms of 100% utilization, consider my peer project portfolio coaching. If you are a manager, who is considering another way, consider Manage Your Project Portfolio and consider my peer project portfolio coaching with your leadership team.

In any case, please read the column, and leave comments on the column over at TechWell.

If you missed my most recent Pragmatic Manager newsletter, Focus on One Thing at a Time, it’s posted. In it, I ranted about the delays of multitasking and introduced a new service: Peer Project Portfolio Coaching.

I keep seeing people trying to make the transition to agile, still multitasking and not able to say No to all those projects–at all levels of the organization. Partly, it’s because they don’t have the tools, which is why we’re talking about the project portfolio. Partly, it’s because they don’t have the language, which is why we’re talking about how to say No. And, partly, because they have rules about should they even say No. Or, they have guilt about saying No. Or, any number of other reasons.

If you are one of these people who knows you can’t quite do it all, and are not sure how to organize or say No, sign up now and take advantage of the early bird pricing.

If you are a leadership team who has trouble with the sunk-cost problem (“we already spent so much money, surely we’ll see some return soon”), talk to me, and we’ll decide if group coaching is right or if you need your own private coaching.

Please join us.

I have finally posted my most recent email newsletter, Three Myths and Three Tips. It took a while because I was converting my site to WordPress and I did not want to maintain the site in two places.

I have finally transitioned fully to WordPress. What a relief. All my old articles are finally posted. I have tagged back to somewhere in 2006. I’ll keep tagging as I get around to it.

What do you think? I’d love your feedback.

I’m at the end of redesigning my website. I’m posting and tagging my articles now. These are the articles from several years ago I didn’t get around to posting because it was too much of a pain to do in Dreamweaver. Yes, I’ve transitioned to WordPress site. I’m planning to unveil it next week.

I have a question for you, my loyal readers. Aside from typical tags, such as “project management,” I can also tag my articles with the outlet in which they were published. Is that helpful to you? Please comment and advise me. Thank you.

I’ve been writing the networking part of the Agile Job Search book, and realized you could use some of the advice before the book is ready.

I receive lots of requests to link with people on LinkedIn. Some people I’ve met at conferences or workshops. Some people I know. Some people I share common groups with. Some people I’ve met only by email. Most people I’ve never met in person at all.

I often accept the offer to link. However, I’ve stopped accepting the offer to link with people who have zero connections and no picture and who use the generic LinkedIn “since you are a person I can trust” text. Why? Because I can’t tell if these people are real. I can’t tell if I can trust you. Why would they want to connect with me of all people, especially if they are not in my industry?

If you want to connect with me, give me a reason to do so. Tell me how you know me. Show me your picture. Yes, I’m harping on the darn picture. If you are looking for a job or looking to hire someone or to expand your network, you have no excuse for not having a picture on your LinkedIn profile. Any reasonable picture will do. Any unreasonable picture, as long as it’s not of your private parts, will do. But don’t hide behind anonymity.

Just this morning, the husband of a close friend sent me an invitation to link. He said in his invitation, “I’m so-and-so’s husband.” Well, that cemented it. I would add anyone from her family, and certainly her husband. I trust her, and by extension her family. Remember back in Networking for a New Job or New Candidates, that Pfeffer said you build loose ties in many places? My friend’s husband is a loose tie to me. We trust each other through my friend. And, he’s not anonymous to me. Yes, he has a picture.

LinkedIn is not built on anonymity. It’s built on your experience, on your network, on your ability to use your network and your ability to help other people. If you’re not going to contribute, then don’t bother. And, don’t bother me.

The nice folks at getabstract like Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. Some of the takeaways they highlight are:

• Project portfolio management helps you finish your software projects on schedule.
• You must understand your mission to make choices about prioritizing software projects.
• Managers must select which projects to undertake and which to avoid.
• Create a visual overview of all current and upcoming projects to depict who will work on them and when.
• Some managers dislike project portfolio management because it prevents them from shifting developers between assignments. This is, in fact, a primary benefit.
• Project portfolio management aligns your team’s work objectives with your organization’s strategic objectives.
• Project portfolio management’s central truth: You can do all your software projects – but you can’t do them all at once.

I get to display this nice badge on the book’s page on my site, and the Prags have it on the book’s page already.

You don’t have to read just the abstract. You can read the entire book. Buy it from the Prags in both the ebook (many forms) and/or print as a holiday present to yourself so you can start the new year right.

Or, if you are still a print-only reader, and want to buy it from Amazon, that works too.

But, if you are still trying to plug people into projects part-time, or if you are still trying to figure out how to get it “all” done, stop. You can’t. You need to engage your peers into having those difficult discussions about what you can commit to for now, what you can’t commit to for now, and what projects you will never commit to.

Welcome to the project portfolio!