This week I got the opportunity to play around this week with a Microsoft Surface Table and turning the bloody thing on was enough of a pain that I thought I would share the experience.

The first switch you need to turn on is the AC adapter located at the back of the table.

To get to the second switch you need to remove the kick plate panel at the end opposite of the AC adapter.

After you press and hold that one for a couple seconds the table should power up and you’ll be presented with the login screen. The manual is worth reading (it’s a bit tricky taking off the end plate as you need to unscrew a bolt). But once you get it off the switch is pretty visible.

An excellent slide deck on the future of work.

Some of my favorite quotes:

• Project teams at work are beginning to resemble movie production teams.
• Ten years ago there were no social networks.
• Ten years before that we didn’t have the web.
• If you work in the web programming, online marketing, or mobile phone industries … you job did not exist 20 years ago.
• Who knows what jobs will exist 20 years from now.
• The people out of work today will soon find jobs again.
• But the work won’t be the same.

Good stuff.

Forming a team is always awkward at first. You are all new to each other, nobody knows what anyone likes or dislikes, and you are all in the same boat trying to figure out how you can all work together.

Instead of letting people stumble upon how you operate tell them upfront! You can do this in a clear focused way using what I like to call The Drucker Exercise.

The Drucker Exercise

The Drucker Exercise is a powerful relationship building exercise to help you and your team gel at the start of a project.

By sharing the answers to four simple questions:

• what am I good at?
• how do I perform?
• what do I value?
• what contribution can be expected from me on this project

you give your team the means to figure out how best to work with you, while at the same time setting expectations around how you can best work with them.

For example, spend two minutes thinking hard about what you are world class at and what you can do better than anybody else.

Understanding your core strengths is good to two reasons. First, it raises your level of self awareness (necessary for spotting opportunities where you can really shine). And secondly, it tells others where they can expect you to excel and where you are really going shine.

The next question to ask yourself is around performance.

How you perform is giving team members a heads on where your magic comes from. Are you a morning person? Let them know. That way they won’t schedule meetings with you during your most productive hours.

If you enjoy collaborating, but occasionally require moments of solitude, let them know that too so they won’t be surprised when you grab your laptop and head down to the coffee shop for some private brain storming.

The next question has to do with your values.

Values are about what you stand for. There are stake in the ground that let’s people know what’s important to you and what you care deeply about. Letting people know what you stand for is important because it gives them insight into what they can expect from you, and better predict how you are going to act and behave.

For example, say on your last project you were perpetually being asked to cut corners, hack, and take every liberty with the code base in the name of speed. Quality was all but thrown and the window and you felt bad coming in every day knowing you weren’t going to be able to do your best work.

If quality is important to you on this project then set that expectation upfront. Let the team know you are going to stand for shoddy craftsmanship. Your code is always going to be accompanied by a suite of automated tests you won’t tolerate bugs—of any kind.

Which brings us to our last question. What can the team expect from you on this project.

This question really gets into what role(s) you can be expected to play on the project.

If your a developer with a passion for user experience, let them know that in addition to cutting high quality code you would like to participate in designing the user experience.

If you were an analyst on the last project, but are now stepping into the role of project manager, let them know they won’t be able to count on you for analysis during this project as you will have your hands full learning the ropes of project management.

Setting expectations about roles at the beginning of the project is good because if there is any confusion about who is doing what, this brings it out on the table for all to see.

Then if any expectations need to be reset (including yours) you can do it before the project begins, and avoid having to reset expectations later.

Don’t wait

You don’t have to wait for a new project to do the Drucker Exercise. You can do it right now. Yes it takes courage to share this kind of stuff with your team. But when you do the response is almost always the same: “This was most helpful. Why didn’t you tell me about this sooner.”

Of course the real power of this exercise comes from doing it as a team and sharing your thoughts with others.

For the full story behind the Drucker Exercise get a copy of the paper Managing oneself and give it the full read. You won’t be disappointed.

One way agile brings immediate value to project teams, is by getting them to question the meaning of the work requirement.

Kent Beck, who put me onto this idea, says it best:

Software development has been steered wrong by the term
requirement, defined in the dictionary as something that is
mandatory or obligatory. The word carries a connotation of
absolutism and permanence, inhibitors for embracing change.
And the word ’requirement’ is just plain wrong.

