… de personas y sistemas.
Posts tagged Experiences
Agile Open La Plata 2009 Results
02 years ago
On Saturday June 20th the Agile Open La Plata 2009 took place, more than 65 people attended.
After having breakfast, we did the official opening, which I facilitated. An incredible experience: it was my first facilitation in an Open Space model. At the beginning, it was exactly as we’re used to see in these kind of events: people does not understand the expectations on them until after 10 minutes of actual work, the result was almost 40 sessions proposals, a very fluid voting and the following schedule:
Agenda AO La Plata 2009
I highlight some sessions I was able to participate in, all of them of an excellent level:
Lean introduction (facilitated by Juan Gabardini) and Agile introduction (moderated by Nicolás Paez) were the first two sessions. I saw people very engaged on the topics, I admit it was hard to stop those sessions on-time due to the atendees’ enthusiasm.
The starts of the second track were SCRUM intro (proposed and moderated by Marcelo Belnicoff) and Agile Team Communication (moderated by Nicolás and Esteban).
Lunch arrived on-time, there was an excellent climate where people exchanged concerns, experiences, questions, solutions, doubts, opinions. A great networking context.
We started the afternoon with the “Pajarraco” Game, during which I took some photos (taken with my cell phone) and a lot of other parallel sessions, more advanced ones in which I was lucky to participate: CMMI+PMI+Agile, Scrum with very little teams, Agile Testing, How to engage the client in Agile Projects, Non IT-industry implementations of agile methodologies, etc.
* Pajarraco Photos:
After a coffee break during the afternoon, there was an interesting debate about Retrospectives (open discussion format) and an Agile Architecture presentation (by Diego Fontdevila).
We reached to the closure with more than 40 people. It was facilitated by Diego with excellent results, as we’re used to in every Open Space: great people interaction, highly engaged & active people,really interesting topics, living experiences, etc. The result was more than positive:
Resultado AO La Plata 2009
The next steps we’re taking at “La Plata” level is to organize a monthly event where to discuss agile topics following the same approach that has been working for months in Buenos Aires, while at a national level we still have the organization and realization of the Rosario, Mar del Plata and Bahía Blanca Agile Opens. And any new city who wants to have one.
A new Agile Open was finished, and -same as the previous ones- it left it’s footprint.
Fying Post-Its
02 years ago
by Martin Alaimo
in Experiences
A few days ago, in the Agile Latin America Community (http://tech.groups.yahoo.com/group/foro-agiles/message/1738), the Flying Post-Its topic was discussed: they fall down, they fly, etc. from ScrumBoards or TaskBoards.
The recommendations were several of different kinds, i.e:
- the usage of “super sticky” Post-Its,
- Scotch Magic tape,
- UHU Tac bar
- Magnetic boards.
In my last 2 experiences applying Scrum on delivery teams we tried using cork boards, regular post-its and Push Pins supporting them. The first implementation of this kind raised by chance; we were waiting for the arrival of the regular board and in the meantime, using easel-pads (Fig.1). Due to the delay in the delivery of the regular board, we made use of a cork board that wasn’t being used at all, we started attaching the post-its to it, but they immediately start falling down. We rapidly used Push pins to attach them to the cork board, preventing them to fall down (Fig.2).
By doing this we found out 2 benefits, apart from avoiding flying post-its: 1) being able to attach a big amount of post-its with a single push pin (Fig.3), using less space (ie. in the “pending” section), and 2) using different colors of push pins for each team member (Fig.4), making it easy to identify the person working on each post-it.
References:
- Fig.1: Easel Pad board @ Accenture – SCM Team
Fig.2: Cork Board @ Gorricho
Fig.3: User Story + Tasks in "Delivered" section @ Gorricho
Fig.4: Each member one Color
Unplanned Tasks
02 years ago
by Martin Alaimo
in Experiences
While I was implemneting SCRUM in a client, as part of a project management consulting engagement, we discovered he worked under two different delivery models that we deliverately called Planned Tasks and Fires.
The concept was that the Planned Tasks were all the ones coming out from the BackLog and included in the Sprint during the planning meeting, while the Fires were all tasks included during the Sprint itself, without prior planning.
The reason behind this decision was that the client works with initiatives, planned deliveries, commitments done in advance, and –in parallel–, maintenance agreements with a certain amount of hours assigned per month, where tasks were accomplished without any kind of planning.
The initial decision
We first decided to take BackLog Items and transform them into Story Cards, which in turns were broken down into Planned Tasks. This activity was accomplished during the second part of the planning meeting, where all the team breaks them down. While this was done, the TaskBoard was filled with Planned Tasks, placing them in the second column, called To-Do; leaving the first one (Commited BackLog) for the Story Cards.
If there was any unseen maintenance/urgent task not able to wait to be completed during the next Sprint, then, it was inserted in the To-Do column of the TaskBoard as a Fire, in the middle of the sprint.
When to add them?
The first challenge we faced was to determine when those Fires would be added to the TaskBoard. We discussed four different possibilities:
1. At any time: The idea was to add the Fires immediately after they were detected or committed to be delivered. The problem we found with this approach was that adding them in the middle of the day wouldn’t give them enough visibility, what leads them to be known by the rest of the team in the next Daily Stand Up Meeting.
2 y 3. Before/During the Daily Stand Up Meeting: Adding them to the TaskBoard 10 minutes before the Daily Stand Up Meeting or during it to give them more visibility. The issue is that the meeting would take unnecessarily longer than expected due to the discussions triggered regarding the new Fires, instead of using the 15 minutes that were available focusing in the real objective of the Daily Stand Up Meeting.
3. After the Daily Stand Up Meeting: We considered also adding those tasks once the meeting is over to avoid making it too long. What we found out was that showing those Fires would modify the plan for the rest of the day, turning the discussions done in the Daily Stand Up meeting useless.
Finally we decided to follow the first option: “the Fires would be added to the TaskBoard at any moment, just in time”. The way we found to give them visibility was that the member of the team adding them would notify the rest before doing that. A more noisy option I considered was to attach a horn to the TaskBoard in order to get the person adding the Fire using it to capture the attention of the whole room… but for the moment, I’ll keep it in my BackLog.
How to visualize them?
A second challenge to solve consisted on how-to make the different kind of tasks differentiated from each other. Our first choice was a solution posted by Xavier Quesada Allue on his blog Visual Management: leave an empty workstream on top to track the Fires. The post is called Unplanned Items and Legacy Issues.
After discussing a while, we decided that even though Xavier’s solution would work perfectly in most of the cases, the particularity on this case was that some Fires have certain Buffer that allows other Planned Tasks to be fineshed before moving into them, and we should reflect that.
Finally, we decided to use Post-Its of different colours: Yellow ones for Planned Tasks and Orange ones for Fires, leaving this way the vertical dimension to reflect priority.
Result:
Although in the implementation we found some characteristics to improve (that I’ll address in a later posts, and how we actually solved them) the result was the following one:
1. If a Fire appears, then an orange Post-It should be created.
2. All the team is notified about the Fire before putting it into the TaskBoard.
3. The priority of the Fire is determined against all the rest of the Planned Tasks in the TaskBoard.
4. The Fire is put in the To-Do column, without StoryCard, representing its priority based on the vertical location (the higher, the important).
In practice:
In white the StoryCards, in yellow the Planned Tasks and in orange the Fires:
