Project Managers...

...get in the way.
...interfere.
...tell people what to do.
...tell people what not to do.
...tell people when to do this and when to do that.

Project Enablers (aka ScrumMasters)...

...give people what they need*, get out of the way and let them accomplish their goals.

*what they need: clear goals, a cross-functional team with an embedded QA and someone to ensure everyone is aligned.

If you want to be effective, make sure everyone is co-located.

If you're not co-located and can't be, that's fine but just be aware of the drop off in communication effectiveness and try to compensate.

Taken from Alistair Cockburn's Article

When I got back to the office after my Certified Scrum Master training, I didn't know what to do. I knew all the theory but I didn't know what to do next.

"Well...I suppose we try it", I thought, "Let's start with a taskboard" and so we made a taskboard.

Then we had a daily scrum meeting.

Then we did a planning meeting, then we tried a retrospective and then a review meeting and before long we were doing Scrum.

Then we started having problems because the client/PO kept changing things so we learned about Kanban and got rid of the iterations (or vice versa, I can't quite remember). On some projects, having iterations worked so we kept them.

Then we realised the product backlog was often in bad shape so we started training the PO and making her understand what happens when the product backlog is in bad shape.

Then we started fixing problems in the code by adding a "Code Review" column to the taskboard.

Then we made a google doc for one of our projects for our client in a different timezone and used it as our taskboard (we had our daily scrum meeting around the google doc), this gave him 100% visibility on what we were doing and when (and who).

Today I learned about "Crystal Clear" created by Alistair Cockburn (say: "co-burn") which I'm now reading about. Maybe we can borrow some things from that.

You see, for me (us) it wasn't about doing Scrum or Agile or Kanban or whatever but was about creating something that works. If it works, keep doing it; if not, change it!

As Seth Godin puts it in a post I just read:

"The Simple two-step process

Step one: Open all doors. Learn a little about a lot. Consider as many options as possible, then add more.

Step two: Relentlessly dismiss, prune and eliminate. Choose. Ship."

http://sethgodin.typepad.com/seths_blog/2011/02/the-simple-two-step-process.html

You have to feel sorry for the Product Owner, they do have a difficult job after all.

They have to manage both the client AND the development team, break down requirements, answer questions and understand all of the features of the product in detail.

With all of these responsibilities, it can be easy to lose track of everything so here's a list of things that every Product Owner should bear in mind.

Think of it like the 26 commandments of being a Product Owner.

1. Be humble.
2. Be available. Understand that you are the lifeline for the team. If the team has a question for you during an iteration, finding the answer is your number one priority. This will help you to gain the team's respect.
3. Don't keep the team waiting a long time for an answer, you will lose their respect.
4. Never ask the team to do something that you don't understand, you will lose their respect.
5. Never lose the team's respect.
6. Understand exactly what the client requires. Explain this to the development team.
7. Be completely transparent with both the development team and the client in terms of features, priorities and the team's commitments.
8. Give the client full visibility on all problems that affect deliveries.
9. Give the team full visibility on all problems the client has.
10. Respect the team's estimates.
11. Respect the team.
12. Respect the client.
13. Prepare in advance the features for the next iteration (i.e. add detail and priorities) and don't insult the development team by providing half-baked detail - ask any obvious questions to the client before asking the development team to estimate.
14. Have at least a basic understanding of what the team has to do to translate the client's requirements into working software. Ask the team to explain if you don't understand.
15. Do not make any changes to requirements or add things once an iteration has begun.
16. Explaining the business case for each feature can help the development team understand where the client is coming from.
17. Consider yourself a service department for the team. You're the team's "bitch" and whatever question they ask, you have to find the answer.
18. Be nice. The team is not your "bitch", consider them a friend doing you a favour.
19. Consider yourself a service department which the client uses to achieve his goals.
20. Train the client on the Scrum/Agile process and make them understand that they are the most important part of it and key to delivering a successful project.
21. Do not micromanage. Do not even get involved unless asked by the team or the ScrumMaster.
22. Be present at all of the meetings: Planning, Review and Retrospective. You can attend the daily scrum meetings but you're not allowed to speak unless asked by the team or the ScrumMaster.
23. Remember that you have no power over the team. You're not their boss and you're only allowed to tell them what is priority and to explain to them the tasks. After that, the team will give their estimates.
24. Grow a pair. Learn to explain to the client that the team's estimates and planning has to be respected.
25. Swallow your pride. Ask when you're not sure (whether it's the client or the team).
26. "I don't know" is not an acceptable response to a question from the development team. "I don't know but I will find out and get back to you within the hour" is.

And here it is in PDF format for printing and sticking on the wall.

It's like a donkey chasing a carrot. You can never reach it, you can just keep moving closer towards it. It's a "concept designed to spur us on to greater heights"*.

Nothing will ever be perfect, so accept it and move on. Once we do that, we can be at peace with ourselves and those around us.

Instead of starting a project with "this is going to be perfect", it can be better to acknowledge the fact that people are going to make mistakes but that despite this we're still going to try to move in the direction of perfection, not as individuals but together as a team.

*In search of perfection by Edward Dreyfus

"Using no way as a way, using no limitations as a limitation." - Bruce Lee

As with people management, I prefer to take each project as it comes and adjust my style to the project at hand. I don't have a set methodology in mind when a project comes up. What I have instead is a framework and a toolbox of useful things that I know has helped me in various situations in my previous projects.

Project management is not doing things by the book (whether the book is PMP or Scrum or Agile or whatever), it's about doing what's best for the project right now.

But how do you know what's best for the project? a) experience, b) by trying things out (this leads to experience)

With experience, you begin to realise that some things may only work for certain projects at certain stages of development (maintenance, beginning of a project etc).

I always try to change, improve and add things to a project to see if they can help. If they do, I continue doing them. If they don't, then I'll try something else.

In 99% of cases, you shouldn't start developing anything until the client has signed off on it.

If it's design, make sure the wireframes are signed off. If it's HTML, make sure the designs are signed off. If it's coding, make sure the project specification is signed off.

Be tough with the client and get him to understand that you need him to sign off on everything before development starts.

The penalty of starting before you have sign-off is redoing work that could have easily been done right the first time. Like a friend of mine says, "it's a waste of moves": you only get so many moves in life, even fewer on projects with tight deadlines, so don't waste any.

(Of course getting sign-off is not guaranteed to save rework but it's a step in the right direction; the client who signs off and changes his mind later is for another post...)

The definition of a Product Owner is quite simply the person who owns the product: the person in who's head are all of the ideas and features for the product.

It's very important that during development, this person is easily accessible and available. Questions can come up all the time and the development team needs someone who can answer those not after a day or after 8 hours but as and when they arise.

The ideal situation would be the Product Owner who sits just a few metres away from the team. Far enough away so that he's not interfering every 5 minutes but close enough so that within 5 minutes the team can have answers to their questions.

Each member of the team should have a direct line to this guy. He's like an intravenous line keeping the team going. As soon as he's out of shouting distance, the team/product/project starts to die. When he comes back in question-answering distance, it's like turning back on the IV.

Zappos.com have a thing called WOW customer service.

It's a minimum level of service quality accepted from all customer service agents and is designed to make the customer come away saying "WOW, that was brilliant".

It's something that we can all adopt whether we're a Developer, a Project Manager, QA engineer or an Account Manager.

In all of our interactions with people both internal and external to the company and in all of our work, we should aim to make people say: "WOW, that was brilliant".

If we make "WOW", the minimum accepted level, the sky's the limit for improved quality, customer satisfaction and internal processes.

A cowboy coder is someone that doesn't care about the quality of his work and the impact that it will have on other people or systems.

He's content to deliver low quality, buggy, poorly designed work to team members, QA and clients and he's happy to rely on these extra people to find bugs instead of finding them himself.

His code is hard to read, maintain and test.

He lacks dedication and passion.

He's lazy.

That's the problem, what's the solution?

Try training and one on one coaching.  If he doesn't respond, remove him from the team.

If you have a cowboy coder, it's important to act quickly and decisively. Just ignoring it and crossing your fingers is the worst thing you can do.