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.