Everybody's a Project Manager, Part 4

This is part 4 in a list of key project management tips and techniques. See also part 1, part 2 and part 3.

This, final part, is about the role of the project manager / scrum master in a scrum team.

  • Decisions must be made within an hour.
    • A bad decision is much better than no decision.
    • When solving problems, 1) define the problem, 2) uncover dependancies, 3) look at possible solutions with the scrum team, 4) ask the customer if necessary.
    • Remember the stupid solutions, sometimes they’re the best ones but no-one dare say them out loud.
    • Be honest!
  • Prepare for each iteration (sprint): define or reiterate goals, scope, visions and threats.
    • Make sure the physical surroundings are in order.
    • Make sure any needed software or hardware is available.
    • Double check that your team is the right team and can actually solve the tasks ahead.
    • A good team consists of no more than 7, preferrably all in the same room. Desks with wheels can mobilize you.
  • Projects work out the best if the team is happy and energetic.
    • Change is good.
    • For boring tasks, reiterate the vision and the tasks place in the larger whole.
    • Money can be a motivator, especially for the dead-end tasks.
    • Passionate people transmit their energy to others.
    • Ensure that all tasks are clearly prioritized.
    • Take note of tired project members and give them a day off, or reward them in some other way if you can’t.
  • Beware of these energy-drains:
    • … having too many (or too few) tasks
    • … shifting task priorities or attention
    • … lack of communication
    • … wasted work
    • … uncertainty about project roles
    • … impossible plans
  • A good project manager is like a parent and …
    • … a “firewall” for incoming tasks
    • … helps divide tasks between team members
    • … minimizes wasted time
    • … is generally hands-off and silent and only the tyrant when necessary
    • … lets the team make their own decision and plans
    • … visualizes project progress on walls or via physical means
    • counts to ten
  • As a project manager, DO NOT:
    • … tell the team what to do and how
    • … plan iterations yourself – involve your team!
    • … update the sprint backlog (iteration to-do list) – let each responsible team member do that themselves
  • To ensure discipline in a team, give responsibility to the team.
    • This will give a sense of project ownership to team members.
    • Anticipate an overhead of administration and “fire suppression”. Some times, planning only a 4 day week is necessary, leaving the 5th for the overhead.

Everybody’s a Project Manager, Part 3

This is part 3 in a list of key project management tips and techniques. See also part 1, part 2 and part 4.

  • Scrum is all about optimizing time and ensuring maximum production.
  • When working on projects with a team, hold daily Scrum meetings
    • These meetings are held at the same time, and the same place
    • The same questions are answered: What’s done? What needs doing? Are there any blocks? New decisions? What’s new in the sprint backlog (iteration to-do list)?
    • Meetings are 15-20 minutes, 7-10 people.
    • No chickens (involved), only pigs (committed). (Concept taken from a joke).
    • If there are any blocks, it is the task of the Scrum master to remove those prior to the next meeting.
  • Good Scrum meetings start on time (preferrably in the morning), finish on time, are predictable and participants have prepared.
    • Scrum meetings ensure that new problems are uncovered and they give sense of project sync and overview.
    • Meeting times, like deadlines are to be met!
  • Assertive communication is important in Scrum.
    • Teach yourself to be assertive, neither defensive (silent) nor aggressive (loud).
    • Learn new things, don’t just turn on the auto-pilot.
    • Talk less (shut up!), listen more.
    • If there’s something you do not understand, ask questions.
    • Know that you’ll most likely hear what you want to hear.
    • Leave your ego at home.
    • Respect yourself and others.
    • Pay extra attention to the submissive participants.
  • Ensure quality by picking improvement areas using a Pareto chart.
    • The Pareto chart follows the 80-20 rule (ex.: 80% of all traffic accidents are caused by 20% of the drivers).
  • At the end of each iteration (a.k.a. sprint), hold a sprint review.
    • A sprint review consists of: 1) demo, 2) sign-off chart for the customer, 3) delivery plan review, 4) problem review, 5) idea brainstorming.
    • A sprint meeting is no longer than 4 hours.
    • The customer can be part of the meeting; the sprint delivery (product so far) is demonstrated.
    • The purpose of a sprint review is to (further) define function and design as well as SWOT.
    • PowerPoints are banned.
    • Brainstorms between production team and customer (if present) are encouraged, but no entries are added to the product backlog. Leave that for the Sprint planning meetings at the beginning of the next iteration.
    • If the sprint review is held the day before the last day of the sprint, the last day can be used to iron out minor bugs that popped up.
  • Due to the nature of agile development in sprints, budgets are different from traditional budgets.
    • The customer may have to accept rolling forecasts that can change, for better or worse.
    • For your own benefit, create a single budget/time overview document at the end of projects. Was the ROI (Return On Investment) okay?
    • Be honest.

Everybody's a Project Manager, Part 2

