The best architectures, requirements, and designs emerge from self-organizing teams.

This one statement, which sounds wonderful to me, is often interpreted to mean:

Agile teams must be made up of generalists: no specialists allowed.

Another interpretation is that anyone on the team must be able to do any job on the project. Most rational agile teams don’t take that extreme interpretation. Or at least they never repeat that mistake more than a couple of times. They learn that having people who understand things at more than a surface level will make work go faster and with less rework.

Specialists vs. Generalists…or is is Specialists vs. Speed?

This is a very strong belief of one prominent Agilisto who is extremely vocal about this principle. His articles and post are full scathing attacks on people who specialize. Sure, he allows people to have a couple of specializations just for fun, but he’s clear that specialists impede the speed of a project, hold back production and generally lead to diva princesses, his name for me when I appear in debates with him. There’s also a prominent consultancy that tells clients that no one with the words "analyst, audit, architect, administrator" will be allowed to speak to anyone on the project –teams must be just business users and team members (developers). This consultancy is also adamant that only a developer and a clerk be able to decide on requirements and implementation issues.

I’ve been on those projects. We ended up with the clerk and the generalist designing and implementing a brand new way of doing accounting, with a brand new chart of accounts. Just for one project. They couldn’t get into QA testing because their solution was not going to pass audit, integration, security or generally accepted accounting practices reviews. But dang, they sure did it fast. And their new way of doing accounting led to inaccurate accounts, but that didn’t matter. They were fast. However, they were sent back to do it all over again. It was painful for everyone.

These are the types of things an architect, auditor, administrator and analyst would have slowed them down with by pointing out gaps in their solution. But dang, they sure did it fast.

Over Specialization and Over Generalization

I do recognize that people can be over-specialized. You see those people all over…if you ask a question, their answer always involves the same solution or tool. They can’t see any other way of doing something than what they know. I also know people who are fabulous at many, many things on my projects. But in my opinion, the all generalist meme really translates to:

Our team needs to be staffed with people who are specialists in everything.

Think about that for a few seconds. What would that mean, just on your current project? Someone who knows these topics at a professional level: database, network, security, design, data, storage, development, coding, planning, estimation, capacity planning, estimation, UX, reporting, analytics, scalability, reliability, availability, quality, testing, compliance, legislation, localization, globalization, privacy, accessibility for people with disabilities, reporting, methodology, development environments.

Now insert the words for all the technologies used on an enterprise system. All of them. We need professional level people to work with all of them. Note that professional doesn’t mean expert; it means someone who can get something done with minimal supervision.

Then insert all the words for all the activities your entire enterprise does. Do you have a few hundred words? A few thousand? Imagine trying to hire someone who meets all those criteria at the professional level? Even if you could find that person, which I don’t believe you can, how much are you going to have to pay her? Does your company have enough spare zeros hanging around to do that? [tweet quote] What are they going to do when they need 100 more people, just like that?

Why I Hire Specialists who Make Great Generalists

So what does this mean? I want to hire people who have a broad understanding of IT development. I want them to have a good literacy-level understand of most the things we do and use. If they don’t have that knowledge, then they need to be able to pick it up as we go. But I need specialists. I don’t have time on my projects to train and mentor someone one who is going to build the database on the difference between foreign keys, alternate keys, surrogate keys, primary keys and Florida Keys. Now if someone else on the team wants to know that, I’m happy to point to resources where they can find that out. However, my database designer needs to be able to work under minimal supervision to be able to do that. In fact, I’d prefer that they know how implement in it in our specific technology. They should be able to rely on external resources, but they shouldn’t have to sit at their desks with a (virtual) book open before them showing them how to do every step. That’s a recipe for disaster. It will take longer and be more error prone.

Be Both a Specialist and a Generalist

How can you do that? By ensuring that your professional development plan (you have one, don’t you?) includes activities that strengthen both your specializations and your overall technical and non-technical skills. That means you read about things outside your specialization. You actually sit through a DAMA meeting or a SQLSaturday session that isn’t part of your "today job". You expand the depth and breadth of your knowledge. Heck you even attend a session on professional development. Then you make sure you plan gets executed, even if it means paying for your own training or getting up early on a Saturday to attend free training at a SQLSaturday. Maybe it means starting up a series of brown bag lunches at your company, where every group takes turn presenting 20 minutes on their favourite topic for other groups.

If you are a data architect, it means learning more about process modeling, database implementations and development tools in your shop. If you are a DBA, it means learning more about data modeling and data compliance. If you are a developer, it means you learn more about all of the above. It’s up to you. You need to take care of both your inner generalist and inner specialists.

