Thursday, 6 December 2007
Scrum-france is online
www.scrum-france.net is online since beg September to reference all events in France surrounding Scrum: testimonials, events, blogs...
Friday, 13 July 2007
Community
Did you notice it too ? Every day I find a new blog or site about agility, Scrum, XP, ... Hard to identify which one is your favorite source and stick to it like you would with your favorite daily newspaper, isn't it ?
Some guys are trying to collect the best of this growing agile world and publish it on a twice-monthly basis in the Carnival Of The Agilists.
Big thanks to John, Pete and Kevin who have been doing this for 2 years.
Some guys are trying to collect the best of this growing agile world and publish it on a twice-monthly basis in the Carnival Of The Agilists.
Big thanks to John, Pete and Kevin who have been doing this for 2 years.
Friday, 15 June 2007
Pleasure
As a ScrumMaster, I often meet people asking me for advices of how they can improve their development practices.
I consider pair-programming and TDD one of the core practices that fantastically improve the quality of a code and the productivity of a team. I recently changed my ScrumMaster cap to my XP coach cap to show what I mean with this to a team member that never experienced neither pair-programming, nor TDD. I proposed him to practice "pair-TDD" for an hour or two.
Of course, we focused on something with immediate payoff for him: his top-priority bug pending list. We chose the #1 bug and began with writing a TestCase class that put in evidence an un-wanted behaviour. We wrote several test methods each time more unitary to identify as precisely as possible the guilty code.
And it happened again :-) ! I saw his face changing from something like "ok let's try it" to something like "incredible, it's here". He had discovered that even if you don't use it from the beginning of your project, TDD is the most fun and efficient way to correct bugs.
For me the pleasure was to have paired someone to this new world where we share the pleasure of working together, having fun with building robust software.
I consider pair-programming and TDD one of the core practices that fantastically improve the quality of a code and the productivity of a team. I recently changed my ScrumMaster cap to my XP coach cap to show what I mean with this to a team member that never experienced neither pair-programming, nor TDD. I proposed him to practice "pair-TDD" for an hour or two.
Of course, we focused on something with immediate payoff for him: his top-priority bug pending list. We chose the #1 bug and began with writing a TestCase class that put in evidence an un-wanted behaviour. We wrote several test methods each time more unitary to identify as precisely as possible the guilty code.
And it happened again :-) ! I saw his face changing from something like "ok let's try it" to something like "incredible, it's here". He had discovered that even if you don't use it from the beginning of your project, TDD is the most fun and efficient way to correct bugs.
For me the pleasure was to have paired someone to this new world where we share the pleasure of working together, having fun with building robust software.
Thursday, 10 May 2007
Visibility
Two month ago, a friend of mine, how had recently integrated a new department as project manager, was quite disconcerted about how chaotic the situation was in this department. As she had arrived there a few weeks ago, she had to learn her new environment and at the same time assess her five persons team issues, and perhaps lacks. She had to deal with an external software provider with a blurry contract, an help desk service without process and jut out from the user rises, and a team of specialists not prone to share their knowledges. Did you ever meet this ?
We met several times and discussed together about how she could take advantage of Scrum, and how fun this would be. Of course her first opinion, as often from my experience, was that this could be great but unfortunatly would be too difficult to implement. Most of all she anticipated big resistances from her team because of the cultural gap that this shift would mean.
So we focused on her own top-priority problems and forgot the team itself for a moment. This first work was merged with her short-term personal objective to present an action plan to her management. I suggested to initiate a simple speardsheet with the list of the missions asignated to the department for the next months, breaking them down into palpable items. Then she sorted the items by priority in the departement point of view, by setting them up a "business value". Finally, we took another coffee and began speaking about our last week-end because our first work was done. Now, she would go back to her team to present this backlog, ask for estimations on the first items, and see what happens...
Last week, we met again. Good news: she's much better. Trying to estimate the top-priority items and to identify who will be in charge of it made the team diagnose that two persons were missing to be able to reach its next objectives. The management accepted the hire request because it was following from its own priorities. The team feels much better because it now shares the global vision of the department and feels confortable with the work to do, expecting support from new staff.
I felt very excited trying to help her by first evangelize her about the agile approach and then identify with her a consistent first-step implementation in her real-work. I felt like a ScrumMaster Trainer newbie. I like it ! I have now to convince her to follow a real Certified ScrumMaster course.
We met several times and discussed together about how she could take advantage of Scrum, and how fun this would be. Of course her first opinion, as often from my experience, was that this could be great but unfortunatly would be too difficult to implement. Most of all she anticipated big resistances from her team because of the cultural gap that this shift would mean.
So we focused on her own top-priority problems and forgot the team itself for a moment. This first work was merged with her short-term personal objective to present an action plan to her management. I suggested to initiate a simple speardsheet with the list of the missions asignated to the department for the next months, breaking them down into palpable items. Then she sorted the items by priority in the departement point of view, by setting them up a "business value". Finally, we took another coffee and began speaking about our last week-end because our first work was done. Now, she would go back to her team to present this backlog, ask for estimations on the first items, and see what happens...
Last week, we met again. Good news: she's much better. Trying to estimate the top-priority items and to identify who will be in charge of it made the team diagnose that two persons were missing to be able to reach its next objectives. The management accepted the hire request because it was following from its own priorities. The team feels much better because it now shares the global vision of the department and feels confortable with the work to do, expecting support from new staff.
I felt very excited trying to help her by first evangelize her about the agile approach and then identify with her a consistent first-step implementation in her real-work. I felt like a ScrumMaster Trainer newbie. I like it ! I have now to convince her to follow a real Certified ScrumMaster course.
Saturday, 24 March 2007
I work in the coffee room
I started this new mission with two goals: help enhancing global visibility of projects and manage myself specific international projects. The late began this week and I started with learning how the different services are organized. I let you guess: this is the kingdom of waterfall processes.
During a previous experience, I announced from the very start my intention to switch all the organization to agile processes. This direct approach was hard to manage. This time I will first learn the current processes, the relations between the different teams : commercial team, dev, QA, delivery. Today, those are separate teams.
During this step of learning, I will try to find my future partner that will help me next to implement Scrum, or at least Scrum principles. I've already found several, during discussions in the aisle or at the coffee room.
The first opportunity was with a C developer whom I asked about automatic tests implementation in the company. Aa few years ago they used to but no more now. He clearly express the desire to come back to this good habit but confessed that he didn't know how to start. I proposed him to start with him with pair programming of automatic tests. Then I saw that others actually do code JUnit classes. I will try to convince them to disseminate the idea.
Finally (for this week) we (QA member, dev and me) were speaking about a currently integration mission that is taking place in a client integration platform in south America. The guy on-site is facing lots of un-anticipated troubles. They explained to me how the integration phases are designed, how sometimes they don't have time to test the products integration before the delivery. In fact they deliver a "not-done" product. The guy on-site will probably have to extend its stay to the next week, and the company will certainly have to offer this extension. It becomes clear for everybody that the global balance of this operation won't be positive because the money apparently saved before the delivery will be lost just the week after with a consultant working for free to fix the bugs, and others remotely assisting him in extra-time work due to time-lag between the two continents. Sure that this firefighter will come back with another vision of what should be a releasable product. It was the first time for him with this kind of mission.
I suggested we should hold a meeting about his mission and of course I started to call this meeting a retrospective. They asked me about this new word which I had been hardly containing during the last minutes. I proposed to try a simple pattern with analyzing what went good during the mission, what our firefighter would like to make different if he had the opportunity to restart this mission, and finally identify a few actions to positively change the things and keep only one to be implemented. They both were very enthusiastic by the idea and we keep speaking about this new kind of what they call "debriefing" with no accurate ideas of what could be an agenda for a debrief. They both decided to try this simple pattern for their common tasks and to reserve time at the end of a task to identify what went good, what would they like to redo differently and choose a single thing that they will do next time to enhance the result.
I've no doubt that they will help me.
During a previous experience, I announced from the very start my intention to switch all the organization to agile processes. This direct approach was hard to manage. This time I will first learn the current processes, the relations between the different teams : commercial team, dev, QA, delivery. Today, those are separate teams.
During this step of learning, I will try to find my future partner that will help me next to implement Scrum, or at least Scrum principles. I've already found several, during discussions in the aisle or at the coffee room.
The first opportunity was with a C developer whom I asked about automatic tests implementation in the company. Aa few years ago they used to but no more now. He clearly express the desire to come back to this good habit but confessed that he didn't know how to start. I proposed him to start with him with pair programming of automatic tests. Then I saw that others actually do code JUnit classes. I will try to convince them to disseminate the idea.
Finally (for this week) we (QA member, dev and me) were speaking about a currently integration mission that is taking place in a client integration platform in south America. The guy on-site is facing lots of un-anticipated troubles. They explained to me how the integration phases are designed, how sometimes they don't have time to test the products integration before the delivery. In fact they deliver a "not-done" product. The guy on-site will probably have to extend its stay to the next week, and the company will certainly have to offer this extension. It becomes clear for everybody that the global balance of this operation won't be positive because the money apparently saved before the delivery will be lost just the week after with a consultant working for free to fix the bugs, and others remotely assisting him in extra-time work due to time-lag between the two continents. Sure that this firefighter will come back with another vision of what should be a releasable product. It was the first time for him with this kind of mission.
I suggested we should hold a meeting about his mission and of course I started to call this meeting a retrospective. They asked me about this new word which I had been hardly containing during the last minutes. I proposed to try a simple pattern with analyzing what went good during the mission, what our firefighter would like to make different if he had the opportunity to restart this mission, and finally identify a few actions to positively change the things and keep only one to be implemented. They both were very enthusiastic by the idea and we keep speaking about this new kind of what they call "debriefing" with no accurate ideas of what could be an agenda for a debrief. They both decided to try this simple pattern for their common tasks and to reserve time at the end of a task to identify what went good, what would they like to redo differently and choose a single thing that they will do next time to enhance the result.
I've no doubt that they will help me.
Monday, 12 March 2007
A new mission begins
Hi all,
Today I started a new mission in a financials softwares/plateforms provider company. As you shall expect, they are facing the typical troubles that the softwares providers are with a waterfall approach.
Scrum should help them like it did with so many others. I will use this blog to give you pratical feed-back of my intent to help them implementing Scrum. Hope that you will share your ideas and opinion with me about this new adventure.
Today I started a new mission in a financials softwares/plateforms provider company. As you shall expect, they are facing the typical troubles that the softwares providers are with a waterfall approach.
Scrum should help them like it did with so many others. I will use this blog to give you pratical feed-back of my intent to help them implementing Scrum. Hope that you will share your ideas and opinion with me about this new adventure.
Subscribe to:
Posts (Atom)