… de personas y sistemas.
Archive for January, 2010
Agile Project Managers
02 years ago
This article is a Spanish direct translation of the “Project Managers” section from the InfoQ Article named “Book Excerpt: Succeeding with Agile: Software Development Using Scrum“, which is about Mike Cohn’s book “Succeeding with Agile: Software Development Using Scrum“.
You can access the Spanish version of this article following this link.
Since the original article is written in English, I see no need to translate it. Please visit the original article here: http://www.infoq.com/articles/cohn-chapter8
Agile Analysts
02 years ago
This article is a Spanish direct translation of the “Analist” section from the InfoQ Article named “Book Excerpt: Succeeding with Agile: Software Development Using Scrum“, which is about Mike Cohn’s book “Succeeding with Agile: Software Development Using Scrum“.
You can access the Spanish version of this article following this link.
Since the original article is written in English, I see no need to translate it. Please visit the original article here: http://www.infoq.com/articles/cohn-chapter8
Breaks between Sprints
02 years ago
by Martin Alaimo
in Agile Projects
Last week there was a conversation within an organization I’m currently working on with agile implementation in creative services industry.
The key point was if there was a way of introducing a break between sprints; this is something that came out from a retrospective. The fact was that the team requested it, but the product owner was not in that same page, he actually didn’t want any break at all between sprints. His arguments were: We need sustainable peace and spend time doing work.
After discussing with both parties and having them exposing their point of views, I gave my personnal opinion to that:
I personally don’t think that having a break between sprints will attempt against sustainable peace. Sustainable peace is about rhythm, heart beats; it’s not about “continuous development”. I mean, we can have a fixed length sprint without alterations and a fixed length break; let’s say half a day. If we do that and preserve it through time, then we’re still having sustainable peace, correct?
Another totally different situation might be if we have random length breaks; like half a day after the first sprint, two days after the second sprint and one day after the third one. This will absolutely attempt against sustainable peace.
On the other hand, when talking about “continuous development”, I realized the PO was talking about getting people producing creative deliverables all time (designing, drafting, creating, etc)… ok, I would be very careful on that because people still need to be trained, regardless the industry they are at.
I personally come from the systems engineering industry, one in which anyone can be turned into a vintage programmer if he don’t get training or refreshes on latest technologies. Of course, this is somehow extreme, but it happens to all people regardless their industry.
It didn’t took too much discussion until we found a shared agreement on breaks between sprints: we decided to have the demo & retrospective meeting during the morning and a free space during the afternoon, there might be no planned work for those 4 hours at the end of each sprint (every 2 weeks).
What are they going to be used for? Well, there will be happening three different things during that time:
- Have the team attend training sessions or prepare training session on industry updates or
- Have someone relevant to the work they do to attend and have a discussion session with them in order to get updated and discuss about new approaches, new movements or latest industry events or
- Have the people contribute to the corporate blog, with an interesting article, or get them participate in online blog conversations, getting benefit for the web 2.0 opportunities
We’ll be monitoring closely how this goes… I’m very excited on this approach. I’d certainly recommend a break between sprints with this characteristics. 
Agile Triple Constraint
02 years ago
Back from vacations, the recently past year was an interesting one; full of changes and challenges. This upcoming year is one I’m very optimistic on; I see a lot of opportunities, discussion spaces and new fresh ideas coming up.
New Year: new blog post. This time, I’d like to write about one of the comparisons/competitions I hear the most in the agile world: PMPs in an agile environment.
Several times I hear questions or arguments from PMPs (I’m a PMP also) about how to implement agile, why agile doesn’t seem to fit on a PMI environment, and so.
There are lots of things going on in the PMI-Agile world, especially after mid-2009. A very interesting argument I heard so far is about helping PMPs change their minds and/or understand better the way agile works from a high level is:
Agile approach has three major areas:
- Engineering Practices
- Leadership Practices
- Project Management Practices
While focusing only on the Project Management Practices, we can talk about the so known “triple constraint”:
In any Project Management environment the most important variables to monitor when managing a project are: Scope, Time and Cost. (Also Quality, Client Satisfaction and Risk are; but for this opportunity we’ll focus just on the first three).
Traditional Project Management states that whenever you start a project, you start from the Scope. Once you have the Scope clarified enough you start playing with resources, assignments and sequence of activities, that will lead you to determine the Time it will take and the Cost it will have. Result: a pretty nice Gantt chart.
Then you go back to the business and/or sponsors; present the result and the typical reaction is: You’re asked to reduce Time and Cost.
Then, as a Project Manager, you start thinking about increasing the team, splitting the work in different phases, build things in parallel (increasing risk of course). The traditional challenge then turns into the traditional problem: very complex Gantt charts, with very complex dependencies that will require very hard coordination and tracking.
Instead, Agile Project Planning approaches the same problem from another direction; the starting point is Time + Cost: How much money wants to be invested for how long? This gives you a team for a certain period of time, and the commitment to deliver the best possible amount of software.
That way you have:
- A Fixed Cost: The team members 8hours of work).
- A Fixed Time: Time boxes, iterations, releases.
- A variable Scope: Then the Scope is the variable part of the triangle, which is injected into iteration after iteration and transformed into working software.
In my opinion, this is the clearest explanation on the different points of view from each of the approaches: traditional and agile ones. Don’t you?
Photograph by Yui Kubo: http://www.flickr.com/photos/yu-kubo/398714467/
