On the last of Agile 2009, I started with the last half of Jim Highsmith's talk: Agile Project Management—Innovation in Action. I have little to say about it but better that can nothing.
He proposed an interesting change on the view of the production "iron triangle". The traditional one having scope, resources and schedule has its constraints. He suggests that in an agile environment those constraints are, in fact, all parts of one corner alone: "Constraints". The other corners being value and quality. I don't have many notes on this talk so I can't add much more.
On the second slot, I went to Patrick Kua's Climbing the Dreyfus Ladder of Agile Practices. It was a great experience. The main idea of the workshop is to help coaches set up their expectations regarding the use of practice within their teams. Patrick started with a small presentation about the behavioral model such as Shu Ha Ri and the Dreyfus model skill of acquisition. His slides are available here.
The mechanics were pretty simple.
Choose a principle or practice you would like to map. I got into the group talking about Story Walls/Big Visible Charts.
Ask people to write down post-its with desired actions or atitudes they expect to happen for this practice.
Once they are done, have them identify on which level of your behavioral model each of the actions they wrote down should fit. Would you expect a beginner to perform that action? Or is that something more common to someone proficient? Some discussion will lead to a mapping of the actions to each level.
With this result, your coaches are now aligned regarding what they might expect from their teams and how they can identify those who managed to climb the ladder and, mostly, how to help people reach a higher level by slowly going up one step at each time.
The results of our workshop are available on Patrick's website and I strongly suggest this activity to help your teams set a common expectation and improve consistently the members of your team.
Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts
Monday, January 4, 2010
Sunday, November 22, 2009
Agile 2009 - Day 3 - 26th August - Kake Coding Dojo
On Wednesday evening, after the talks were over, I organized a Kake Coding Dojo at the open jam area. We had 3 computers (my own running OS X, Thiago Colucci's with Ubuntu Linux and Pedro Leal's one with OS X) and about 10 people participating.
We chose Kata Bowling as our problem.
We built up the nice sheet you can see above (thanks Danilo Sato for the picture) with our explanation of the problem as well as the mechanics. This way, we intend to get people to join us on the fly while the dojo was already running. And it worked! We had about 3 or 4 people that came by, joined for two rounds and then left. A few people kept around just chatting about what was going on and wondering how to things were going. Thanks Pedro Leal for the picture below.
The same problem was being solved in Ruby, Haskell and Java on each computer and it worked about fairly well in all of them. We kept 7 minutes round as usual and just had some problems with missing experts on Haskell (just two people very familiar with the language and 2 more with some experience) which drove us to ask out for help to other Agile attendees.
Finally, we ran our retrospective which the result you can check on the picture above (or this link for the higher resolution one).
Our main problems were about the noise around (downside of being in an open area) and our lack of detached keyboards (which could have jumped from hand to hand more easily). We learned (the hard way) that changing a pair in the middle of a big refactoring is really hard. It is very difficult to explain what is happening to the newcomer when the code is not working.
People also liked trying Ruby and Haskell but mostly the experience of pair programming with different people from different backgrounds. There was a small issue regarding the stress situation that the format puts participants on. 7 minutes is a short time and having the pressure to explain the code to the newcomer and adding your own contribution in that time (not being able to fail on any or else the whole code might get lost) is not an easy and comfortable situation. From this view point, the format breaks the safety aspect so important in a Coding Dojo. On the other hand it also leads to a more exciting experience and gets you to practice a different set of skills.
On the overall it was an amazing experience and I would like to thank everyone for joining us. After so much fun, we obviously went out for some dinner at an amazing burger place in Chicago.
You can checkout the generated code of the three solutions at Coding Dojo São Paulo's github account. There are also more pictures from Danilo at his Flickr account and some more from Pedro at his Picasa account.
We chose Kata Bowling as our problem.
We built up the nice sheet you can see above (thanks Danilo Sato for the picture) with our explanation of the problem as well as the mechanics. This way, we intend to get people to join us on the fly while the dojo was already running. And it worked! We had about 3 or 4 people that came by, joined for two rounds and then left. A few people kept around just chatting about what was going on and wondering how to things were going. Thanks Pedro Leal for the picture below.The same problem was being solved in Ruby, Haskell and Java on each computer and it worked about fairly well in all of them. We kept 7 minutes round as usual and just had some problems with missing experts on Haskell (just two people very familiar with the language and 2 more with some experience) which drove us to ask out for help to other Agile attendees.Finally, we ran our retrospective which the result you can check on the picture above (or this link for the higher resolution one).Our main problems were about the noise around (downside of being in an open area) and our lack of detached keyboards (which could have jumped from hand to hand more easily). We learned (the hard way) that changing a pair in the middle of a big refactoring is really hard. It is very difficult to explain what is happening to the newcomer when the code is not working.
People also liked trying Ruby and Haskell but mostly the experience of pair programming with different people from different backgrounds. There was a small issue regarding the stress situation that the format puts participants on. 7 minutes is a short time and having the pressure to explain the code to the newcomer and adding your own contribution in that time (not being able to fail on any or else the whole code might get lost) is not an easy and comfortable situation. From this view point, the format breaks the safety aspect so important in a Coding Dojo. On the other hand it also leads to a more exciting experience and gets you to practice a different set of skills.
On the overall it was an amazing experience and I would like to thank everyone for joining us. After so much fun, we obviously went out for some dinner at an amazing burger place in Chicago.
You can checkout the generated code of the three solutions at Coding Dojo São Paulo's github account. There are also more pictures from Danilo at his Flickr account and some more from Pedro at his Picasa account.
Agile 2009 - Day 3 - 26th August - Placebo
Things have gone smoothly (and busy) since last post so I am back to finish my report about Agile 2009. On Wednesday, during the morning I was assigned to Robert Biddle's talk about "Activity Theory for Manifesting Agile" which was a very good and a bit too complicated for me. Since I was working couldn't get any notes so I'll skip it just like Johanna Hunt and Rachel Davies' "Telling Your Stories: Why Stories are important for your team" workshop. The workshop was pretty fun and I managed to help a little. A brief description would say that it consisted in getting people together to invent stories they've been through and listening to other people repeating them. Interesting results but I can't detail them by lack of notes.
So for Wednesday afternoon I got a little more time. Not knowing what to attend to, I wandered around during the first slot and ended up (very luckily) at Linda Rising's "Agile: placebo or real solution?" session. Best thing that could happen to me was to get into that one. Amazing talk.
Linda started telling us about what is the placebo effect. This effect is now know to exist for a fact and its outcomes are pretty impressive: about 30% of sick people get better no matter what is the medicine that is given to them.
She explained that quite a few experiments have been done regarding this effect. Those experiment show that if you get three people with the same diagnosed disease and you give them all a pill with placebo (which has absolutely no medical effect) without them know it is placebo but really believing that those pills will heal them, one of them will, indeed get better.
One important point is that the patients have to know that they are being treated. The test has absolutely no effect if the medicine is given without the patient's knowledge (hidden in the food or water or applied during sleep). The consciousness of being taken care off is of great importance for the effect to take place.
There are many more experiments that show off that if there is anything that points to a fake, no results are shown. If the patients are not confident that the medicine will help them (if the doctor shows uncertainty, if they've heard from friends that it doesn't work, etc.), the effect also does not present itself.
From those experiments, we can conclude that since belief and awareness of treatment are essentials, it is our own body and mind that makes it so that we get better.
Having introduced us for this clinical view of the placebo effect, Linda talked about experiments that were run in order to identify why would some patients (not always to same) respond to placebo and others wouldn't. From some brain analysis, it looks like there are two groups of people. People which she called "sheeps" that are more influenced by their unconscious and people which stick much more with their conscious called "goats".
This doesn't mean that you either a sheep or a goat. People can behave like sheep on certain situations and like goat on others. It so happens that the brain activity of people being treated by the placebo effect is very similar to the activities recorded on sheep behavior.
So it is people's unconscious that is capable of healing a disease by itself.
And what is the relation of such medical results with agile software development? Well, Linda asks us whether all we've been talking about is just placebo and people were just looking for a medicine to improve their situation or is it that there is really an improvement by applying agile methods?
The answer she provides is a simple one: who cares? As long as it works, let's keep doing it! She gave this end a very scary religious connotation as she brought some people up-front and started talking like a priest with "Oh yeah brother! Amem!" and stuff like that. It was a fun joke but a bit scary if you saw people joining her (they were also having fun).
Anyway, the whole talk was a very interesting one. Sometimes just having someone with authority (a consultant) come in and use whatever claiming it will solve the problems can solve them even if is nothing special. Better think about it when you are facing a problem with a group.
So for Wednesday afternoon I got a little more time. Not knowing what to attend to, I wandered around during the first slot and ended up (very luckily) at Linda Rising's "Agile: placebo or real solution?" session. Best thing that could happen to me was to get into that one. Amazing talk.
Linda started telling us about what is the placebo effect. This effect is now know to exist for a fact and its outcomes are pretty impressive: about 30% of sick people get better no matter what is the medicine that is given to them.
She explained that quite a few experiments have been done regarding this effect. Those experiment show that if you get three people with the same diagnosed disease and you give them all a pill with placebo (which has absolutely no medical effect) without them know it is placebo but really believing that those pills will heal them, one of them will, indeed get better.
One important point is that the patients have to know that they are being treated. The test has absolutely no effect if the medicine is given without the patient's knowledge (hidden in the food or water or applied during sleep). The consciousness of being taken care off is of great importance for the effect to take place.
There are many more experiments that show off that if there is anything that points to a fake, no results are shown. If the patients are not confident that the medicine will help them (if the doctor shows uncertainty, if they've heard from friends that it doesn't work, etc.), the effect also does not present itself.
From those experiments, we can conclude that since belief and awareness of treatment are essentials, it is our own body and mind that makes it so that we get better.
Having introduced us for this clinical view of the placebo effect, Linda talked about experiments that were run in order to identify why would some patients (not always to same) respond to placebo and others wouldn't. From some brain analysis, it looks like there are two groups of people. People which she called "sheeps" that are more influenced by their unconscious and people which stick much more with their conscious called "goats".
This doesn't mean that you either a sheep or a goat. People can behave like sheep on certain situations and like goat on others. It so happens that the brain activity of people being treated by the placebo effect is very similar to the activities recorded on sheep behavior.
So it is people's unconscious that is capable of healing a disease by itself.
And what is the relation of such medical results with agile software development? Well, Linda asks us whether all we've been talking about is just placebo and people were just looking for a medicine to improve their situation or is it that there is really an improvement by applying agile methods?
The answer she provides is a simple one: who cares? As long as it works, let's keep doing it! She gave this end a very scary religious connotation as she brought some people up-front and started talking like a priest with "Oh yeah brother! Amem!" and stuff like that. It was a fun joke but a bit scary if you saw people joining her (they were also having fun).
Anyway, the whole talk was a very interesting one. Sometimes just having someone with authority (a consultant) come in and use whatever claiming it will solve the problems can solve them even if is nothing special. Better think about it when you are facing a problem with a group.
Friday, October 2, 2009
Agile 2009 - Day 2 - 25th August - Lean Lego Game
After lunch on Tuesdays I was assigned as a volunteer. On the first slot I took care of "Speed Up Your Testing With Acceptance Criteria Conversations". It wasn't really my favorite session to attend to but I needed some time to rest my mind so I took profit of being near the wifi area (believe me, there was only 1 free wifi spot in the conf) to check my emails and catch up with the world a little.
On the second slot, I joined Danilo Sato and Frank Trindade in the Lean Lego Game session they ran.
The Lean Lego Game - Danilo Sato & Francisco Trindade
The session was a workshop and, by the way it was built, it couldn't handle more than 30 people participating actively. Since I was on duty I couldn't join the teams but had the pleasure to help. The session started up talking a bit about Lean, velocity and cost but mostly explaining that lots of people in the software industry now have heard of Lean but few of them really understand the context in which Lean was born. I'll skip the talk part (slides are available at here) and go the game itself since it was the most interesting part to me and it is the one that brings back to that first Lean context.
The participants were divided in four groups of 7 to 8 people each. Each group was in a table and had another table with a few Lego pieces nearby. The idea is that those four groups simulated a house factory that could do houses of four different colors. There were 3 rounds was constituted of 4 sprints of 30 seconds each. Each round followed a slightly different production system.
The first round simulated a production line. The group closer to the talkers were the assembly workers and their responsibility was to assembly a house. The next group was the selection group responsible for collecting the right amount of each part to build a house from a pile of parts from a certain color. The next group was the one responsible for the coloring separation. Their job was to get pieces and separate them into four piles, each with one color. Finally, the farther away group was responsible for "buying" resources from the big Lego bag and providing them (no more than a certain a amount of each kind) to the other group. Each person of the group should have a task and could not do anything other than that task. At the end of each sprint, Patrick Kua (the house factory customer) selected two colors (randomly from a card deck) for the houses he wanted to buy to simulate a push system where things were done BEFORE the clients manifested a wish for them (like North American car factories used to do).
In that scenario, each group knew what do to from start and they followed the colors chosen by the client for that sprint. At the end of each sprint, the talkers collected the results of each group. They counted how many houses were delivered, how many resources were consumed on each stage and the total. This way, the first sprint didn't manage to deliver any houses. Colors were sorted by the client and in the second sprint, the team delivered two houses but one was not from the colors the customer wanted. Another two colors were sorted and one matched the extra house in stock. On the third sprint, the team delivered another two houses but one of them didn't match the requested ones. The last sprint delivered two other matched house. The customer picked another two colors and couldn't get a match so the team ended up delivering 5 houses.
The session then talked a bit about could have gone wrong. And the team felt many of them were not having work to do or were doing the wrong work because they didn't know what they should be doing.
So the second round changed the system to pull system. Meaning the teams were supposed to work exactly in the same way internally but the client would pick the card at the start of each sprint and the supplier teams would provide supplies of the colors selected by the client. Results were much more impressive this time and the team managed to deliver one house successfully on the first sprint, two houses on the second and third sprint and three houses on the last sprint. This way they ended up with 8 houses sold. However they still consumed more "money" than the houses "paid".
This brought up the problems related to keeping a stock and still having people not aware of the whole process. The presenters then introduced the idea of Yatai. So the last round followed a Yatai where each person was responsible for building one house by themselves just picking from the piles available near their tables. Instead of having fours sprints of 30 seconds, the team was given one big sprint of 120 seconds. It ended up that the team managed to deliver 16 houses and the stock was severely reduced.
Although I couldn't be part of a team, I really had a lot of fun. People were running around, trying desperately to do their best and getting frustrated over the systems they were forced in. I think Danilo and Frank really managed to bring up one of the key issues brought up by Lean ideas and had a great timing to swap between presentation and activities.
I loved the workshop so much that I will be presenting an instance of it at Encontro Ágil 2009 on the 10th of October (next week) in São Paulo. If you want to learn a bit more about Lean and personally feel the industry issues that modeled Lean, join us and help us improve this workshop even more.
On the second slot, I joined Danilo Sato and Frank Trindade in the Lean Lego Game session they ran.
The Lean Lego Game - Danilo Sato & Francisco Trindade
The session was a workshop and, by the way it was built, it couldn't handle more than 30 people participating actively. Since I was on duty I couldn't join the teams but had the pleasure to help. The session started up talking a bit about Lean, velocity and cost but mostly explaining that lots of people in the software industry now have heard of Lean but few of them really understand the context in which Lean was born. I'll skip the talk part (slides are available at here) and go the game itself since it was the most interesting part to me and it is the one that brings back to that first Lean context.
The participants were divided in four groups of 7 to 8 people each. Each group was in a table and had another table with a few Lego pieces nearby. The idea is that those four groups simulated a house factory that could do houses of four different colors. There were 3 rounds was constituted of 4 sprints of 30 seconds each. Each round followed a slightly different production system.
The first round simulated a production line. The group closer to the talkers were the assembly workers and their responsibility was to assembly a house. The next group was the selection group responsible for collecting the right amount of each part to build a house from a pile of parts from a certain color. The next group was the one responsible for the coloring separation. Their job was to get pieces and separate them into four piles, each with one color. Finally, the farther away group was responsible for "buying" resources from the big Lego bag and providing them (no more than a certain a amount of each kind) to the other group. Each person of the group should have a task and could not do anything other than that task. At the end of each sprint, Patrick Kua (the house factory customer) selected two colors (randomly from a card deck) for the houses he wanted to buy to simulate a push system where things were done BEFORE the clients manifested a wish for them (like North American car factories used to do).
In that scenario, each group knew what do to from start and they followed the colors chosen by the client for that sprint. At the end of each sprint, the talkers collected the results of each group. They counted how many houses were delivered, how many resources were consumed on each stage and the total. This way, the first sprint didn't manage to deliver any houses. Colors were sorted by the client and in the second sprint, the team delivered two houses but one was not from the colors the customer wanted. Another two colors were sorted and one matched the extra house in stock. On the third sprint, the team delivered another two houses but one of them didn't match the requested ones. The last sprint delivered two other matched house. The customer picked another two colors and couldn't get a match so the team ended up delivering 5 houses.
The session then talked a bit about could have gone wrong. And the team felt many of them were not having work to do or were doing the wrong work because they didn't know what they should be doing.
So the second round changed the system to pull system. Meaning the teams were supposed to work exactly in the same way internally but the client would pick the card at the start of each sprint and the supplier teams would provide supplies of the colors selected by the client. Results were much more impressive this time and the team managed to deliver one house successfully on the first sprint, two houses on the second and third sprint and three houses on the last sprint. This way they ended up with 8 houses sold. However they still consumed more "money" than the houses "paid".
This brought up the problems related to keeping a stock and still having people not aware of the whole process. The presenters then introduced the idea of Yatai. So the last round followed a Yatai where each person was responsible for building one house by themselves just picking from the piles available near their tables. Instead of having fours sprints of 30 seconds, the team was given one big sprint of 120 seconds. It ended up that the team managed to deliver 16 houses and the stock was severely reduced.
Although I couldn't be part of a team, I really had a lot of fun. People were running around, trying desperately to do their best and getting frustrated over the systems they were forced in. I think Danilo and Frank really managed to bring up one of the key issues brought up by Lean ideas and had a great timing to swap between presentation and activities.
I loved the workshop so much that I will be presenting an instance of it at Encontro Ágil 2009 on the 10th of October (next week) in São Paulo. If you want to learn a bit more about Lean and personally feel the industry issues that modeled Lean, join us and help us improve this workshop even more.
Wednesday, September 23, 2009
Agile 2009 - Day 2 - 25th August - Top 10 tips to Agile Coaches
After Alistair's Keynote, I went to Rachel Davies & Liz Sedley's "Top ten tips to Agile Coaches".
Top ten tips to Agile Coaches - Rachel Davies & Liz Sedley
The session was mainly based on a summary from what Rachel and Liz learned through their experience and while writing their book. I will just write down the tips with my small notes and let you think about them.
10. Get Introduced
Who are you? What do you do? What is your goal?
Explain your point of view to the team you will (or are) coaching and let them understand you are not there to be their boss.
9. Agile is NOT a religion
Spend time and effort to listen and understand the team and their environment. It might very well happen that agility does not fit their situation. Be sensitive to their context.
8. Show respect
Always trust (deeply in your heart, not just for show) that people did their best since the beginning and try to understand why they got in the situation they are in.
Discover the differences between people and use NAMES ("the BA said that the DB guy couldn't do it" versus "Jenny told me that Josh was having troubles to implement it").
Ask what they think about the issues and was suggestions they have and LISTEN to their answer. Pay attention and try to understand. Work with them over those suggestions.
7. Step back to see the big picture
Don't try to fix people. Try to fix the pressures and obligations those people suffer from so that they can do their job decently.
6. Ask questions to spark ideas
Questions make people explain ideas and understand them. It also makes them create arguments and counter-arguments for their ideas. If you can make their ideas work, it will help the team adopt the movement and carry on.
But be careful: ask questions to other people's ideas, not your own. Do not try to force your ideas through those questions.
5. Take time out to reflect
Don't let pressure force your answers. Your calm attitude will relax the team and make them feel more confident. Ask help to other agile coaches/people if you can't think of a good behavior. You don't have to know it all.
4. Introduce the Elephant
Show off the problem that everyone know exists but is silent about it. But don't put it as a pressure. Give the team a chance to suggest solutions, ideas, root causes, etc.
3. Make changes as an experiment
Go slowly. Try some idea and be ready to remove it if it doesn't work. Don't stick to something that won't work just because you think the team should make it work. Try something else and try it again later, in another context. Give the team chances to suggest those changes and experiment with their ideas.
2. Go with the energy of the team
Solve the problem the team wants to solve. Eventually they will address the problems you consider important.
1. Have courage in your convictions
Don't doubt your capacities, the problem is not easy and you can't let people see you doubt yourself. It will discourage them and make them lose confidence in you. Believe you can make a difference or you really won't.
After the talk, they asked for each table of participants to add their own tips. A few of them were really good but, unfortunately, I couldn't write them down. Those are obviously good ideas and NOT religions either. Any problem can have its context in which any of those tips can fail. But in general, thinking about them can only help you. Do you have any tip you feel should enter that list? Please post it as a comment. I've attached their slides although they don't add so much.
Top ten tips to Agile Coaches - Rachel Davies & Liz Sedley
The session was mainly based on a summary from what Rachel and Liz learned through their experience and while writing their book. I will just write down the tips with my small notes and let you think about them.
10. Get Introduced
Who are you? What do you do? What is your goal?
Explain your point of view to the team you will (or are) coaching and let them understand you are not there to be their boss.
9. Agile is NOT a religion
Spend time and effort to listen and understand the team and their environment. It might very well happen that agility does not fit their situation. Be sensitive to their context.
8. Show respect
Always trust (deeply in your heart, not just for show) that people did their best since the beginning and try to understand why they got in the situation they are in.
Discover the differences between people and use NAMES ("the BA said that the DB guy couldn't do it" versus "Jenny told me that Josh was having troubles to implement it").
Ask what they think about the issues and was suggestions they have and LISTEN to their answer. Pay attention and try to understand. Work with them over those suggestions.
7. Step back to see the big picture
Don't try to fix people. Try to fix the pressures and obligations those people suffer from so that they can do their job decently.
6. Ask questions to spark ideas
Questions make people explain ideas and understand them. It also makes them create arguments and counter-arguments for their ideas. If you can make their ideas work, it will help the team adopt the movement and carry on.
But be careful: ask questions to other people's ideas, not your own. Do not try to force your ideas through those questions.
5. Take time out to reflect
Don't let pressure force your answers. Your calm attitude will relax the team and make them feel more confident. Ask help to other agile coaches/people if you can't think of a good behavior. You don't have to know it all.
4. Introduce the Elephant
Show off the problem that everyone know exists but is silent about it. But don't put it as a pressure. Give the team a chance to suggest solutions, ideas, root causes, etc.
3. Make changes as an experiment
Go slowly. Try some idea and be ready to remove it if it doesn't work. Don't stick to something that won't work just because you think the team should make it work. Try something else and try it again later, in another context. Give the team chances to suggest those changes and experiment with their ideas.
2. Go with the energy of the team
Solve the problem the team wants to solve. Eventually they will address the problems you consider important.
1. Have courage in your convictions
Don't doubt your capacities, the problem is not easy and you can't let people see you doubt yourself. It will discourage them and make them lose confidence in you. Believe you can make a difference or you really won't.
After the talk, they asked for each table of participants to add their own tips. A few of them were really good but, unfortunately, I couldn't write them down. Those are obviously good ideas and NOT religions either. Any problem can have its context in which any of those tips can fail. But in general, thinking about them can only help you. Do you have any tip you feel should enter that list? Please post it as a comment. I've attached their slides although they don't add so much.
Saturday, September 12, 2009
Agile 2009 - Day 2 - 25th August - Alistair's Keynote
Tuesday at Agile 2009 started well. The conference provided a very good breakfast with chocolate croissant (I love those), coffee, tea, fruits, juices and different kinds of breads.
From there, everyone went to the Grand Ballroom to watch Alistair Cockburn's Keynote. I won't need to write a full description of Alistair's talk because InfoQ just published the full video of it. So it will be a bit closer to my impressions.
First thing I need to mention is that once Ahmed Sidky (Agile 2009 Program Chair) introduced Alistair, we had an amazing performance of Wind's Song Flutes playing the one Scottish music used in all movies and Alistair was following silently behind. Very impressive entrance. Alistair then explained why wind's song flutes players always walk when playing: "They are running away from the sound".
Past the fun, came the sadness. Alistair started his talk reciting an adapted version of the funeral oration from Shakespeare's Julius Cesar to Agile Software Development. A very impressive performance. It was the introduction to say not that Agile was dead but that it was melted. He compared Agile to an iceberg in the ocean (software development) and said that before, Agile was something that people noticed because it was outstanding from the rest. Nowadays, the iceberg has melted. It is not gone. But it is now part of the ocean. It is now something that is accepted by most people.
He then moved on to his viewing of software development you might know if you read any of his Crystal books or articles or if you attended any session with him.
He defines Developing Software as
People
Making Ideas Concrete
in an Economic Context
He then showed this image that I particularly like:
He explains that Software Development can be considered a finite, goal-directed and cooperative game while building IT Systems is open-ended. This means that when you are developing software you should work in a team to reach a goal and you are done when you make the software achieve that goal. On the other hand, when you think about the whole system, you want to work cooperatively in an open ended game. Meaning you are always in a dilemma between delivering the software and setting up for the next software (or game).
He says also that this game is consisted of 3 possible moves: Invent, Decide, Communicate. With those moves you have to deliver the software and be slightly prepared for the next game.
He then went on to more traditional arguments he uses for Crystal. Team size and criticality of the project are key to decide what practices you should apply. He also mentioned the quality of communication between people and the fact that most means are much more effective than paper to communicate so people should really think about different forms of documentation.
He also talked a little about the Craft focus that is being given to software development lately. He pointed that thinking of any activity as a craft helps you identify the skills required to perform it and the medium available to achieve the goal. Moved a little to the User Experience entrance in the process of software development and how things changed or should change to be more effective in overall.
It was a very good talk. A bit repetitive for those that already attended any session with Alistair but still very a great talk. I definitively recommend you see the whole video from InfoQ and feel free to post comments to start a discussion on any of those subjects.
Next post will present Rachel Davies and Liz Sedley's "Top ten tips to Agile Coaches".
From there, everyone went to the Grand Ballroom to watch Alistair Cockburn's Keynote. I won't need to write a full description of Alistair's talk because InfoQ just published the full video of it. So it will be a bit closer to my impressions.
First thing I need to mention is that once Ahmed Sidky (Agile 2009 Program Chair) introduced Alistair, we had an amazing performance of Wind's Song Flutes playing the one Scottish music used in all movies and Alistair was following silently behind. Very impressive entrance. Alistair then explained why wind's song flutes players always walk when playing: "They are running away from the sound".
Past the fun, came the sadness. Alistair started his talk reciting an adapted version of the funeral oration from Shakespeare's Julius Cesar to Agile Software Development. A very impressive performance. It was the introduction to say not that Agile was dead but that it was melted. He compared Agile to an iceberg in the ocean (software development) and said that before, Agile was something that people noticed because it was outstanding from the rest. Nowadays, the iceberg has melted. It is not gone. But it is now part of the ocean. It is now something that is accepted by most people.
He then moved on to his viewing of software development you might know if you read any of his Crystal books or articles or if you attended any session with him.
He defines Developing Software as
People
Making Ideas Concrete
in an Economic Context
He then showed this image that I particularly like:
He explains that Software Development can be considered a finite, goal-directed and cooperative game while building IT Systems is open-ended. This means that when you are developing software you should work in a team to reach a goal and you are done when you make the software achieve that goal. On the other hand, when you think about the whole system, you want to work cooperatively in an open ended game. Meaning you are always in a dilemma between delivering the software and setting up for the next software (or game).He says also that this game is consisted of 3 possible moves: Invent, Decide, Communicate. With those moves you have to deliver the software and be slightly prepared for the next game.
He then went on to more traditional arguments he uses for Crystal. Team size and criticality of the project are key to decide what practices you should apply. He also mentioned the quality of communication between people and the fact that most means are much more effective than paper to communicate so people should really think about different forms of documentation.
He also talked a little about the Craft focus that is being given to software development lately. He pointed that thinking of any activity as a craft helps you identify the skills required to perform it and the medium available to achieve the goal. Moved a little to the User Experience entrance in the process of software development and how things changed or should change to be more effective in overall.
It was a very good talk. A bit repetitive for those that already attended any session with Alistair but still very a great talk. I definitively recommend you see the whole video from InfoQ and feel free to post comments to start a discussion on any of those subjects.
Next post will present Rachel Davies and Liz Sedley's "Top ten tips to Agile Coaches".
Thursday, September 10, 2009
Agile 2009 - Day 1 - 24th August - Software Quality
On the second slot of monday afternoon, I attended Jim Highsmith's "Zen and the Art of Software Quality". I missed the first 10 minutes but I don't think it was a big deal.
Zen and the Art of Software Quality - Jim Highsmith
When I arrived, Jim was talking about why we should not use the Standish Group Measures to evaluate software development success. The main reason he points is that the outcomes measured are outdated. They focus on projects that are on plan, on schedule and on features.
Meaning that a project that is delayed of a year but has a satisfied customer is a failed project.
A project that achieves an unexpected goal is a failure.
A project that delivers less feature in less time and stops is a failure.
Those are wrong concepts. Canceling a project soon enough is NOT a failure. It is a great success from an agile perspective. It means the client didn't waste his money for several months (or years) until he discovered he couldn't afford (or do) what he wanted to.
One of Jim's sentence that I liked is:
"Target high and miss
might be better than
target low and hit!"
What good is it to estimate every story as an epic story and manage to do it in 6 iterations while you could break the story in smaller ones and deliver 80% of the value in 1 iteration?
His suggestion from this scenario is that we shouldn't think about the old Cost-Scope-Schedule triangle as our variables in software development. That waterfall iron triangle should be replaced by an Agile Iron Triangle constituted of Value-Quality-Constraint where Constraint would be Cost-Scope-Schedule.
His idea is that those are constraints to software development. Variables related that fit in a greater picture. Our questioning should now be something like "how much value can we deliver given a certain level of quality and our constraints".
Jim explained then that there are "two kinds of Quality". An iextrinsic quality that is related to the quality imbued from value a given software has for a customer and an intrinsic quality. The intrinsic quality is closer to what we consider quality nowadays. It is the way the software is done. It is its bugless property, its simplicity, etc.
Separating those qualities help us understand something we already know. It is useless to produce the perfect software that solves nobody's problem.
Jim then defends what I understand as "fail fast". He argued that there is some point where cost outcomes value and that, at this point, the software development should be stopped. If we can pinpoint this moment, it is the best way to be have a good performance. If a feature is not worth being paid for, it should not be implemented. If no feature is worth being paid for then the development should stop. And it is NO failure if that happens in the middle of the original schedule. Quite the opposite!
Jim finished his talk mentioning the Parking Lot Diagram I reproduced below. The diagram very well known in FDD communities focuses on feature releasables. Meaning that, in opposition to the Gantt shart that focuses on tasks, the Parking Lot shows the features that can be released.
That was it. I've uploaded Jim's hand outs for more details.
What I learned:
Revisiting some ideas that were pretty obvious can help refocus on what really matters. It is good to listen to the same ideas without having a brand (XP, Scrum, FDD, etc.).
Please leave your comments and ideas regarding this talk.
Next post will be about Alistair Cockburn's keynote.
Zen and the Art of Software Quality - Jim Highsmith
When I arrived, Jim was talking about why we should not use the Standish Group Measures to evaluate software development success. The main reason he points is that the outcomes measured are outdated. They focus on projects that are on plan, on schedule and on features.
Meaning that a project that is delayed of a year but has a satisfied customer is a failed project.
A project that achieves an unexpected goal is a failure.
A project that delivers less feature in less time and stops is a failure.
Those are wrong concepts. Canceling a project soon enough is NOT a failure. It is a great success from an agile perspective. It means the client didn't waste his money for several months (or years) until he discovered he couldn't afford (or do) what he wanted to.
One of Jim's sentence that I liked is:
"Target high and miss
might be better than
target low and hit!"
What good is it to estimate every story as an epic story and manage to do it in 6 iterations while you could break the story in smaller ones and deliver 80% of the value in 1 iteration?
His suggestion from this scenario is that we shouldn't think about the old Cost-Scope-Schedule triangle as our variables in software development. That waterfall iron triangle should be replaced by an Agile Iron Triangle constituted of Value-Quality-Constraint where Constraint would be Cost-Scope-Schedule.
His idea is that those are constraints to software development. Variables related that fit in a greater picture. Our questioning should now be something like "how much value can we deliver given a certain level of quality and our constraints".
Jim explained then that there are "two kinds of Quality". An iextrinsic quality that is related to the quality imbued from value a given software has for a customer and an intrinsic quality. The intrinsic quality is closer to what we consider quality nowadays. It is the way the software is done. It is its bugless property, its simplicity, etc.
Separating those qualities help us understand something we already know. It is useless to produce the perfect software that solves nobody's problem.
Jim then defends what I understand as "fail fast". He argued that there is some point where cost outcomes value and that, at this point, the software development should be stopped. If we can pinpoint this moment, it is the best way to be have a good performance. If a feature is not worth being paid for, it should not be implemented. If no feature is worth being paid for then the development should stop. And it is NO failure if that happens in the middle of the original schedule. Quite the opposite!
Jim finished his talk mentioning the Parking Lot Diagram I reproduced below. The diagram very well known in FDD communities focuses on feature releasables. Meaning that, in opposition to the Gantt shart that focuses on tasks, the Parking Lot shows the features that can be released.
That was it. I've uploaded Jim's hand outs for more details.What I learned:
Revisiting some ideas that were pretty obvious can help refocus on what really matters. It is good to listen to the same ideas without having a brand (XP, Scrum, FDD, etc.).
Please leave your comments and ideas regarding this talk.
Next post will be about Alistair Cockburn's keynote.
Agile 2009 - Day 1 - 24th August - Agile Coaches
During Monday morning, I was working as a volunteer at Registration. This wasn't as fun as bag stuffing for sure. No big innovations there. Just talking to people, handing bags and shirts. The only ironical part was to received about 6 new items we had to stuff into the bags DURING the morning.
For the afternoon, I attended two talks. The one I will be writing about in this post and Jim Highsmith's one about software quality that will be the focus of my next post.
"What Do Agile Coaches Do?" by Liz Sedley and Rachel Davies
Liz and Rachel started explaining that the session was based on the work they had done to their new book "Agile Coaching". They also pointed out the session was a workshop and that it was aimed to Carlos - internal coach (see the conference personas webpage to a better understanding).
Their first point was that coaching a software development team was not exactly like coaching a soccer team although the name is the same. It led them towards J. Richard Hackman's work. According to Liz and Rachel, Hackman's book named "Leading Teams - Setting the stage for great performances" out stands from other leadership books because it focuses in teams rather than individuals.
From this, they pointed out a couple things that are NOT coaching namely doing someone else's job and directing the team. In opposite, they explained that a coach should provide feedback, explain dynamics, provide suggestions and become useless (they called it: being transitional).
They explained Hackman divides possible coaching interventions in three groups:
On an Educational intervention, the coach would run an activity that could allow the team to a better understanding of what is happening and why. Retrospectives usually fit very well in Educational interventions because they make the team think about their situation and look for improvements therefore increasing their learning.
A Consultative intervention is one that the coach will apply to adjust the situation to a better one. This is the easiest intervention to make since it only requires that the coach have a suggestion of improvement and use its experience to solve the issue. The problem with it is that it does not helps the team become independent since the knowledge about why applying that solution stays with the coach. On the other hand, this is a very good solution when dealing with a team of novice people (or Shu people - see the Dreyfus learning model or the Shu-Ha-Ri model - I will post about both since there were talks about both) because it will show them one technique.
This introduction led us to the workshop itself. The room was split into groups of 3 or 4 people and Rachel and Liz handed over several Scenarios of problems in a team for each group so that the group would suggestion some coaching interventions to each scenario. The activity itself was quite interesting but, as most attendees in the session, I felt just having the division of interventions in 3 kinds was worth the session.
Most of the groups reached a fourth division that could be called "Introspection" that consists in any activity that might help understand the problem. Introspection interventions usually lead to Educational interventions from the own team opposed to Educational interventions from the coach (which might have run the Introspection intervention unknowing what the appropriate intervention was). One can argue that Introspection interventions are always performed before any other and therefore can be considered part of each intervention but the point here is that an introspection intervention may result in different sorts of intervention even if the problem is the same.
More information can be found in Liz and Rachel's slides.
I learned that classifying your actions according to Hackman's suggestion is very useful to self-analysis and to moderate the kind of actions you take. It can also help sharing experience between coaches and can probably be used in some behavioral studies related to cultural differences.
The next post will regard Jim Highsmith's "Zen and the Art of Software Quality" presentation. Please leave your comments here and there.
For the afternoon, I attended two talks. The one I will be writing about in this post and Jim Highsmith's one about software quality that will be the focus of my next post.
"What Do Agile Coaches Do?" by Liz Sedley and Rachel Davies
Liz and Rachel started explaining that the session was based on the work they had done to their new book "Agile Coaching". They also pointed out the session was a workshop and that it was aimed to Carlos - internal coach (see the conference personas webpage to a better understanding).
Their first point was that coaching a software development team was not exactly like coaching a soccer team although the name is the same. It led them towards J. Richard Hackman's work. According to Liz and Rachel, Hackman's book named "Leading Teams - Setting the stage for great performances" out stands from other leadership books because it focuses in teams rather than individuals.
From this, they pointed out a couple things that are NOT coaching namely doing someone else's job and directing the team. In opposite, they explained that a coach should provide feedback, explain dynamics, provide suggestions and become useless (they called it: being transitional).
They explained Hackman divides possible coaching interventions in three groups:
- Motivational intervention: one that tries to increase the effort of the team
- Consultative intervention: one that attempts to improve the quality of the process
- Educational intervention: one that aims to improve learning
On an Educational intervention, the coach would run an activity that could allow the team to a better understanding of what is happening and why. Retrospectives usually fit very well in Educational interventions because they make the team think about their situation and look for improvements therefore increasing their learning.
A Consultative intervention is one that the coach will apply to adjust the situation to a better one. This is the easiest intervention to make since it only requires that the coach have a suggestion of improvement and use its experience to solve the issue. The problem with it is that it does not helps the team become independent since the knowledge about why applying that solution stays with the coach. On the other hand, this is a very good solution when dealing with a team of novice people (or Shu people - see the Dreyfus learning model or the Shu-Ha-Ri model - I will post about both since there were talks about both) because it will show them one technique.
This introduction led us to the workshop itself. The room was split into groups of 3 or 4 people and Rachel and Liz handed over several Scenarios of problems in a team for each group so that the group would suggestion some coaching interventions to each scenario. The activity itself was quite interesting but, as most attendees in the session, I felt just having the division of interventions in 3 kinds was worth the session.
Most of the groups reached a fourth division that could be called "Introspection" that consists in any activity that might help understand the problem. Introspection interventions usually lead to Educational interventions from the own team opposed to Educational interventions from the coach (which might have run the Introspection intervention unknowing what the appropriate intervention was). One can argue that Introspection interventions are always performed before any other and therefore can be considered part of each intervention but the point here is that an introspection intervention may result in different sorts of intervention even if the problem is the same.
More information can be found in Liz and Rachel's slides.
I learned that classifying your actions according to Hackman's suggestion is very useful to self-analysis and to moderate the kind of actions you take. It can also help sharing experience between coaches and can probably be used in some behavioral studies related to cultural differences.
The next post will regard Jim Highsmith's "Zen and the Art of Software Quality" presentation. Please leave your comments here and there.
Thursday, September 3, 2009
Agile 2009 - Day 0 - 23th August - Bag Stuffing
As a volunteer at Agile 2009, you get to attend the conference without having to pay the conference fee (which is NOT cheap) in exchange for some (~20h) of your working time. Most of this time is spend by helping out during sessions or just in crowd control during the big events.
However, there is also some back stage work to be done BEFORE the conference really starts. That is Bag Stuffing.
Bag Stuffing is an activity that consists in generating enough conference bags with all sponsor materials within each bag. This year the volunteers received a lot of help from various people and we had the honor of having some Kanban people to help us improve our process as we went on.
Our first job was to gather boxes together and discover what should go into each bag. It wasn't the easiest job on Earth since nobody knew the content of the boxes nor if we were missing something or not. It ended up that we had 3 teams. One building up a sample bag with every item they got and counting and checking that every sponsor had their items listed. One building up a redundant bag that would verify that the first team got everything and that we could point each items' boxes. A last team that placed the boxes in a line with a sample item on the top of them so that we could easily identify the piles.
This job got done pretty quickly and very soon we had a list of available items and discovered some items were missing and got the news of a few new items arriving. Having included those new items and accounted for the missing ones, the group got split into two groups that would assemble the bags.
The process started with 7 people on each group following different ideas:
As expected, the team 1 was faster on the first iterations but soon team 2 managed to be more productive. Both team identified a problem with the table's height. However, for security reasons, none was allowed to make the tables higher which resulted in some fatigue to everyone. After the first hour, we had discovered the bottleneck for both teams and, surprise, it wasn't within the teams bounds. The greatest issue was to get the cars full of bags to the upper level and unload them into the registration area. So some people got assigned to that task and some adjustments were made.
Team 1 could easily fit the reduction of people by just assigning more items to each person down the line (we already had extra persons in the line). It even managed to have a person (me) dedicated to refilling supplies (lots of times for both teams).
Team 2 suffered the loss a bit more since each person less in the team meant a reasonable amount of bags that could flow. But they came out with an improvement to reduce their path. Instead of laying out the tables in a line, they moved them to be a U shape. This way, their path got considerably shorter.
It turned out that this was became a problem because the bottleneck would still be getting the bags upstairs but, this time, because the elevators were not as responsive as possible. So Team 1 adapted to this. People would take a small break every time a car got filled up and so they could rest from fatigue.
Team 2 also enjoyed it because they were moving around so much (having to go back all the table to restart filling a bag) that they were getting pretty tired.
By the end of the morning, both teams had completed around 800 bags and most people left for lunch. I wasn't at the afternoon's work but heard some good improvements from them. The team that picked up line 1 mainly followed what was already being done since it was reasonably simple and effective.
On the other hand, team 2 identified some very nice improvements. They laid out the tables in the shape of a star (like to image on the right). This way, they managed to dramatically reduce the length of their path to fill a bag, have a quick an big stock of materials and improve their speed. It is also fair to say that it was only possible because they had only 4 people working (they were missing some volunteers).
In any way, the results were amazing. About 1400 bags were filled and unloaded from 8am to 3pm by some 20 people in the morning shift and about 12 in the noon shift. Great work from everyone and good lessons from applying Kanban techniques.
However, there is also some back stage work to be done BEFORE the conference really starts. That is Bag Stuffing.
Bag Stuffing is an activity that consists in generating enough conference bags with all sponsor materials within each bag. This year the volunteers received a lot of help from various people and we had the honor of having some Kanban people to help us improve our process as we went on.
Our first job was to gather boxes together and discover what should go into each bag. It wasn't the easiest job on Earth since nobody knew the content of the boxes nor if we were missing something or not. It ended up that we had 3 teams. One building up a sample bag with every item they got and counting and checking that every sponsor had their items listed. One building up a redundant bag that would verify that the first team got everything and that we could point each items' boxes. A last team that placed the boxes in a line with a sample item on the top of them so that we could easily identify the piles.
This job got done pretty quickly and very soon we had a list of available items and discovered some items were missing and got the news of a few new items arriving. Having included those new items and accounted for the missing ones, the group got split into two groups that would assemble the bags.
The process started with 7 people on each group following different ideas:
- A production line where the bags would flow from one side to the other being moved by the people assigned to stuff in certain items.
- A pick-up line where the people would flow from one side of table to the other filling a complete bag each item at a time.
As expected, the team 1 was faster on the first iterations but soon team 2 managed to be more productive. Both team identified a problem with the table's height. However, for security reasons, none was allowed to make the tables higher which resulted in some fatigue to everyone. After the first hour, we had discovered the bottleneck for both teams and, surprise, it wasn't within the teams bounds. The greatest issue was to get the cars full of bags to the upper level and unload them into the registration area. So some people got assigned to that task and some adjustments were made.
Team 1 could easily fit the reduction of people by just assigning more items to each person down the line (we already had extra persons in the line). It even managed to have a person (me) dedicated to refilling supplies (lots of times for both teams).
Team 2 suffered the loss a bit more since each person less in the team meant a reasonable amount of bags that could flow. But they came out with an improvement to reduce their path. Instead of laying out the tables in a line, they moved them to be a U shape. This way, their path got considerably shorter.
It turned out that this was became a problem because the bottleneck would still be getting the bags upstairs but, this time, because the elevators were not as responsive as possible. So Team 1 adapted to this. People would take a small break every time a car got filled up and so they could rest from fatigue.
Team 2 also enjoyed it because they were moving around so much (having to go back all the table to restart filling a bag) that they were getting pretty tired.
By the end of the morning, both teams had completed around 800 bags and most people left for lunch. I wasn't at the afternoon's work but heard some good improvements from them. The team that picked up line 1 mainly followed what was already being done since it was reasonably simple and effective.
On the other hand, team 2 identified some very nice improvements. They laid out the tables in the shape of a star (like to image on the right). This way, they managed to dramatically reduce the length of their path to fill a bag, have a quick an big stock of materials and improve their speed. It is also fair to say that it was only possible because they had only 4 people working (they were missing some volunteers).In any way, the results were amazing. About 1400 bags were filled and unloaded from 8am to 3pm by some 20 people in the morning shift and about 12 in the noon shift. Great work from everyone and good lessons from applying Kanban techniques.
Monday, October 27, 2008
Crystal Monday morning at OOPSLA 2008
Hello,
As always with OOPSLA, once it starts it is very hard to keep anything updated since we get so busy. Monday was an interesting day.
I had to pleasure to attend to Alistair Cockburn's tutorial called Crystal Clear Methodology. As I expected it was very interesting. Alistair's work is well known and I am surely not the best person to talk about it but I will try anyway. Although I already heard about the Shu-Ha-Ri levels of knowledge (that are not that far from Apprentice-Novice-Expert-Master from the Dreyfus model), it is always better the have them explained from someone that know them very well.
The idea is that the Shu level of knowledge is the one where you want to learn the basis. It basically means you want a recipe that can help you get the thing done without having to give it much thoughts. This is how you learn most of the things in life: reading, writing, riding a bike, cooking, programming and those sort of things.
Once you are comfortable at reproducing those steps, you want to have a better understanding about why the best practioners in the fields do it differently from time to time. You then pass to the Ha level. In this level, you get to collect all sorts of techniques in the field you are learning. This is when you learn the exceptions, the cases, the workarounds and stuff like that. If you take the learning to ride a bike example, this is when you can take those auxiliary wheels off and do those nice curves all by yourself. You might also learn how to straight your bike and have it running on just one wheel.
When you get to master those several techniques, you get to understand how or when to use one technique or another. At this level, you are reaching the Ri. From then on, you can pick techniques according to the context. Your answers to any question become "It depends..." and very slight changes in the environment can make you change radically the way you do things. At this level, you might even inovate with new solutions that you never really thought about, they just feel right.
If you are familiar with the Dreyfus model of knowledge, you can see very clearly that those are very closely related ideas. It is interesting to perceive how the transitions in this model are more fluid or, let's say, more oriental opposing to the transitions in the Dreyfus model being more occidental. More on those differences to come on the next posts.
The rest of Alistair's tutorial showed how XP (first edition) and Scrum are excelent Shu descriptions of Agile methods although the author are clearly at the Ri level themselves. XP (second edition) and the Crystal family, on the other hand, are, according to Alistair, better suited at the Ha level since they present a set of possible solutions according to a given environment. I personally don't think the Ri level can be learned with a book which makes me believe that we can't go much further than Crystal in the matter of describing Agile methods if Alistair is right.
There was much more content on Alistair's talk but you can learn most of it from his books.
That was it for Monday morning. More posts comming with the rest.
See you all!
As always with OOPSLA, once it starts it is very hard to keep anything updated since we get so busy. Monday was an interesting day.
I had to pleasure to attend to Alistair Cockburn's tutorial called Crystal Clear Methodology. As I expected it was very interesting. Alistair's work is well known and I am surely not the best person to talk about it but I will try anyway. Although I already heard about the Shu-Ha-Ri levels of knowledge (that are not that far from Apprentice-Novice-Expert-Master from the Dreyfus model), it is always better the have them explained from someone that know them very well.
The idea is that the Shu level of knowledge is the one where you want to learn the basis. It basically means you want a recipe that can help you get the thing done without having to give it much thoughts. This is how you learn most of the things in life: reading, writing, riding a bike, cooking, programming and those sort of things.
Once you are comfortable at reproducing those steps, you want to have a better understanding about why the best practioners in the fields do it differently from time to time. You then pass to the Ha level. In this level, you get to collect all sorts of techniques in the field you are learning. This is when you learn the exceptions, the cases, the workarounds and stuff like that. If you take the learning to ride a bike example, this is when you can take those auxiliary wheels off and do those nice curves all by yourself. You might also learn how to straight your bike and have it running on just one wheel.
When you get to master those several techniques, you get to understand how or when to use one technique or another. At this level, you are reaching the Ri. From then on, you can pick techniques according to the context. Your answers to any question become "It depends..." and very slight changes in the environment can make you change radically the way you do things. At this level, you might even inovate with new solutions that you never really thought about, they just feel right.
If you are familiar with the Dreyfus model of knowledge, you can see very clearly that those are very closely related ideas. It is interesting to perceive how the transitions in this model are more fluid or, let's say, more oriental opposing to the transitions in the Dreyfus model being more occidental. More on those differences to come on the next posts.
The rest of Alistair's tutorial showed how XP (first edition) and Scrum are excelent Shu descriptions of Agile methods although the author are clearly at the Ri level themselves. XP (second edition) and the Crystal family, on the other hand, are, according to Alistair, better suited at the Ha level since they present a set of possible solutions according to a given environment. I personally don't think the Ri level can be learned with a book which makes me believe that we can't go much further than Crystal in the matter of describing Agile methods if Alistair is right.
There was much more content on Alistair's talk but you can learn most of it from his books.
That was it for Monday morning. More posts comming with the rest.
See you all!
Tuesday, October 14, 2008
Coding Rumors++ or UberDojo
Hello,
I previously described the Coding Rumor game and later on presented the results we had at PyCon Brasil 2008 doing it. During the Encontro Agil, we tried having a session of what rbp (or R) called UberDojo to follow the UltraDojo idea (the name he prefered for Coding Rumor).
Just to remind you, UltraDojo (or Coding Rumor) is a Coding Dojo session where you don't need a projector. The code is written in one laptop and the pair switches with rounds just like the regular one. Everyone works on the same problem but you only get to see the code for 2 rounds (14 minutes) in which you are the co-pilot and then the pilot. If you are not on any of those roles, you can chill and chat with other people. The advantage of this is that it requires less time focusing on the problem which makes it a good practice for conferences.
The UberDojo version is just the UltraDojo game with several laptops. You should plan to have at least three people for each laptop but you can have more if you want. In this case, when the pilot leaves, he goes to the "audience" and will choose another laptop to go to on the next round.
Last Monday's session happened at Thiago's house. We were 14 people (Danilo Sato, George Malamidis, Rodrigo Bernardo Pimentel, Thiago Colucci, Fabricio Sousa Nascimento, Jacqueline Marchetti, Renato Willi, Bruno Pedroso, João Pedro Kerr Catunda - a.k.a Yoshi, Mariana Bravo, Breno Flesch, Rafael Schouery, Adolfo Rodrigues and myself). We had four laptops splitted in two round tables. Each table defined a language (Haskell and Ruby) and each side of the table defined a problem (Bank OCR and Minesweeper).
We followed 7 minutes rounds and tried to keep Haskell and Ruby "experts" available to help out people programming. At the end of each round, the co-pilots would become pilot, pilots would go away and part of the audience would join as a co-pilot on each table. We tried to keep it as random as we could in order to never repeat pairs. We had over 1 hour coding that way. It was very intense and fun. Obvisouly, we never got to finish any problem although we walked pretty well with the Haskell OCR system.
All the produced source code is available at Github on the dojo project at UberDojo-02. In retrospective people reported that is was very exciting and that it was actually a good teaching system but that they should police themselves to actually explain quickly the code to the newcomer before starting to code and be even more radical with the baby steps approach. I think this might be a very good exercise for experienced TDDers and agile teams. I believe if a team manages to actually code something slightly more complicated than Roman to Numerals, it is actually showing a lot of code cleaness. We acknowledge, however, that this sort of exercise is not especially welcoming to new people and requires quite a few experience with TDD. We agreed to have a UberDojo once a month in our meetings and keep the rest as regular dojo sessions. If you try it, please let me know what went right or wrong and your impressions.
Thanks and bye bye.
I previously described the Coding Rumor game and later on presented the results we had at PyCon Brasil 2008 doing it. During the Encontro Agil, we tried having a session of what rbp (or R) called UberDojo to follow the UltraDojo idea (the name he prefered for Coding Rumor).
Just to remind you, UltraDojo (or Coding Rumor) is a Coding Dojo session where you don't need a projector. The code is written in one laptop and the pair switches with rounds just like the regular one. Everyone works on the same problem but you only get to see the code for 2 rounds (14 minutes) in which you are the co-pilot and then the pilot. If you are not on any of those roles, you can chill and chat with other people. The advantage of this is that it requires less time focusing on the problem which makes it a good practice for conferences.
The UberDojo version is just the UltraDojo game with several laptops. You should plan to have at least three people for each laptop but you can have more if you want. In this case, when the pilot leaves, he goes to the "audience" and will choose another laptop to go to on the next round.
Last Monday's session happened at Thiago's house. We were 14 people (Danilo Sato, George Malamidis, Rodrigo Bernardo Pimentel, Thiago Colucci, Fabricio Sousa Nascimento, Jacqueline Marchetti, Renato Willi, Bruno Pedroso, João Pedro Kerr Catunda - a.k.a Yoshi, Mariana Bravo, Breno Flesch, Rafael Schouery, Adolfo Rodrigues and myself). We had four laptops splitted in two round tables. Each table defined a language (Haskell and Ruby) and each side of the table defined a problem (Bank OCR and Minesweeper).
We followed 7 minutes rounds and tried to keep Haskell and Ruby "experts" available to help out people programming. At the end of each round, the co-pilots would become pilot, pilots would go away and part of the audience would join as a co-pilot on each table. We tried to keep it as random as we could in order to never repeat pairs. We had over 1 hour coding that way. It was very intense and fun. Obvisouly, we never got to finish any problem although we walked pretty well with the Haskell OCR system.
All the produced source code is available at Github on the dojo project at UberDojo-02. In retrospective people reported that is was very exciting and that it was actually a good teaching system but that they should police themselves to actually explain quickly the code to the newcomer before starting to code and be even more radical with the baby steps approach. I think this might be a very good exercise for experienced TDDers and agile teams. I believe if a team manages to actually code something slightly more complicated than Roman to Numerals, it is actually showing a lot of code cleaness. We acknowledge, however, that this sort of exercise is not especially welcoming to new people and requires quite a few experience with TDD. We agreed to have a UberDojo once a month in our meetings and keep the rest as regular dojo sessions. If you try it, please let me know what went right or wrong and your impressions.
Thanks and bye bye.
Monday, October 13, 2008
Encontro Agil was a success!
Hello everyone,
On Saturday, we (AgilCoop) ran the first 2008 agile conference in Brazil (although TDC had quite a few agile talks, the focus was not in agile). The Encontro Agil (or Agile Meeting) happened at the IME (Instituto de Matemática e Estatística - Mathematics and Statistics Institute) of USP (University of São Paulo). The event was free (as in free beer). We had around 200 attendees, 16 speakers, 2 debates and a free lunch.
We followed several ideas from the Agile 2008 conference. We had an ongoing retrospective on a wall between the two main rooms, we had an open spaces room that was interesting but quite empty since people are not used to those ideas, we had a birds of a feather session with 5 rooms discussing several topics and a huge updatable conference schedule.
On the overall, the feedback was great. Some things people pointed out in the retrospective board: we have to have more coffee, especially in the morning and after lunch. There was a load of information to be absorbed in too little time. Maybe increase the conference size or reduce the amount of information on each talk. Hand-over material has to been better selected.
On the other hand, people loved the agility in the event. We had to find a replacement talker (that was me) because another talker (Jorge) was late and the talk ran quite nicely. We adjusted the schedule on the fly to allow Jorge to give his talk anyway. The free lunch was one of the great points and birds got a nice feedback too since interaction is nicer than just listening.
A few statistics of the event. We had almost 500 people that registered themselves to come. From those, only around 300 confirmed their participation on the event a couple days before. And we had 200 attendees which gives us something around 60% drops from the original registration. As it is frequent on computer science conferences, we had 16% female attendees. Around 80% of the public was either a manager or a developer and had between 25 and 45 years old. We also had 41% of the attendees that had no experience with agile methods and 43% that were novice to it (had less than 1 year of experience). To my information, 60% never contribute to free software projects and 25% contribute occasionally. Finally, music is the extra-curriculum activity that most people practice (44%) and/or would like to learn more (48%) followed closely on the learning wish list by dance (35%).
I guess this is it for now. We will have all the content of the advanced talks on the web and a few videos of the event published around. I will post those when they are available. All slides should be available at the AgilCoop web site in a few days as well as on the conference's web page.
Future conferences in Brazil that will have some agile content are Rails Summit Latin America 2008 organized by Locaweb and mainly Fabio Akita and Falando em Agile organized by Caelum. Both will happen in October while I am at OOPSLA 2008 so I won't be there but I expect them to be quite interesting.
And get ready for next year, our goal is to have at least one international speaker.
On Saturday, we (AgilCoop) ran the first 2008 agile conference in Brazil (although TDC had quite a few agile talks, the focus was not in agile). The Encontro Agil (or Agile Meeting) happened at the IME (Instituto de Matemática e Estatística - Mathematics and Statistics Institute) of USP (University of São Paulo). The event was free (as in free beer). We had around 200 attendees, 16 speakers, 2 debates and a free lunch.
We followed several ideas from the Agile 2008 conference. We had an ongoing retrospective on a wall between the two main rooms, we had an open spaces room that was interesting but quite empty since people are not used to those ideas, we had a birds of a feather session with 5 rooms discussing several topics and a huge updatable conference schedule.
On the overall, the feedback was great. Some things people pointed out in the retrospective board: we have to have more coffee, especially in the morning and after lunch. There was a load of information to be absorbed in too little time. Maybe increase the conference size or reduce the amount of information on each talk. Hand-over material has to been better selected.
On the other hand, people loved the agility in the event. We had to find a replacement talker (that was me) because another talker (Jorge) was late and the talk ran quite nicely. We adjusted the schedule on the fly to allow Jorge to give his talk anyway. The free lunch was one of the great points and birds got a nice feedback too since interaction is nicer than just listening.
A few statistics of the event. We had almost 500 people that registered themselves to come. From those, only around 300 confirmed their participation on the event a couple days before. And we had 200 attendees which gives us something around 60% drops from the original registration. As it is frequent on computer science conferences, we had 16% female attendees. Around 80% of the public was either a manager or a developer and had between 25 and 45 years old. We also had 41% of the attendees that had no experience with agile methods and 43% that were novice to it (had less than 1 year of experience). To my information, 60% never contribute to free software projects and 25% contribute occasionally. Finally, music is the extra-curriculum activity that most people practice (44%) and/or would like to learn more (48%) followed closely on the learning wish list by dance (35%).
I guess this is it for now. We will have all the content of the advanced talks on the web and a few videos of the event published around. I will post those when they are available. All slides should be available at the AgilCoop web site in a few days as well as on the conference's web page.
Future conferences in Brazil that will have some agile content are Rails Summit Latin America 2008 organized by Locaweb and mainly Fabio Akita and Falando em Agile organized by Caelum. Both will happen in October while I am at OOPSLA 2008 so I won't be there but I expect them to be quite interesting.
And get ready for next year, our goal is to have at least one international speaker.
Sunday, August 24, 2008
Friday - Last day at Agile
Friday morning was a bit emptier. A few people were leaving or had already left Toronto. Breakfast was calmer and everyone was interested in the sessions that were elected to be rerun after lunch. About 40 sessions were going to be rerun that were chosen by the attendees by voting on one session per day.
On the first slot in the morning, I attended a talk by Arnaud Bailly with Emmanuel Gaillot and Mariana. Arnaud presented us a small game about Haskell intended to teach young students how to solve problems in Haskell. The game is formed by tiles of lambdas, basic operations, color tiles to match variables, pi to describe the pattern matching and a few numbers. The first exercice we did was to write the factorial of a number. The recursive version came out pretty quickly and when we tried to expand it to get the solution, we noticed the huge amount of tiles needed. It was a great way to realize the amount of memory needed when stacking everything. We worked our way through the tail recursion version in which we could realize that the stack was never greater than 2. I found it a very nice way to show students the consequences of those details.
After the coffee break, everyone went to the Grand Ballroom to the last Keynote of the conference. This time, Alan Cooper, creator of Visual Studio (later sold to Microsoft) and author of several Human-Computer Iteraction books, presented his point of view about Agile and the way software is developed. It was a quite controversial talk. Alan presented his view point regarding the software development process. According to his speach, there four main stages in software development. The first one, "The Big Idea", is completly out of scope to any software development method. It is a creative process that is accomplished by the business experts and developpers should not be involved.
After that stage comes the Design stage followed by the Engineering stage and ending by the Construction stage. He states that Design and Engineering are stages based on iteration and increment, therefore, those are agile stages. And this is where Agile gets it right. However, construction is NOT an iterative stage. Purely incremental. Simplifying a lot, he says that all software should be built once, using agile methods, to be thrown away (since Brooks said, in The Mythical Man-Month, "Plan to throw one away, you will anyway"). After that first sketch, the software should be built from scratch without agile methods. His argument is that the first time, you will discover several new things while you walk ahead. Those things will impact on your software making it harder to understand and more complex. The second time, you already know those problems and can handle them previously working without surprises.
What I don't understand in this way of thinking is why rebuilding the software the first time? The only reason I can find to do that is because you want to change things in it. But if you do, you might encounter more problems and end up having to throw your second attempt away too! And you can go on like that over and over and over. The other question is why not refactor your first version to make it less complex and hard to understand? Maybe it is more expensive to refactor the whole software than starting it from scratch. But if this is true, then you obviously will have new decisions to make when you restart and you may just as well end up with the same problem at the end.
Anyway, the rest of the talk was about how interaction designer can improve the overall quality of the first software development. To this part, I have little to talk about. Alan's presentation can be found in his company's site. I totally agree that interaction designers are very usefull but I oppose to the idea that developers are not supposed to understand a little about their work and be able to perform a few of their tasks. I agree that in all field there should be experts that can help generalists. But I pretty much like the generalists that are able to do the whole thing decently even if it is not excelent. There is a nice article Danilo wrote about the Generalist/Specialist paradox. I believe nobody can be a specialist in all fields becoming therefore a generalist specialist. But I can understand having lots of generalists that have one specific area of expertise. To have a great agile team, all you need is that your generalists have different expertises and everyone knows about it.
Back to Agile. After the keynote, lunch was served in the corridors and I got ready to attend Kenji Hiratabe's double session. The first one was about the lessons he learned from the chief engineer at Toyota's development and the second one was a video about the migration of a traditional industrial chain to a "Yaigi" system. Those were a couple of amazing talks. I won't be able to summarize everything decently. I'll just say we have a LOT to learn from oriental cultures. Working in such environments where respect is a key is an experience I would like to have in my life.
That was the end of Agile 2008's reports. It took me three weeks to post my summaries of the five days I spent in the conference but it was worth it. My best advice is to search on the web for more reports and maybe even slides from the event. Also, stay tunned for next year's Agile to be realized in Chicago. If you want to attend Agile but don't think you can afford it, try getting in as a volunteer. You don't need to be a student to apply for it and it saves you the inscription fee which is considerable. In the next days, I will be returning to my usual posting subjects. Archimedes is the next one and I will try to go back to short posts. Hope you liked it. bye!
On the first slot in the morning, I attended a talk by Arnaud Bailly with Emmanuel Gaillot and Mariana. Arnaud presented us a small game about Haskell intended to teach young students how to solve problems in Haskell. The game is formed by tiles of lambdas, basic operations, color tiles to match variables, pi to describe the pattern matching and a few numbers. The first exercice we did was to write the factorial of a number. The recursive version came out pretty quickly and when we tried to expand it to get the solution, we noticed the huge amount of tiles needed. It was a great way to realize the amount of memory needed when stacking everything. We worked our way through the tail recursion version in which we could realize that the stack was never greater than 2. I found it a very nice way to show students the consequences of those details.
After the coffee break, everyone went to the Grand Ballroom to the last Keynote of the conference. This time, Alan Cooper, creator of Visual Studio (later sold to Microsoft) and author of several Human-Computer Iteraction books, presented his point of view about Agile and the way software is developed. It was a quite controversial talk. Alan presented his view point regarding the software development process. According to his speach, there four main stages in software development. The first one, "The Big Idea", is completly out of scope to any software development method. It is a creative process that is accomplished by the business experts and developpers should not be involved.
After that stage comes the Design stage followed by the Engineering stage and ending by the Construction stage. He states that Design and Engineering are stages based on iteration and increment, therefore, those are agile stages. And this is where Agile gets it right. However, construction is NOT an iterative stage. Purely incremental. Simplifying a lot, he says that all software should be built once, using agile methods, to be thrown away (since Brooks said, in The Mythical Man-Month, "Plan to throw one away, you will anyway"). After that first sketch, the software should be built from scratch without agile methods. His argument is that the first time, you will discover several new things while you walk ahead. Those things will impact on your software making it harder to understand and more complex. The second time, you already know those problems and can handle them previously working without surprises.
What I don't understand in this way of thinking is why rebuilding the software the first time? The only reason I can find to do that is because you want to change things in it. But if you do, you might encounter more problems and end up having to throw your second attempt away too! And you can go on like that over and over and over. The other question is why not refactor your first version to make it less complex and hard to understand? Maybe it is more expensive to refactor the whole software than starting it from scratch. But if this is true, then you obviously will have new decisions to make when you restart and you may just as well end up with the same problem at the end.
Anyway, the rest of the talk was about how interaction designer can improve the overall quality of the first software development. To this part, I have little to talk about. Alan's presentation can be found in his company's site. I totally agree that interaction designers are very usefull but I oppose to the idea that developers are not supposed to understand a little about their work and be able to perform a few of their tasks. I agree that in all field there should be experts that can help generalists. But I pretty much like the generalists that are able to do the whole thing decently even if it is not excelent. There is a nice article Danilo wrote about the Generalist/Specialist paradox. I believe nobody can be a specialist in all fields becoming therefore a generalist specialist. But I can understand having lots of generalists that have one specific area of expertise. To have a great agile team, all you need is that your generalists have different expertises and everyone knows about it.
Back to Agile. After the keynote, lunch was served in the corridors and I got ready to attend Kenji Hiratabe's double session. The first one was about the lessons he learned from the chief engineer at Toyota's development and the second one was a video about the migration of a traditional industrial chain to a "Yaigi" system. Those were a couple of amazing talks. I won't be able to summarize everything decently. I'll just say we have a LOT to learn from oriental cultures. Working in such environments where respect is a key is an experience I would like to have in my life.
That was the end of Agile 2008's reports. It took me three weeks to post my summaries of the five days I spent in the conference but it was worth it. My best advice is to search on the web for more reports and maybe even slides from the event. Also, stay tunned for next year's Agile to be realized in Chicago. If you want to attend Agile but don't think you can afford it, try getting in as a volunteer. You don't need to be a student to apply for it and it saves you the inscription fee which is considerable. In the next days, I will be returning to my usual posting subjects. Archimedes is the next one and I will try to go back to short posts. Hope you liked it. bye!
Thursday, August 21, 2008
Thurday at Agile - No lunch
Thursday morning started just like the other mornings: breakfast in the Grand Ballroom but with most people late. I guess Wednesday evening was quite exhaustive to many people.
I went straight to the Learning & Education stage where I could enjoy an amazing double session (went all the way through morning) of Game Design. This was NOT software game design. It was "hardware" game development. The idea was how to create games that could be used to teach concepts to people. Hubert Smits from Railly introduced shortly the work of Sivasailam Thiagarajan (aka Thiagi at www.thiagi.com).
After a short introduction, Hubert explained that we were going to build a game to teach Sprint (or Iteration, depending on your flavor of agile) planning.
We started by playing a game ourselves. Each os uf wrote down 4 cards with strong opinions he had about iteration planning. Hubert collected all of those and shuffled them redistributing 3 cards to each person. He asked us to sort the cards according to the importance we attributed to the sentence on the card. Meanwhile, he was laying down the rest of the cards on an empty table. Once we were done, he asked us to come to the table, now full of cards, and exchange the cards one by one on our hands with the ones on the table if we considered them more important. When he realised we were all happy with the cards we had, he asked us to trade cards among ourselves following the same idea to increase the value of the cards on our hands (according to our personal opinions). Finally, he ordered us to join with two or three other people and form a group. The group would have all the cards from its members and was to chose three cards that they would hold as theirs. The wrapping up was to have each group present their cards explaning why those cards were important to them.
I found this activity very interesting to align people's expectations about something. I could understand that it was a very good way to have people accepting other people's ideas. Hubert suggested it could also help building a team since the involved people would go from an individual perspective to a group perspective. To me, it looked like a very good ice breaker to get people thinking together.
The next part was the most important one and the goal of the session: to develop our very own game about iteration planning. It was a pretty simple board game. Each player had a character that was in a path leaving from start and aiming to reach the end. The initial rules that Hubert gave us were simple. All players receive about 10 cards at start and those are given back after shuffled when they are over. A player can only go forward if he presents a card that fits the stage in which he is. A player can challenge the presented card if he believes it does not fit that stage. Upon a challenge, all the players in the game should discuss the matter and reach a concensus. If they decide the challenger was right, the challenged player cannot go forward. On the other hand, if the challenged player was right, the challenger goes back one move and the challenged goes forward regularly. The first player to reach the end wins.
Based on those simple rules, we were supposed to define the stages of our game and then write the cards that the players would hold. That was a very interesting activity. It made us think a lot about what were the steps we considered essential in the planning and generated lots of discussion. We then had to gather all the cards we wrote individually and have them classified into the stages we defined. After that, we could change a few rules that we believed would improve the game. Finally, we played our own game to make a few changes with the game experience. We discovered the whole stage stuff was very boring since it took a long time to change stages. The idea that solved it was to have the game being iterative itself. Meaning each move would bring you to another stage and once you were done with the iteration, you would start another until you reach the end.
I loved that experience. It was a great way to have people think about their working system and how to teach it to others. Keeping a coach around as a game driver can be very useful to correct mistakes that the team can make. Finally, playing the game sounded a bit exhaustive but creating it is very revealing. The best part is that such game can be created to teach almost any process or complex non deterministic flow.
During the game session, Danilo, Mariana, Arnaud, Dan and Liz were working on the Block Problem with a Haskell solution. The most innovative idea was to set up a mercurial server (version control) and commit each step so that people could work on their environment and keyboard (Dan had a dvorak keyboard while Arnaud has an azerty one). Once I managed to take them off the, Mariana and me went have lunch with Danilo, Kiko and Bonnie Aumann (which we met at Kiko's presentation on Tuesday) at the CN Tower (CN stands for Canada National). It was a really good lunch with a great view and the chat was very pleasant. Kiko insisting that I was the french one so I should choose the wine and saying that being old (around 35) was way better than being young (around 25).
We came back from lunch about 30 minutes late and I went to my work on the Mezzanine floor. I used the half first slot I had left to relax a bit and review the things I want to ask for reruns. The second slot of sessions in the afternoon was filled with a Panel about open source and agile. The session was organized by Dennis Byrne and had Dirk Riehle, Mary Poppendieck, Naresh Jain and Christian Reis (Kiko). The discussion turned around what are the advantages of open source development that agility disregards or lost. Mary was very sharp as always which made the audience defended itself and attack a few points. I would not be capable of summarizing all we discussed there. The two main points that open source have were setting the user's expectation low and having volunteer work (and therefore committed workers).
After that, we all went to the Banquet where we could enjoy Uncle Bob's talk about Clean Code. Many blogs have already reported what happend but I would like to focus a bit more about his (re-phrased) point: "Craftmanship over Execution". I understand this as a consequence of all the refactoring value we have today. Nobody can sistematically say that refactoring is done. It can always improve. I have to admit I face frequently the question about when should I refactor some piece of code. Should I do it after I've written it and I master it? If I do so, I might be waisting time on something that will never be used (this code won't be extended). On the other hand, if I wait to refactor only when I need to, my code can look really crappy and it might take me some time until I remember how the code was supposed to work. Most of the time, I find myself refactoring things until I just have the feeling that it is enough. I don't know what makes me feel good enough with the code but, at some point, I accept it can be left the way it is even if more refactoring can be done. This sounds obviously as a support to the craftmanship theory since this "intuition" can only come from learning and experience. But shouldn't such motivations be triggered by some regular facts that could be documented? How do we create our craftmanship book? I have no idea but would surely like some tips.
Finally to close the night, Kenji Hiratabe presented himself with 10 other Japanese people by singing the well-know "Dear ecuspi (XP)". For those of you who lost that moment, check it here.
Believe me, around 800 people stood up and sang and danced hearing that. It was really fun!
Well, I am almost over for my reports. I hope I will post Friday by the start of next week. Then I should get back to my regular activities (Archimedes and Squeakasts). Bye bye everyone.
I went straight to the Learning & Education stage where I could enjoy an amazing double session (went all the way through morning) of Game Design. This was NOT software game design. It was "hardware" game development. The idea was how to create games that could be used to teach concepts to people. Hubert Smits from Railly introduced shortly the work of Sivasailam Thiagarajan (aka Thiagi at www.thiagi.com).
After a short introduction, Hubert explained that we were going to build a game to teach Sprint (or Iteration, depending on your flavor of agile) planning.
We started by playing a game ourselves. Each os uf wrote down 4 cards with strong opinions he had about iteration planning. Hubert collected all of those and shuffled them redistributing 3 cards to each person. He asked us to sort the cards according to the importance we attributed to the sentence on the card. Meanwhile, he was laying down the rest of the cards on an empty table. Once we were done, he asked us to come to the table, now full of cards, and exchange the cards one by one on our hands with the ones on the table if we considered them more important. When he realised we were all happy with the cards we had, he asked us to trade cards among ourselves following the same idea to increase the value of the cards on our hands (according to our personal opinions). Finally, he ordered us to join with two or three other people and form a group. The group would have all the cards from its members and was to chose three cards that they would hold as theirs. The wrapping up was to have each group present their cards explaning why those cards were important to them.
I found this activity very interesting to align people's expectations about something. I could understand that it was a very good way to have people accepting other people's ideas. Hubert suggested it could also help building a team since the involved people would go from an individual perspective to a group perspective. To me, it looked like a very good ice breaker to get people thinking together.
The next part was the most important one and the goal of the session: to develop our very own game about iteration planning. It was a pretty simple board game. Each player had a character that was in a path leaving from start and aiming to reach the end. The initial rules that Hubert gave us were simple. All players receive about 10 cards at start and those are given back after shuffled when they are over. A player can only go forward if he presents a card that fits the stage in which he is. A player can challenge the presented card if he believes it does not fit that stage. Upon a challenge, all the players in the game should discuss the matter and reach a concensus. If they decide the challenger was right, the challenged player cannot go forward. On the other hand, if the challenged player was right, the challenger goes back one move and the challenged goes forward regularly. The first player to reach the end wins.
Based on those simple rules, we were supposed to define the stages of our game and then write the cards that the players would hold. That was a very interesting activity. It made us think a lot about what were the steps we considered essential in the planning and generated lots of discussion. We then had to gather all the cards we wrote individually and have them classified into the stages we defined. After that, we could change a few rules that we believed would improve the game. Finally, we played our own game to make a few changes with the game experience. We discovered the whole stage stuff was very boring since it took a long time to change stages. The idea that solved it was to have the game being iterative itself. Meaning each move would bring you to another stage and once you were done with the iteration, you would start another until you reach the end.
I loved that experience. It was a great way to have people think about their working system and how to teach it to others. Keeping a coach around as a game driver can be very useful to correct mistakes that the team can make. Finally, playing the game sounded a bit exhaustive but creating it is very revealing. The best part is that such game can be created to teach almost any process or complex non deterministic flow.
During the game session, Danilo, Mariana, Arnaud, Dan and Liz were working on the Block Problem with a Haskell solution. The most innovative idea was to set up a mercurial server (version control) and commit each step so that people could work on their environment and keyboard (Dan had a dvorak keyboard while Arnaud has an azerty one). Once I managed to take them off the, Mariana and me went have lunch with Danilo, Kiko and Bonnie Aumann (which we met at Kiko's presentation on Tuesday) at the CN Tower (CN stands for Canada National). It was a really good lunch with a great view and the chat was very pleasant. Kiko insisting that I was the french one so I should choose the wine and saying that being old (around 35) was way better than being young (around 25).
We came back from lunch about 30 minutes late and I went to my work on the Mezzanine floor. I used the half first slot I had left to relax a bit and review the things I want to ask for reruns. The second slot of sessions in the afternoon was filled with a Panel about open source and agile. The session was organized by Dennis Byrne and had Dirk Riehle, Mary Poppendieck, Naresh Jain and Christian Reis (Kiko). The discussion turned around what are the advantages of open source development that agility disregards or lost. Mary was very sharp as always which made the audience defended itself and attack a few points. I would not be capable of summarizing all we discussed there. The two main points that open source have were setting the user's expectation low and having volunteer work (and therefore committed workers).
After that, we all went to the Banquet where we could enjoy Uncle Bob's talk about Clean Code. Many blogs have already reported what happend but I would like to focus a bit more about his (re-phrased) point: "Craftmanship over Execution". I understand this as a consequence of all the refactoring value we have today. Nobody can sistematically say that refactoring is done. It can always improve. I have to admit I face frequently the question about when should I refactor some piece of code. Should I do it after I've written it and I master it? If I do so, I might be waisting time on something that will never be used (this code won't be extended). On the other hand, if I wait to refactor only when I need to, my code can look really crappy and it might take me some time until I remember how the code was supposed to work. Most of the time, I find myself refactoring things until I just have the feeling that it is enough. I don't know what makes me feel good enough with the code but, at some point, I accept it can be left the way it is even if more refactoring can be done. This sounds obviously as a support to the craftmanship theory since this "intuition" can only come from learning and experience. But shouldn't such motivations be triggered by some regular facts that could be documented? How do we create our craftmanship book? I have no idea but would surely like some tips.
Finally to close the night, Kenji Hiratabe presented himself with 10 other Japanese people by singing the well-know "Dear ecuspi (XP)". For those of you who lost that moment, check it here.
Believe me, around 800 people stood up and sang and danced hearing that. It was really fun!
Well, I am almost over for my reports. I hope I will post Friday by the start of next week. Then I should get back to my regular activities (Archimedes and Squeakasts). Bye bye everyone.
Friday, August 15, 2008
Wednesday - a free night at Agile 2008
Wednesday was the day without receptions. The day started as usual: breakfast at the conference. Donnuts, fruits, cakes but no croissant or pain au chocolat this time. Sessions started at 8:30 as usual and I was doing my volunteer work on the room where I was going to present the Coding Dojo with Danilo and Mari. We were a bit late for the beginning of the stage because Microsoft's reception was a bit too open on the drinks (this is obviously NOT a complaint).
It was on the Learning and Education stage. It started with a nice presentation from Laurie Williams about the work she has been doing with other teachers/researchers regarding pair programming. They made up a nice funny video to stimulate teachers to adopt the pair programming practice in their laboratories explaining the advantages it presents as well as evaluation modes that could be used to assign grades to each student. The video was a bit exagerated in the way it presented the facts which gave it a humorous profile. Although I believe there is more work to be done on that presentation, it is a very nice start. As far as I know, the video is not yet available but should be once they consider it ready. If you want to help, please email her at williams - at - csc.ncsu.edu.
After that, Garry Berteig talked about the Learning Circle. He stated that there are four entry points into a learning circle. Action, Reflection, Learning and Planning are stages through which we pass through when learning something new. He established those four points as quarters of a circle in which the center is guidance. Guidance is what helps keeping someone in that circle efficiently. He then elaborated how to support each activity and how to lead one to another. He got short on time by the end just when he presented how this can and should affect the way agility is taught.
On the third slot of this 1h30 was the presentation of our Coding Dojo in Sao Paulo experience report. Danilo posted some infos about our presentation here. I would like to highlight the map we built on google maps to show where are the dojos around the world.
This is a reproduction of the image but I would really appreciate it if, in a few years from now, this map counted more dojos in north and central America, in Asia and Australia and in the west coast of south America. Europe has a few dojos but I would also expect to find more options since there are so many countries close to each other and ideas should pass around more quickly.
During the second half of the morning, I stayed in the room to fulfill my volunteer work but could not stay focused since I had to take care of another 3 rooms so I used my time to post the Tuesday report. Danilo and Mari went to the OpenJam where they met with Emmanuel Gaillot, Arnaud Bailly and some other people to have a Coding Dojo session. They presented the Block Problem and started to solve it in Ruby. I showed up a couple times but could not help them. They could not finish the problem but liked it so much that Arnaud and Emmanuel worked on it later on (I'll explain more on the post about Thursday). We then had lunch at the conference and attended the Programming with the Stars event. It was quite cool again (I attended on Tuesdays too) with some pretty good demonstration since they now had more time to code (6 minutes).
After the lunch, I went to a session with Esther Derby where she was going to talk about Crossing Cultures. It was going to happen in the French stage (although it was going to be in English) and she had planned a nice game to show how mixing cultures might be hard to endure. Unfortunately, she needed at least 8 people to run the game well enough and we were 7. So she had to cancel it and I was orphan for the rest of the afternoon. Later on that night, we went have dinner with Danilo and the Toughtworks' fellows which was a very pleasant night.
I'll continue on later with more about Agile and after that series, I'll try to get back to my regular activities. Hope you enjoyed it and bye bye.
It was on the Learning and Education stage. It started with a nice presentation from Laurie Williams about the work she has been doing with other teachers/researchers regarding pair programming. They made up a nice funny video to stimulate teachers to adopt the pair programming practice in their laboratories explaining the advantages it presents as well as evaluation modes that could be used to assign grades to each student. The video was a bit exagerated in the way it presented the facts which gave it a humorous profile. Although I believe there is more work to be done on that presentation, it is a very nice start. As far as I know, the video is not yet available but should be once they consider it ready. If you want to help, please email her at williams - at - csc.ncsu.edu.
After that, Garry Berteig talked about the Learning Circle. He stated that there are four entry points into a learning circle. Action, Reflection, Learning and Planning are stages through which we pass through when learning something new. He established those four points as quarters of a circle in which the center is guidance. Guidance is what helps keeping someone in that circle efficiently. He then elaborated how to support each activity and how to lead one to another. He got short on time by the end just when he presented how this can and should affect the way agility is taught.
On the third slot of this 1h30 was the presentation of our Coding Dojo in Sao Paulo experience report. Danilo posted some infos about our presentation here. I would like to highlight the map we built on google maps to show where are the dojos around the world.
This is a reproduction of the image but I would really appreciate it if, in a few years from now, this map counted more dojos in north and central America, in Asia and Australia and in the west coast of south America. Europe has a few dojos but I would also expect to find more options since there are so many countries close to each other and ideas should pass around more quickly.
During the second half of the morning, I stayed in the room to fulfill my volunteer work but could not stay focused since I had to take care of another 3 rooms so I used my time to post the Tuesday report. Danilo and Mari went to the OpenJam where they met with Emmanuel Gaillot, Arnaud Bailly and some other people to have a Coding Dojo session. They presented the Block Problem and started to solve it in Ruby. I showed up a couple times but could not help them. They could not finish the problem but liked it so much that Arnaud and Emmanuel worked on it later on (I'll explain more on the post about Thursday). We then had lunch at the conference and attended the Programming with the Stars event. It was quite cool again (I attended on Tuesdays too) with some pretty good demonstration since they now had more time to code (6 minutes).
After the lunch, I went to a session with Esther Derby where she was going to talk about Crossing Cultures. It was going to happen in the French stage (although it was going to be in English) and she had planned a nice game to show how mixing cultures might be hard to endure. Unfortunately, she needed at least 8 people to run the game well enough and we were 7. So she had to cancel it and I was orphan for the rest of the afternoon. Later on that night, we went have dinner with Danilo and the Toughtworks' fellows which was a very pleasant night.
I'll continue on later with more about Agile and after that series, I'll try to get back to my regular activities. Hope you enjoyed it and bye bye.
Wednesday, August 6, 2008
Agile sessions on Tuesday
The agile conference is insane!
There are over 30 concurrent presentations going on plus a couple talk/chill out areas and several booths for the companies involved in agile development. Tuesday was the real opening of the conference.
There was breakfast from 7am to 8:30am when the opening Keynote took place. The last post was written during that talk. After that, I ran out to a talk from Dirk Riehle about open source business opportunities. It was a bit empty and Dirk covered mainly only the advantages for companies to use or develop open source. I felt there was more to said about the relationship between agile and open source and how it can help improving your approaches to clients and give you more possible solutions to use.
Lunch followed at the conference where food was pretty like the one from the ice breaker. Nice but could have been better to have some variety. After lunch, I managed to swap work with another volunteer to spend the whole afternoon attending a session with Mary Poppendieck and Christian Reis (Kiko). The first part was a presentation about the way Kiko sees open source development to work and how he works at Cannonical to develop open source. I got a few insights and learned a couple things really interesting. Mostly the very rigid hierarchy that most open source project use to filter contributions in order to maintain a good code base. The second part was just amazing. Mary drove a discussion that should point us to things agilists should learn from open source developers and vice versa. I won't be able to give you a good summary but Mary promissed she would post the results in about 10 days. I've offered myself to help her but I don't really know how I will do it.
Finally, Microsoft hosted a reception from 7pm to 10pm with loads of drinks to everyone and some very funny rock band contest which volunteers proudly won. :) I had a great time chatting with Danilo, Mariana, Kiko, Hernan (an Argentinian volunteer I met here), Elizabeth Keogh, Dan North, Tom Poppendieck as well as many more people. We left around 10:30 pm after about 4 or 5 red wine glasses and having evaluated the Archimedes code with Danilo and Szczepan Faber (one of Mockito's maintainer) to find out why I was having problems mocking a couple stuff.
So far my evaluation for Agile is great. It is even more extreme than OOPSLA since you have more things going on at the same time and there are more events trying to put everyone in contact to each other. It is very intense (and expensive) but it is really worth it.
Today's summary should come up tomorrow so stay on.
There are over 30 concurrent presentations going on plus a couple talk/chill out areas and several booths for the companies involved in agile development. Tuesday was the real opening of the conference.
There was breakfast from 7am to 8:30am when the opening Keynote took place. The last post was written during that talk. After that, I ran out to a talk from Dirk Riehle about open source business opportunities. It was a bit empty and Dirk covered mainly only the advantages for companies to use or develop open source. I felt there was more to said about the relationship between agile and open source and how it can help improving your approaches to clients and give you more possible solutions to use.
Lunch followed at the conference where food was pretty like the one from the ice breaker. Nice but could have been better to have some variety. After lunch, I managed to swap work with another volunteer to spend the whole afternoon attending a session with Mary Poppendieck and Christian Reis (Kiko). The first part was a presentation about the way Kiko sees open source development to work and how he works at Cannonical to develop open source. I got a few insights and learned a couple things really interesting. Mostly the very rigid hierarchy that most open source project use to filter contributions in order to maintain a good code base. The second part was just amazing. Mary drove a discussion that should point us to things agilists should learn from open source developers and vice versa. I won't be able to give you a good summary but Mary promissed she would post the results in about 10 days. I've offered myself to help her but I don't really know how I will do it.
Finally, Microsoft hosted a reception from 7pm to 10pm with loads of drinks to everyone and some very funny rock band contest which volunteers proudly won. :) I had a great time chatting with Danilo, Mariana, Kiko, Hernan (an Argentinian volunteer I met here), Elizabeth Keogh, Dan North, Tom Poppendieck as well as many more people. We left around 10:30 pm after about 4 or 5 red wine glasses and having evaluated the Archimedes code with Danilo and Szczepan Faber (one of Mockito's maintainer) to find out why I was having problems mocking a couple stuff.
So far my evaluation for Agile is great. It is even more extreme than OOPSLA since you have more things going on at the same time and there are more events trying to put everyone in contact to each other. It is very intense (and expensive) but it is really worth it.
Today's summary should come up tomorrow so stay on.
Tuesday, August 5, 2008
Monday at Agile 2008 and past news
Hello everyone,
The end of the holidays was very good. I found my supervisor (absolutely NO problem to do it) and we managed to organize a Coding Dojo in Grenoble with some researchers and some industry workers. We worked with ruby (http://www.ruby-lang.org) and rspec (http://rspec.info/) on the block problem (http://acm.uva.es/p/v1/101.html). It was very interesting and I felt they liked the idea. Even promissed me that they would start their own dojo.
The last week was in Paris where I joined the Paris Coding Dojo (http://xp-france.net/cgi-bin/wiki.pl?DojoDeveloppement - in French) where I met Emmanuel Gaillot (http://emmanuelgaillot.blogspot.com/) and a few other regular Paris Dojo attendees. It was an amazing experience and will probably have future great consequences regarding collaboration between the group in Sao Paulo and the one in Paris.
Finally, I should leave France on Saturday morning. Obvisouly, as always near holidays, my flight was overbooked. So I was offered some money and a full paied day to stay one more day in Paris. I accepted it so it would pay off my accomodation expenses in Toronto. Therefore, I arrived in Toronto on Sunday afternoon. Found out that the student accomodations at the University of Toronto is pretty amazing! The room is quite big and nice in a very nice campus and pretty well geared and very well located.
I then went the Agile 2008 volunteers meeting in the Sheraton Hotel Center. It was a pretty good overview of the size of the conference: 1600 attendees. 400 speakers and around 100 staff (70 volunteers, 20 stage directors and about 10 major organizers). Sunday was really smooth since the conference only sort of started in Monday. Monday only had registration and bag deliveries as well as the research talks. The lines were little, everything was flowing pretty smoothly and people were talking quite a lot. Loads of famous agilists were walking around, meeting each other and talking to other people. It ended up with the Ice breaker evening which was a huge meeting with all attendees with 4 food spots that were representing Toronto's main social origins. There were also several weird pass times you could go into: massage, hand reading, handwrite analysis, henna tatoos, taro players and other stuff.
It was on from 7 pm to 10 pm when those services as well as food and drinking stopped sending people out ot bars or the Musik Maztik which is a special stage in the conference for attendees to play music instruments. Since the timezone difference is about 6 hours between Paris and Toronto, 10 pm was 4 am for me so I went to bed.
Today (Tuesday) is the official sessions start of the conference. Things are going very well so far, the breakfast was amazing and everyone is watching a very good talk from James Surowiecki, author of The Wisdom of Crowds (http://www.randomhouse.com/features/wisdomofcrowds/). He is talking about how wisdom can come out of the crowds and why in some cases, it just gets people dumbers. After this, the first sessions will come up and people should spread over. I will try to keep this blog updated about the conference but I am not sure I will manage it.
That's all for now people. Bye bye!
The end of the holidays was very good. I found my supervisor (absolutely NO problem to do it) and we managed to organize a Coding Dojo in Grenoble with some researchers and some industry workers. We worked with ruby (http://www.ruby-lang.org) and rspec (http://rspec.info/) on the block problem (http://acm.uva.es/p/v1/101.html). It was very interesting and I felt they liked the idea. Even promissed me that they would start their own dojo.
The last week was in Paris where I joined the Paris Coding Dojo (http://xp-france.net/cgi-bin/wiki.pl?DojoDeveloppement - in French) where I met Emmanuel Gaillot (http://emmanuelgaillot.blogspot.com/) and a few other regular Paris Dojo attendees. It was an amazing experience and will probably have future great consequences regarding collaboration between the group in Sao Paulo and the one in Paris.
Finally, I should leave France on Saturday morning. Obvisouly, as always near holidays, my flight was overbooked. So I was offered some money and a full paied day to stay one more day in Paris. I accepted it so it would pay off my accomodation expenses in Toronto. Therefore, I arrived in Toronto on Sunday afternoon. Found out that the student accomodations at the University of Toronto is pretty amazing! The room is quite big and nice in a very nice campus and pretty well geared and very well located.
I then went the Agile 2008 volunteers meeting in the Sheraton Hotel Center. It was a pretty good overview of the size of the conference: 1600 attendees. 400 speakers and around 100 staff (70 volunteers, 20 stage directors and about 10 major organizers). Sunday was really smooth since the conference only sort of started in Monday. Monday only had registration and bag deliveries as well as the research talks. The lines were little, everything was flowing pretty smoothly and people were talking quite a lot. Loads of famous agilists were walking around, meeting each other and talking to other people. It ended up with the Ice breaker evening which was a huge meeting with all attendees with 4 food spots that were representing Toronto's main social origins. There were also several weird pass times you could go into: massage, hand reading, handwrite analysis, henna tatoos, taro players and other stuff.
It was on from 7 pm to 10 pm when those services as well as food and drinking stopped sending people out ot bars or the Musik Maztik which is a special stage in the conference for attendees to play music instruments. Since the timezone difference is about 6 hours between Paris and Toronto, 10 pm was 4 am for me so I went to bed.
Today (Tuesday) is the official sessions start of the conference. Things are going very well so far, the breakfast was amazing and everyone is watching a very good talk from James Surowiecki, author of The Wisdom of Crowds (http://www.randomhouse.com/features/wisdomofcrowds/). He is talking about how wisdom can come out of the crowds and why in some cases, it just gets people dumbers. After this, the first sessions will come up and people should spread over. I will try to keep this blog updated about the conference but I am not sure I will manage it.
That's all for now people. Bye bye!
Sunday, May 18, 2008
Article link
Well,
As usual, I am late with my duties.
The Dojo São Paulo now has a blog where we post the summary of each meeting. We also have a list where Mariana posted the link to our article about our experience that will be published at Agile 2008. And finally, we created a Dojo São Paulo git repository at Github. It is supposed to host the projects started at the Dojo. It currently hosts only the Dojo Unit which is the C Unit testing library we started working on. I have been working on it quite a few to make it a bit more effective. It is, so far, strongly based on conventions and limited to very small projects. If it grows a bit stronger I will post again about it.
I am not at home now but as soon as I get back, I will update my whole archimedes tree and release version 0.54. It marks the return of intersection features such as intersection grip and selection by intersection. Tomorrow the team will define what will be the next goal and I will post it as it gets defined.
I have defined the next screencast's script and I hope to record it tomorrow and post it then. I would like to say I am very disapointed with Google Videos since they are failing to process the screencasts I try to upload. I will try something else later but I lack enthusiam.
That's it for now. See you later folks.
As usual, I am late with my duties.
The Dojo São Paulo now has a blog where we post the summary of each meeting. We also have a list where Mariana posted the link to our article about our experience that will be published at Agile 2008. And finally, we created a Dojo São Paulo git repository at Github. It is supposed to host the projects started at the Dojo. It currently hosts only the Dojo Unit which is the C Unit testing library we started working on. I have been working on it quite a few to make it a bit more effective. It is, so far, strongly based on conventions and limited to very small projects. If it grows a bit stronger I will post again about it.
I am not at home now but as soon as I get back, I will update my whole archimedes tree and release version 0.54. It marks the return of intersection features such as intersection grip and selection by intersection. Tomorrow the team will define what will be the next goal and I will post it as it gets defined.
I have defined the next screencast's script and I hope to record it tomorrow and post it then. I would like to say I am very disapointed with Google Videos since they are failing to process the screencasts I try to upload. I will try something else later but I lack enthusiam.
That's it for now. See you later folks.
Monday, May 12, 2008
After a while, another screencast
Hello,
I've been busy since FISL as always. A couple projects starting over which I will only comment once they go a bit further than now.
Now for the good news, I had a paper about the Coding Dojo São Paulo accepted at Agile 2008 with Danilo Sato and Mariana Bravo. As soon as we finish the last revisions, I will post it here. For those of you who do not know what a Coding Dojo is, check the paper by the end of the week, for the rest, know that we host a coding dojo weekly (soon to be twice a week) in São Paulo and we would be glad if you could join us every wednesday from 8pm to 10:30pm.
Archimedes is walking slowly. I believe we will have most intersection features working for this release but not the save/open feature yet. Selection by intersection an trim will not be ready either. I should release it by the end of the week and I will post about it.
I have finally recorded the 6th screencast about Smalltalk, Squeak and Seaside. It shows the System Browser tool along with the Message names and the Method finder. It is not really very important but I had to talk about it before I can start classes (which is next screencast's goal).
That's it for now. Enjoy the recording:
Download the English version here or see it on Google Video.
Download the Portuguese version here or see it on Google Video.
I've been busy since FISL as always. A couple projects starting over which I will only comment once they go a bit further than now.
Now for the good news, I had a paper about the Coding Dojo São Paulo accepted at Agile 2008 with Danilo Sato and Mariana Bravo. As soon as we finish the last revisions, I will post it here. For those of you who do not know what a Coding Dojo is, check the paper by the end of the week, for the rest, know that we host a coding dojo weekly (soon to be twice a week) in São Paulo and we would be glad if you could join us every wednesday from 8pm to 10:30pm.
Archimedes is walking slowly. I believe we will have most intersection features working for this release but not the save/open feature yet. Selection by intersection an trim will not be ready either. I should release it by the end of the week and I will post about it.
I have finally recorded the 6th screencast about Smalltalk, Squeak and Seaside. It shows the System Browser tool along with the Message names and the Method finder. It is not really very important but I had to talk about it before I can start classes (which is next screencast's goal).
That's it for now. Enjoy the recording:
Download the English version here or see it on Google Video.
Download the Portuguese version here or see it on Google Video.
Saturday, April 19, 2008
Last and best day of FISL
The third and last day of FISL was, for me, the best day of all. Not only could I enjoy my previous night but I could sleep and come to the conference without problems. The day started at 9 am as usual, but the first interesting talk was Randal L. Schwartz about Smalltalk and Seaside. Let me repeat: Randal Schwartz about Smalltalk. Not Perl, Smalltalk! He still loves Perl and is still very important in the Perl world but he said Smalltalk is being an amazing experience.
Sadly, he ran a bit out of time during the talk so the audience could only see very little things about Seaside but the lonely fact of having him spreading Seaside is great.
After the talk, I talked to him about the screencasts and the squeakcasts website idea and guess what? He already knew about the screencasts, saw them and liked it. That scared the hell out of me! :) I will have to think much more to make better screencasts next time.
Already had a small critic about my block explanation that I hope to handle in future screencasts.
Anyway, it seems we might work together to get Squeakcasts under the squeak.org domain. I'll do my best to have the site ready as fast as I can and get more screencasts going.
Next episode was a talk about Scrum and eXtreme Programming by Guilherme Chapiewski. His justification to present this in a Free Software conference was that people need to work in some way, to work and those methodologies get as close as programmers as we can. His talk was pretty basic showing the default scrum and xp definition with a few examples of his experience. I was amazed that he got the talk accepted because people from Agilcoop tried in the last conference and revisors said that it was an already discussed matter. I didn't like a couple things he said although the presentation was good for a general audience. The part when he spoke about eXtreme Programming practices like if it was a sin to use them upset me a little. He also said that XP is scary for manager and Scrum is better because you can present it as a simple method and working in a team, etc... The argument sounded amazingly biased since you can present XP in the same way. I don't think managers are so stupid that a name would scare them more than another but anyway. The room was overloaded, people were sitting in the floor and I suppose it will help convert a few more programmers to agile methods so that is good.
And this was the end for me. Mariana got sick and I left the event earlier to get her into a bed and ensure she didn't get worse. In a short summary, I liked FISL 9 and it was very good but mostly because of the people I can meet there and not so much because of the talks. I hope next year they will have the Smalltalk track running and I can present something nice there. I also expect them to go to a bigger place (maybe FIERGS, which I complained about last year but that can fit the 7500 attendees) and have a more stable wireless connection.
That's it about FISL. See you soon with the next screencast.
Sadly, he ran a bit out of time during the talk so the audience could only see very little things about Seaside but the lonely fact of having him spreading Seaside is great.
After the talk, I talked to him about the screencasts and the squeakcasts website idea and guess what? He already knew about the screencasts, saw them and liked it. That scared the hell out of me! :) I will have to think much more to make better screencasts next time.
Already had a small critic about my block explanation that I hope to handle in future screencasts.
Anyway, it seems we might work together to get Squeakcasts under the squeak.org domain. I'll do my best to have the site ready as fast as I can and get more screencasts going.
Next episode was a talk about Scrum and eXtreme Programming by Guilherme Chapiewski. His justification to present this in a Free Software conference was that people need to work in some way, to work and those methodologies get as close as programmers as we can. His talk was pretty basic showing the default scrum and xp definition with a few examples of his experience. I was amazed that he got the talk accepted because people from Agilcoop tried in the last conference and revisors said that it was an already discussed matter. I didn't like a couple things he said although the presentation was good for a general audience. The part when he spoke about eXtreme Programming practices like if it was a sin to use them upset me a little. He also said that XP is scary for manager and Scrum is better because you can present it as a simple method and working in a team, etc... The argument sounded amazingly biased since you can present XP in the same way. I don't think managers are so stupid that a name would scare them more than another but anyway. The room was overloaded, people were sitting in the floor and I suppose it will help convert a few more programmers to agile methods so that is good.
And this was the end for me. Mariana got sick and I left the event earlier to get her into a bed and ensure she didn't get worse. In a short summary, I liked FISL 9 and it was very good but mostly because of the people I can meet there and not so much because of the talks. I hope next year they will have the Smalltalk track running and I can present something nice there. I also expect them to go to a bigger place (maybe FIERGS, which I complained about last year but that can fit the 7500 attendees) and have a more stable wireless connection.
That's it about FISL. See you soon with the next screencast.
Subscribe to:
Posts (Atom)
Posts