Generalists are great…in general. You can’t master everything, no matter what people tell you. But your specialization won’t be much value if you can’t apply that knowledge within the context of the overall project. You need to be both.

Maybe we’ve been writing too much about problems and solutions lately? Is it me, or does this Wordle focus on negativity? Perhaps problem solving tips are the best thing we can share. What do you think?

A wordle is a graphic generated from text where the size of the word is based on how frequently we have used that word in a post. I used our RSS feed for the blog to generate the wordle, so only recent posts will show up in this graphic.

One of the ways we measure whether we are writing the right stuff is how many comments we get on the blog post itself. So if you read our posts and agree, disagree, have another thought or just want to encourage continued postings, please do leave a comment. Yes, you can include a link to your blog. Yes, you can use your Gravatar to post. I know that some bloggers don’t like comments/links/gravatars, but I think they they are crazy.

I’ve been doing business analysis and project management for a while now and sometimes you run into one of those project that you just can’t seem to get traction on. Maybe it’s time to consider it a ‘Wicked Problem’.

‘Wicked Problem’ is a phrase originally used in social planning to describe a problem that is difficult or impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize.

I know what you’re thinking…if you’re the Project Manager or Business Analyst you should be able to get to the real requirements and the real problem. And I would normally agree with that, but read a little further about “Wicked Problems” and you’ll see it isn’t so straightforward. It isn’t just about the requirements, but the difficulty in defining the problem and the goal, as well as the overall social and cultural aspects at play. And if the organization and environment are constantly changing you can’t stick a stake in the ground and say “this is what it looks like”. By the time you finish writing it down, it will have changed.

The people in the organization also contribute to the problem here. If you have different aspects of the business that are unable to agree on the goals and vision you will never be able to come up with a solution using traditional methods. Normally, this type of problem doesn’t apply to an organization, but more to societal and cultural issues. However, the odd time, you run into a company and project where it exists.

A Right Turn Instead Of A Left Turn

Some time ago, Karen and I put our names in to attend the #NASATweetup scheduled for the last launch of Space Shuttle Endeavour (STS-134). Karen was chosen and went down last week and had a fabulous experience, but with less than 3 hours to go until the launch it got scrubbed. Throughout that morning they had already worked on a problem with a regulator and had made up for lost time caused by a storm the previous day and it all looked good for a launch. I was watching the tweets and through NASA TV saw the astronauts in the Astro Van heading to the launch pad when they turned right to go back instead of left and we found out the launch was scrubbed. As of right now, a new launch date has not been set as they work on the problem and determine when the next eligible target launch date can be.

But We’re Going To Disappoint All These People

The launch delay got me thinking about how decisions like that get made especially so close to the deadline and how we could apply this thinking to our own projects. Think about it, the President was on his way, there were numerous dignitaries, 150 #NASATweetup attendees, and an estimated 700,000 others there to watch this historic launch of the last shuttle flight of Endeavour. Can you imagine having to be the one that has to say “not today”? Have you ever been on a project when the executives are there saying “Let’s just go ahead and implement it and we’ll fix it later”?

Your Decision Making Process Is Key And Must Be In Writing

While most of us don’t deal with projects with the same risk factors as NASA does we still have to deal with problems and risk, but how we deal with it is key. As Karen detailed in her post #NASATweetup – It’s a GO! Readiness Reviews and Your Projects this all works when you have everything documented beforehand and you have a formal process for this. In essence, you have algorithms and decision trees that you follow that make sure that you make the right choice and don’t let human emotion and behaviour get in the way. Don’t get me wrong, this was not an immediate decision and I’m sure it was not an easy decision. But if you have all of your options and decision trees, policies and procedures mapped out ahead of time then the decision is based on those written policies and not subject to human emotion.

In the announcement of the delay Shuttle Launch Director, Mike Leinbach, stated:

Today, the orbiter is not ready to fly…we will not fly before we’re ready.

This was not a decision taken lightly, but after thoroughly evaluating the problem and determining if it could be fixed prior to launch or if it was more serious. But with such a short time to launch they had to make a firm decision, so they did. In my mind, this takes a lot of integrity and strength to be able to stand up and say that they can’t launch.

WWND

So the next time you have a problem on one of your projects think about this: WWND – What Would NASA Do? Better yet, when you start a project, write down all the possible scenarios, risks and decisions and a have a formal process so you can follow it when you need to.

What do you think of this picture of Annie? Doesn’t she look cute? She’s such a tiny cat and looks so innocent that you think you can pick her up and pet her and she’ll be all sweet and nice. She can be nice and sweet, but she can also be nasty and bite and scratch. The funny thing is, she turns from nice to nasty really fast. You can be petting her and thinking everything’s fine, but all of a sudden she’ll turn and hiss and lash out to scratch. For those that don’t know her and just try and pet her they are surprised when she turns and they aren’t expecting it. For those of us that know her and have experienced it, we know what the signs are and can see her starting to turn. It’s in her eyes and the way she holds her head, but if you haven’t seen it before you may not recognize it.

Last week I wrote a blog post called What It Feels Like To Be The Cat and I talked about a specific example of feeling like a cat when you’re in meetings. In my example, the project team was surprised when I finally did “lash out” in a meeting, but they shouldn’t have been. Just like Annie does, we all show signs when we are not happy, not engaged, ready to run, or ready to lash out. We just have to look for the signs. In Karen’s recent post Herding Cats The Hard Way, she talks about situations where you can be causing your users or project team to act like a cat and want to lash out, but sometimes it happens no matter what you do. But I think that if we see the signs, we can change our actions and it can keep things from getting too bloody.

I’ll give an example of how this can happen. Let’s say you’re invited to a normal status meeting where everything seems to have been going fine and it’s a clear agenda of things to discuss. Now suppose that someone has found some problem that wasn’t on the agenda and it relates to your (or your team’s) work and they bring it up. Your first reaction internally is an adrenalin rush and you get defensive. Most of us won’t “lash out” in that meeting as a first response, but if it keeps getting discussed and we’re pushed into a corner it could happen. But if the others in the meeting are paying attention they can see it coming and defuse the situation. Think about it, has this ever happened to you? What was your reaction? Did you feel like the cat and want to lash out or run away and hide?

You’re actions and what you do and say are important in your interaction with people. You can’t deliver the same message the same way with everyone and you have to watch and pay attention to the other person so you can see when their attitude is changing. If you don’t pay attention, you could be surprised and a bit bloody.

In her recent blog post Herding Cats the Hard Way, Karen talked about trying to herd a cat into a cat crate and that it struck her as being similar to trying to work with business users when you treat them like a cat. Karen wrote:

The worst part was not being able to explain to Frank why all this was going on. He had to be treated so there was no question about having to put him through this process. Unlike a business user, though, we don’t have the opportunity to prepare him for the event with good data, analysis of the cost, benefits, and risks of going to the veterinarian. He was blindsided by all of this.

All of this made me think of attending meetings where I really did feel like the cat and, like Frank, wanted or needed to lash out. Over the years I have worked in a number of different areas as both an employee and a consultant and there are times when I’ve been the cat or when I’ve treated others like the cat. We all know the meetings where someone feels like the cat…the person sits there and doesn’t understand what’s happening, they are reticent and don’t want to participate and they may get really defensive. All the while, you’ll be sitting there thinking “What’s the problem here? I just want to make it better.”

At one point in my career I managed a contracting organization and a major client hired a system integrator and bought a new ERP system to do their work management. The system integrator and the company justified this system to the Board of Directors based on benefits or savings and, in fact, the integrator would receive a portion of the savings as part of their contract. Of course we weren’t privy to all of the information, but they wanted us to participate and tell them we were happy and agree with everything they did.

Every time we had one of these meetings there was someone in there asking about benefits. We were okay with that if the benefits were real, but we also foresaw areas where there would be costs associated with using this system. The integrator and company would hold these meetings, lay out the process, ask about benefits, but never talk about costs. In fact, when we asked about costs and how they would be handled we were told that was an issue for another group.

Now I can go with the flow and work through a lot of issues, but just like a cat, eventually I’ll lash out if you keep pushing the wrong way. About halfway through the project we were having another meeting to discuss the process and I talked about how a certain part of the program should be configured. The IROC sitting across the table with pen poised above paper asked “and what’s the benefit of that?” My response was “I’m not going to tell you if there’s a benefit or not.” Everyone in the meeting stopped and looked at me and I said that we would have no further discussions or meetings to discuss benefits until we actually talked about the “elephant in the room”. The meeting was over. Then all of the contractors and the project sponsors had to have a big meeting to talk about what we were trying to achieve and how we should work together and that it was benefits net of costs so we got what we wanted, too.

Just like the cat, there are times when you have to lash out and make it a bit bloody for people to understand that you don’t like something. We business users don’t want to do that, but sometimes that’s the only way to make certain people listen.

So the next time you’re going into a meeting with a business user, another department, a vendor, a customer, etc. think about it. Have you been listening? Have you shown the others that you understand what they want and are working to make that happen?

A few nights ago I went out to have a look at a logistical marvel. There were 6 very large beer fermentation tanks working their way to a Molson brewery location on the streets in and around Toronto. First, you might not think that this was any big deal except that each tank holds about 1 million bottles of beer and couldn’t be taken through any normal routes. Second, you might ask why I would go out at midnight on a really cold night to see this, but the engineer in me had to see it up close to see just how big these things were and how complicated this was. The planned move and the progress were profiled through many news outlets and it was an interesting story.