Kent Beck Extreme Programming Explained: Embrace Change.

It’s hard to abandon a word that has so much history behind it, but abandon it we must because the word is simply wrong.

So the next time you are gathering requirements for your project, try using the word feature instead.

This will get your customers less tied to the things they don’t need, and give you more time stuff to focus on the 10-20% that really matter.

Friend and writer Staffan Noteberg has just realized his new book:

Pomodoro Technique Illustrated
Can You Focus, Really Focus, for 25 Minutes?

Pomordoro is time management tool for helping people focus.

In his book, Staffan shows readers how they can boost productivity, become more effective, and get more done with little more than an egg timer and 25 minute intervals.

The book is chalked full of useful techniques, practices about the Pomodoro technique, along with entertaining stories of how he practices Pomodoro himself.

But don’t take my word for it. Check it out for yourself here at the Pragmatic Programmer website. If you think you have a problem with time management, this could be the book you’re looking for.

Today, in the agile community, there are dozens of newsgroups spanning many topics. Here are a few interesting ones I regularly track and follow:

Extreme Programming:

http://tech.groups.yahoo.com/group/extremeprogramming

Domain Driven Design

http://tech.groups.yahoo.com/group/domaindrivendesign

Lean agile

http://tech.groups.yahoo.com/group/leanagile

Lean development

http://tech.groups.yahoo.com/group/leandevelopment

Agile testing

http://tech.groups.yahoo.com/group/agile-testing

Agile usability

http://tech.groups.yahoo.com/group/agile-usability/

Do a favorite newsgroup? Do share.

Just having gotten back from Agile 2009, there is a tension in the air that I find interesting in the agile community.

Most people / companies seem to get the mechanics of agile delivery. No one is debating the merits of writing unit tests, gathering requirements as user stories, and delivering functionality incrementally.

People get that.

What is more interesting is how companies, specifically senior management, are reconciling this growing wave of common sense and pragmatism that agile brings to project delivery, as it bubbles up within their organizations.

The tension I am referring to is how companies with traditional command and control style structures reconcile the brutal honesty and visibility agile brings to projects and portfolios.

No longer can management remain blissfully unaware of how their projects are doing. When the true state of a project is revealed, and it conflicts with the edicts and lightning bolts thrown down from up high, some tough conversations will need to be had.

As agile gains in popularity, and the dysfunction of how we have traditionally managed and run projects becomes more clear, it will be harder for command and control style management do just say ‘do it!’, when there is measured, tracked compelling evidence indicating others wise.

So if you’ve had great success with agile at the project level, and you are wondering how to capitalize on this and transition it to the next level, take comfort in knowing that you are not alone. Many are undergoing the same journey.

For some the transition will be smooth.
For others it will never occur.

The good news is that the conversations are occurring. And those companies that make the transition will reap the rewards and benefits that come from having an energized, self-organizing, continuously improving eco-system upon which to build compelling projects and services. And others will continue (some very successfully) with what they have done before.

I just finished David Price’s excellent book titled The Pixar Touch.

It is chalked full of great stories, interesting anecdotes, and is a testament to the shear will power, and creativity of folks like Ed Catmull, John Lasseter, and Steve Jobs.

Here are some little known facts about Pixar:

• Pixar, not Apple, made Steve Jobs a billionaire. Jobs bought Pixar in 1986 from Lucasfilm for $5 million. In 1995, the week after the release of Toy Story, Pixar went public and Jobs’s stock was worth $1.1 billion.

• Ed Catmull, Pixar’s co-founder, dreamed as a youth of becoming an animator, but decided in high school that he couldn’t draw well enough. Instead, he became an early visionary of computer animation as a graduate student in the 1970’s. “Computer animation was sort of on the lunatic fringe at that time,” remembered Fred Parke, a fellow Ph.D. student in Catmull’s class at the University of Utah.

• When John Lasseter joined Pixar—which was then the computer graphics department of George Lucas’s Lucasfilm—he had just been fired from his dream job as an animator at Disney. He became the first person to apply classic Disney character animation principles to computer animation.

• To learn how to make a realistic French kitchen, the producer and first director of Ratatouille worked as apprentices at an elite French restaurant in the Napa Valley.

• Before it became an animation studio, Pixar went through years of struggle and multi-million-dollar losses. It started as a computer company and John Lasseter’s short films, such as Luxo Jr. and Tin Toy, were promotional films to help sell the company’s computers.

• Pixar was almost bought by…Microsoft? Yep: Jobs remained worried about the company’s finances even after Pixar made a deal with the Walt Disney Co. in 1991 to produce Toy Story, Pixar’s first feature film. The Pixar Touch details the effort to sell Pixar to Bill Gates’s company while Toy Story was in production.

• When writing Toy Story, to find inspiration for the relationship between Buzz and Woody, Lasseter and his story department screened classic “buddy” movies, including 48 Hrs., The Defiant Ones, Midnight Run, and Thelma & Louise.

• John Lasseter has instilled an intense commitment to research in the studio’s creative staff. To prepare for the scene in Finding Nemo in which the fish characters Marlin and Dory become trapped in a whale, two members of the art department climbed inside a dead gray whale that had been stranded north of Marin, California.

• Pixar deliberately avoided making the humans in The Incredibles look too realistic. They knew that as animated human characters became too close to lifelike, audiences would actually perceive them as repulsive. The phenomenon, known as the “uncanny valley,” had been predicted by a Japanese robotics researcher as early as 1970. Thus, the details of human skin, such as pores and hair follicles, were left out of The Incredibles’ characters in favor of a more cartoonlike appearance.

• The signature of most Pixar feature films is characters who appeal to children (toys, fish, monsters…), but who have adult-like personalities and are dealing with adult-like problems.

• Prior to the acquisition of Pixar by Disney in 2006, Lasseter loathed the idea of Disney making sequels to Pixar films without Pixar’s involvement—as Disney’s contract with Pixar allowed it to do. “These were the people that put out Cinderella II,” Lasseter remarked.

• Pixar is more than an animation studio. Pixar’s innovations in computer graphics technology pervade movies today. Special-effects houses like Industrial Light & Magic (Pirates of the Caribbean: Dead Man’s Chest, The Chronicles of Narnia: The Lion, The Witch and The Wardrobe, Harry Potter and the Order of the Phoenix) use Pixar’s software to create out-of-this-world places and characters.

(taken from amazon review)

If you want to learn more about the incredible journey this company underwent, you can read the book.

Or you can watch the equally good documentary : The Pixar Story.

I recently started playing a bit of a release manager role for some projects at work, and one of the interesting conversations I’ve been having with people are the merits of slicing projects horizontally vs vertically.

Horizontal slicing

With horizontal slicing, projects are broken up roughly along architectural lines. That is there would be one team for UI, one team for business logic and services (SOA), and another team for data.

One advantage of slicing your application horizontally, is you get good communication and consistency within each slice. Everyone does things the same way.

The downside of slicing your projects this way, is that until you integrate every thing together, you really haven’t delivered anything of value.

Your customer can’t go into production with screens, services, or well normalized database schemas.

Only when all the layers are hooked up do they offer any value.

That’s why agile is so big on slicing projects vertically.

Vertical slicing

Agile is very big on the concept of one team. There is no UI, SOA, or data team. There is only one team, focused on delivering a suite of features for the customer.

The other advantage of slicing vertically is you are more efficient. You don’t have the overhead, and effort that comes from trying to coordinate activities across multiple teams. No need to negotiate for resources. You’re all on the same team.

No. Not always.

Whenever you have legacy systems (mainframes), core business entities consumed by many across the enterprise, or anything where the technology dictates how the application needs to be built, you may be better off slicing that body of work horizontally.

That doesn’t mean you can’t work with them in an agile fashion. More that they will have a certain way of doing things, and you will have to adapt.

So go vertical when you can. And horizontal when you have too.

Thanks to John Kordyback for sharing his thoughts on this subject.

Driving home from the lake today, it occurred to me that not all forms of pain on a project are bad. In fact some are pretty good.

Take bug tracking for instance.

Do you want a tool that makes tracking bugs nice, friendly, and easy to use?

Or do you want something that is slow, cumbersome, laborious, and so painful, your team would rather fix the bug than report it.

A painful bug tracker may be a great pain to have on your project.

Let me know if you can think of any others.