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.
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.
Monday, October 12, 2009
Encontro Ágil 2009 - Lean Lego Game
Slightly interrupting the Agile 2009 sequence (I'll come back to it later). I presented the Lean Lego Game at Encontro Ágil 2009 on Saturday (10/10/2009) with Mariana.
Our slides (in Portuguese) are here. You can check a few pictures of the event (including our workshop) from Daniel Cukier from his Flickr account. The session was a success. We had the room filled and people really looked like they enjoyed it.
Our results were pretty good. For the pull system hands on, our production line only managed to deliver one house with a total of 300 bricks on stock.
On the push system hands on, we got much better and managed to deliver 4 houses and the stock was around 250 bricks.
And during the Yatai session, we delivered 8 perfect houses and 1 with a slight defect and had all bricks on tables (about 350 bricks). One nice thing that happened was that attendees actually noticed it and complained about it which lead me straight to Kaizen in a great fluent transition.
As planned, we finished in around 1h30 which left us with some 20 minutes for questions. Since attendees were a bit shy, it ended up being a story telling session where I shared the story Kenji Hiranabe showed at Agile 2008 about the transition of one of Sanyo's cell phone factories to Lean principles. Too bad the video is not public.
We also mentioned the story about a tooth paste factory that hired engineers to build a huge expensive machine that would separate empty boxes from filled ones. Since it would take some time to build the machine, the manager had one of the employees remove the empty boxes from the line while the machine wasn't ready. After a month, he came back to the factory and was surprised to find a pile of empty boxes on the ground and the employee he had assigned to select the boxes doing something else. Near the line was a fan blowing the empty boxes from the production line. When the manager asked why it was there, the employee explained that selecting the boxes manually was too boring and that he felt he would be more useful somewhere else. So he put the fan there and came by at the end of each day to collect the empty boxes and add them back to the stock therefore accomplishing the task that the huge expensive machine engineers were building.
That story is a great example of why Gemba is so important in Lean. People that actually do the work are usually more suited to find simple solutions to problems they have.
I hope to receive more feedback from those who attended and plan to present this workshop more often. Any questions or critics are very welcome.
Our slides (in Portuguese) are here. You can check a few pictures of the event (including our workshop) from Daniel Cukier from his Flickr account. The session was a success. We had the room filled and people really looked like they enjoyed it.
Our results were pretty good. For the pull system hands on, our production line only managed to deliver one house with a total of 300 bricks on stock.
On the push system hands on, we got much better and managed to deliver 4 houses and the stock was around 250 bricks.
And during the Yatai session, we delivered 8 perfect houses and 1 with a slight defect and had all bricks on tables (about 350 bricks). One nice thing that happened was that attendees actually noticed it and complained about it which lead me straight to Kaizen in a great fluent transition.
As planned, we finished in around 1h30 which left us with some 20 minutes for questions. Since attendees were a bit shy, it ended up being a story telling session where I shared the story Kenji Hiranabe showed at Agile 2008 about the transition of one of Sanyo's cell phone factories to Lean principles. Too bad the video is not public.
We also mentioned the story about a tooth paste factory that hired engineers to build a huge expensive machine that would separate empty boxes from filled ones. Since it would take some time to build the machine, the manager had one of the employees remove the empty boxes from the line while the machine wasn't ready. After a month, he came back to the factory and was surprised to find a pile of empty boxes on the ground and the employee he had assigned to select the boxes doing something else. Near the line was a fan blowing the empty boxes from the production line. When the manager asked why it was there, the employee explained that selecting the boxes manually was too boring and that he felt he would be more useful somewhere else. So he put the fan there and came by at the end of each day to collect the empty boxes and add them back to the stock therefore accomplishing the task that the huge expensive machine engineers were building.
That story is a great example of why Gemba is so important in Lean. People that actually do the work are usually more suited to find simple solutions to problems they have.
I hope to receive more feedback from those who attended and plan to present this workshop more often. Any questions or critics are very welcome.
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".
Subscribe to:
Posts (Atom)
Posts
