Martín Alaimo
… de personas y sistemas.
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
Defragging My Day
12 years ago
A few days ago while I was surfing the Internet, I suddenly reach up to an article called “Defragment your Day” which caught my attention.
Reading it carefully, the base idea is to group the different activities of the day into slots of the same type rather than spreading them randomly –in a chaotic way- all through the day calendar.
It seems to be a very good idea to implement, but I still have some concerns on it, ‘cause it tends to assume the people work at least 3 hs at night after 10PM… what¡¡?? C’mon, I don’t want to spend the rest of my life working from 10pm to 1am every day (plus my normal office hours). Do you?
Ok, but let’s give it credit and assume this is a schema for a very high workload period, like a cutover, an implementation or an annual financial close, etc. which may demand an extra effort from you. So, I’ll try avoiding that 3hours period whenever I can, leaving it to emergency/critical situations. Make sense? I hope so.
Assuming that, it seems to be pretty good. You know what? I’ll try putting it in practice in my day-to-day basis and figure out how it works, which problems I face. Additionally I’ll post here my experience on this.
By the way, the original article was written by Kevin Milden for New Leaders. You can find it following this link: http://newleaders.com/discussions/369-defragment-your-day
Cheers!
(Español) Desfragmenta tu Día
32 years ago
by Martin Alaimo
in Time Management
Sorry, this entry is only available in Español.
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:
Introduction to Agile
02 years ago
by Martin Alaimo
in Introduction
So, what’s all this “agile thing”about?
This is a pretty acceptable question for which we need an answer. I’m posting this information due to the fact that we can’t assume everyone reaching up to this blog would know what agile is.
On the other hand, there’s already a lot of information out there describing what agile is and going deeper in details on their most known flavors; so, rather than writing another blog post about what Agile is, I’ll just point you to the needed materials/books that will explain it.In case your mother tonge were Spanish, I’d suggest you to visit the Spanish version of this article where you’ll find a more deeper introduction to agile.
OK, here we go, please check out the following material in order to understand what Agile is:
- The first thing to know about is the bean that made this Agile thoughts grow: The Agile Manifesto.
- After that, you’d probably need to read the principles derived from the above manifesto: The Agile Principles.
- Once the basis are known, here’s a beginner level introduction to Agile: A Brief Introduction to Agile.
- Focusing only on SCRUM at this point, I’d recommend you to take a look at Ken Schwaber’s book named Agile Project Management with SCRUM.
- Finally, you MUST read Henrik Kniberg’s e-book (free online version) named SCRUM and XP from the Trenches which is a detailed description on how the author implements SCRUM and XP in different development teams.
Hello agile world!
02 years ago
by Martin Alaimo
in Agile Projects
It’s been several years since I’ve started working with agile methodologies and practices; but it wasn’t until a few months ago that I seriously considered the topic.
Today I’m definitely convinced of the eficiency on it’s ways and objectives when it comes to “agility”. I’ve seen during this last months how the agile methodologies lead the teams that implements them into a qualitative jump.
It’s also today when I start this blog about agile methodologies, where I’m intent on recording my experiences, concerns, anecdotes and ideas raised during my trip through this way.
Since I got certified in PMP I tent to convert whatever sorrounds me into a project; and if we consider a blog to be a project on itself, then we can assume it can be incrementally developed in an agile way.
Said that, welcome to my blog!