This is part 2 in a list of key project management tips and techniques. See also part 1, part 3 and part 4.

  • No single management model will work for all types of development. Pick the one, or parts of the one that works for you.
  • Each management model is essentially a toolbox. Use only the tools you need to solve your problems.
  • For software development, the Scrum model has benefits over the traditional “waterfall” model.
    • Because Scrum deals with sequential, delivery-oriented work iterations (sprints), it’s easier and cheaper to backtrack when encountering changes.
    • Because Scrum is delivery-oriented, it allows developers to be accomodating when the customer makes new requests.
    • Scrum encourages code and project refactoring; that means it encourages doing things right rather than doing things quickly.
  • Defining a manifesto of company values helps to clarify the overall direction and game rules of a company.
    • A manifesto can be used as a code of laws for whether or not to take new jobs.
    • Build the manifesto by a) writing down values on stickies, b) grouping stickies together, c) assigning points to each group and d) picking only the 5 top scoring groups.
  • Every week, evaluate what parts of the code can be recycled for other projects.
    • When evaluating parts to refactor, sort ideas in “keep this” and “try that” groups.
  • When building an iteration task list (sprint backlog), a good use case can be helpful in translating specific goals into managable tasks.
    • Use cases come in many sizes. They can be as elaborate or as simple as is necessary.
    • A good use case can help identify unknowns (the “black box”), and can translate user-terms to a product backlog (project to-do list) of tech requirements.
    • A good use case has pictures and sketches.
  • During an iteration, move completed tasks from the product backlog (project to-do list) to the sprint backlog (iteraion to-do list).
  • During tight deadlines, it is helpful to evaluate the time needed to finish the product backlog—every day.
    • To give an overview of deadlines, a Gantt chart is helpful.
  • Using the Agile model (working in iterations), iteration end-dates are set in stone. If you can’t finish all sprint backlog items, move some items back to the product backlog.

Everybody's a Project Manager

Along with a few colleagues, I’m taking a project management course at work. We’ve learned many things already, one of them being that verbal communication is much more effective than textual, which is why this list of tips and techniques is presented to you in scannable bulletform.

This list is the 1st of 4, and is a general introduction to Agile development (Scrum). See also part 2, part 3 and part 4.

  • Using the agile project management method, work in iterations (a.k.a. sprints) of two or three weeks and make deliveries at the end of each iteration.
    • While the overall goal and vision of the product is specified at the beginning, only the first iteration is actually spec‘ed out. This is called game planning.
    • At the end of each iteration, the customer will have to approve the delivery and participate in working out the spec for the next iteration.
    • Iterations with fixed durations will give a sense of rhythm, produce visible results, and let the customer know when to be available.
    • If a specific task takes more than 16 hours, divide it into two tasks.
    • On huge projects, documenting project estimates can be a delivery in itself.
  • Instead of working under varying work pressures, strive to find a balance that provides an even pressure—a pressure that people can continuously work under.
  • Embrace change. Unknown factors will appear during the course of the project.
    • Change the plan, not the project.
  • Make daily standing meetings. This will ensure meetings are short and concise.
    • At least one meeting in the morning, if necessary one after lunch.
  • Prioritize tasks using the MoSCoW method (Must have / Should have / Could have / Won’t have). Put as few things in the “Must have” pile as possible.
  • Keep documents simple. Preferrably a single page per:
    • Project schedule
    • Iteration task list
    • Business case (is it worth it?)
    • Risk analysis
    • Initiation documents like these are alive and to be changed during the course.
  • Digitally photograph whiteboard notes. It’s faster than typing them down.
  • Finish projects and close them.

Hard-earned Advice for Creative People

Say no by default

Having worked with design for quite a few years now, I’ve learned my share of lessons and picked up a few do’s and don’ts. For your reading pleasure, here they are, neatly compiled into bullet points. Your thoughts on these are most welcome. Oh, and feel free to chime in with your own advice.

  • Design matters much less than you think.
  • People viewing your design will have a radically different understanding of it, than you have.
  • Being creative on demand gets easier the more routine you get.
  • If in doubt, add an outline.
  • Sometimes, we must let go of the things we appreciate the most, in order to do what is expected of us.
  • Learn to save often.
  • For the tedious repetitive things you do, if you can, create tools or processes to do them for you.
  • Say no by default. If someone asks you to lift a finger, your no brainer response should be “No”. Only when you’ve thought long and hard about it, consider saying yes.
  • Stay miles away from people who tell you things like “do this for free and I’ll get you other clients—I know people in the business”.
  • Never do creative work for family members.
  • Forget about perfect. Nothing is perfect. Nothing can be perfect. Also, nobody looks close enough to see it’s not perfect.

De Bono's Simplicity Principles

A long while back, I stumbled upon a snippet of wisdom. Fortunately, I wrote it down, because the website that held this info is down. I have managed to track down the source to a Mr. Edward de Bono. His book, “Simplicity“, is available at Amazon.

The snippet of wisdom is related to achieving simplicity in designs. I am storing it here as much for your convenience, as for mine.

Continue reading “De Bono's Simplicity Principles”