Getting Things Done – Review

This is the fourth article in a series providing a summary “book club” reading of Mr. David Allen’s  “Getting Things Done”. I’m reading from the 2001  Penguin Books edition.

This is a very important phase of the entire process. It´s one thing to write down all the actions, for example that you need milk. But it’s useless if you don’t look at the list when you are in the milk shop…

The first review is very simple and just requires to check your calendar and your next Action list (maybe just the actions you tagged @phone if you want to make some call or @computer if you want to start some work there) and it happens whenever as often  as you need, so a good habit is to check them daily. [article]

A critical review is the weekly one: all your open loops, i.e. the projects should be checked once per week. Then you would gather and process all the new stuff, review your system, update the lists and get ready for the next week.

Allen uses an altitude analogy to illustrate his model to review your own work with 6 different levels of focus,which are:

  • at 15K meters: Life mission (the big vision).
  • at 12K meters: 3 to 5 years vision
  • at 9K meters: 1 to 2 years goals
  • at 6K meters: Areas of responsibility (such as job commitments or health, finance, home, etc.)
  • at 3K meters: Current projects
  • at the ground: Current actions

These perspectives should give you which are the priorities which then tells you on which projects and actions you should concentrate your efforts.

Next: the projects planning

Advertisements

Agile software development – an introduction and a brief history

Agile software development is on great advance, more and more software teams adopting it. But what is it exactly?

It’s a development approach, where the entire process – from planning to requirements analysis and design to the programming, test and deployment run through several repeating short cycles (iterations), auto-adapting themselves.

It’s a set of best practices (not a formal process) with roots in many modern management approaches as the lean manufacturing (famously introduced at Toyota), the evolutionary system (Evo) from Tom Gilb, Scrum and the Extreme Programming, and partly a reaction from the heavily regulated waterfall model (http://en.wikipedia.org/wiki/Waterfall_model).

A turning point happened in February 2001, when prominent members of the “lightweight methods” community met and created the Agile Manifesto and later founded the Agile Alliance. The name agile was also coined at that meeting.

As you can see on the site the manifesto lists a series of value (on the left) preferred over related commonly used values (on the right). Before we look into the details, a very important note from the Manifesto:

“That is, while there is value in the items on the right, we value the items on the left more.”

The manifesto says that they value:

Individuals and interactions over processes and tools

Projects are built around individuals. People are the most important variable in a project and this should not be forget.
Interaction refers to the communication in the team and among the stakeholders; agile methods always push to foster communication at any level and time. In concret: if you have doubts or questions, ask directly your colleagues and the project stakeholders, don’t just rely on the process steps or the tools.

Working software over comprehensive documentation

As you say: “if the territory and the map disagree, trust the territory”.

Working software is the principal measure of progress, despite what a project plan or a design document can say, only it can really tell you where you are with the project.
This is also why agile methods favour frequent software deliveries.

Customer collaboration over contract negotiation

and

Responding to change over following a plan

A project is there because someone sponsored and founded it. Every project has one or more customers who have the final word about whether was successful or not. This is so critical that most models, as the waterfall one, are investing a big amount of the project life into defining, assessing and documenting the requirements, producing at the end a formal negotiated contract.
This is working fine if:
1. the requirements, the customers and the business scenario are not changing for the entire project life.
2. the requirements are well understood.

I can’t think of very few projects where these are true.

The agile answer to that is to allow requirements to change, even late in the process and to have a daily cooperation with the customers, also after the initial requirements definition phase.
Having frequent software deliveries is also part of the effort to satisfy customers first of all.

Next: the problem with the waterfall method

PM – 4: Project Life Cycles

This is the fourth post in a series where I will write down what I learned about project management.

As said in the first post, a project is a temporary endeavour so it has a definite beginning and an end.
The project life cycle defines the phases that connect the beginning of a project to its end.
The life cycle phases depend both on the kind of project and on the project environment (i.e some organizations have established policies that standardize their projects or there could be industry common practices which lead to a preferred life cycle).

Sometimes the life cycle phases are well defined and there is a technical handover orProduct and Project Life Cycles a sort of tollgate between one phase and the next but very often a phase begins prior to the approval of the previous one’s deliverables (overlapping phases).
Generally typical phases are an initial phase (low cost and staffing), one or more intermediate phases (peak) and a final one (ramp down).

The life cycles define:

  • what technical work to do in which phase (for example, the architecture should be done all in the initial phase or spread into all initial and intermediate phases?)
  • when the deliverables are to be generated (e.g., at the end of well defined phase or multiple times into the phase?)
  • who is involved in each phase
  • how to control and approve each phase and each deliverable

Each phase is characterized by the completion and approval of one or more deliverables (i.e., a measurable and verifiable work product such as a specification, a feasibility study, a design document or a working release).