What struck me about all of this when I was watching was just how complicated and involved this was from a project planning and logistics perspective. There were also key lessons in project management tat can be gleaned from this:

NOTHING Impossible Ever Is

When someone comes to you and says “we want to do this….can it be done?” The answer should never be a simple no. There may be reasons why it can’t be done, but everything can be done given enough time, effort and money. The key is to figure out how badly they want it done and if they are willing to pay for it. The impossible part of it might be that the cost is too much for what it is, but you won’t necessarily be the judge of that. As Jerry Weinberg says in The Secrets of Consulting, you should always frame it as “I can do that, but this is what it is going to cost”.

With the beer tanks, Molson’s knew they wanted to increase their production and they needed these tanks. The trick was to figure out the manufacturing, logistics and installation. Given the size of the tanks, building them somewhere else and shipping them to the site seemed impossible. But building them on site would have been cost prohibitive so they looked at other options and figured out that they could have the tanks manufactured in Germany and shipped to Toronto.

Find The Right Expertise

You might think that you are the experts and only your company or department can do the project you’re thinking about, but trust me when I say that’s not true. Unless you are on the bleeding edge of some new technology, everything has been done before by someone. Find them and either hire them or glean the information you need from them.

In the case of the beer tanks, Molson Breweries hired Challenger Motor Freight to figure out how to get the tanks from Point A to Point B. Challenger has experience with moving very large freight and could provide the logistics necessary to make it happen.

Think Outside The Box

As I said in the first point above, nothing is impossible. But in order to see the solution sometimes you have to think about the problem differently. You can’t just have a narrow focus and think in terms of how it’s always been done or you’ll never see the answer. The other point here is that if you are just looking at a problem from you’re own little world, or department, you might miss the bigger solution and end up with something that is sub-optimal.

To ship the beer tanks and get them to the brewery they wouldn’t fit on any planes so they had to come on a boat. Then there were all the logistical issues of getting them to the brewery. If you looked at this simply from bringing them to the port in Toronto you would think it’s impossible given the infrastructure and bridges and everything in the way. Instead, the tanks were shipped to Hamilton which is farther from the brewery, but it made it possible for the land portion of the shipping. From Hamilton it became a huge puzzle of taking the right combination of streets to avoid all underpasses and bridges where the tanks wouldn’t fit and dealing with the utilities and infrastructure that was in the way. For example, on the last night of the move, the convoy was on the same street that the brewery was on, but they had to turn off that street and take a number of others just to avoid an underpass before getting back on line to the brewery.

Stuff Happens

You might have the best plan in the world, but sometimes stuff happens. You have to be ready to adjust your plans and have contingencies in place in case it doesn’t work according to the plan. The key to project management is being able to see the holes and risks in your plan and be prepared to take action or adjust when it does go off the rails. The best project managers aren’t the ones that never have any problems with their plans, but the ones that adapt and adjust quickly and cohesively when things do happen.

The shipping and installation of the beer tanks was behind schedule. Even before they left Hamilton they were behind. The tanks got to Hamilton in November, but with delays and the holiday season they didn’t leave for Toronto until January 7th. The move itself from Hamilton to Toronto was supposed to take 4 nights. In reality it took 10. The weather played a factor as well as the time involved in moving the electricity, cable and telephone lines. The convoy had to be prepared to stop at different locations and adjust their plans as they went. On the night I watched, there were three sets of wires the tanks had to go over/under in a very short stretch and these all had to be moved out of the way. In some cases the wires were taken down and laid along the ground and in others they were lifted up out of the way.

The Entire Team Has To Work Together

On any project it isn’t just one person that has to do all the work on the problem, there is a team of people. The team can include internal people, contractors, consultants, suppliers, etc. Even in your own companies there may be other departments and people that you must rely on to complete your projects. The point here is that everyone must have the goal in sight and be working together to get there.

For the beer convoy there were trucks, drivers, spotters, supervisors, utility workers, police, etc. all working in concert to get the freight delivered. There were a number of different companies and organizations represented, but everyone knew the goal and what they were contributing to the project. While I watched, I could see the coordination in action and the way everyone was working together to get the trucks through their next obstacle.

Final Thoughts

There are a lot of things happening in the world around us that we can look at and study to learn about how it applies to our work and what we do. This project was a lot more complicated than most, but when it is broken down it really is just a bunch of steps put together to get a tank another 50 meters down the road. If you do enough of those 50 meter long tasks eventually you get the full 108 kilometers covered. You might be a few days late, but you’ll get there…