Written in February 2010 Here is a detailed feedback from our Agile Project.
This project consisted in developing a mobile application for 16.000 train drivers of the French national railroad company. Among the goals of that application :
From a technical point of view, that application had to run on a HTC Touch HD device and could only use 3G data communications. In order to meet client challenging planning, we used Agile Scrum methodology. We are currently testing our app in real-life : we started the deployment and for the time being, 250 train drivers are already using the application. So far, our client is very glad.
Here is a short video (will be translated in english soon):
SummaryContext
Tools used
Results
Degree of implementation of Scrum : Nokia TestPart 1 : are we doing Iterative Development?
Part 2 : are we doing Scrum?
Detailed FeedbackThe Agile approach choiceMy company was about to run this project with a traditional waterfall approach. Obviously I did not agree because I experienced too many mistakes, conflicts and team problems with this kind of approach. The decision to adopt Agile approach was not supported by everyone : it could disturb old habits of the project actors (the customer, my management,...). There were many issues on this project and it was the first try of Agile approach for the customer and my company. That's also the reason why we didn't have a clearly identified Product Owner. The choice to adopt an Agile approach has been made because of the many challenges of the project. Challenges about budget, hard deadline, team coordination (the team was big regarding to the scope of developments) and complexity (technically and functionally). So we had to start developing very quickly with rigor, give a concrete visibility to the custormer as soon as possible, offer flexibility facing business needs changing. The Agile approach was meeting these challenges and met them. Contractual basisWe started by building the Product Backlog with all the customer's requirements in mind. We estimated all of them with Planning Poker technique. At this stage the business needs were not very clear, so we didn't fall into details. But to reassure us, we writed some assumptions in front of each risquy requirement. The customer validated the Product Backlog and the budget was fixed.
During the project, the Product Backlog content changed respecting the swaping rule. For example, the customer asked to add some requirements, we estimated and added them to the PB. In return we took off other requirements less important for our customer and with the same cost. So we respected the budget and deadline. This swaping rule is simple and the customer understood it easily. What about design ?The design effort (business needs analysis, design & specification) has been distributed during all the duration of the project. Only the first sprint (called Sprint 0) was dedicated to architecture design (just enough to start the first real sprint), setup tasks as building the development environment, etc. This sprint 0 had a duration of 4 weeks. The functional design was made during the first week of each iteration and most of the development on the 2 next weeks (some developments associated to mature needs started from the first week of the sprint). It looks like a small waterfall approach inside each sprint, I think we could have done better by designing separately each fonctionnality at any time in the sprint just before developping it. At the end of the first week of each sprint, we requested the customer's validation of specifications. The demo effectEach sprint ended with a demonstration of the application to the customer and end users. These demonstrations were made on a simple developper's PDA and PC pointing to the URL of the integration server for the web part of the application. We hadn't many things to show for the first demonstrations but it was a great experience. It's amazing to see how a simple home page ou home screen (for mobile application) can bring value in a demonstration, it will structure the next pages and screens. The feedbacks are very useful for the Agile team, to check the right understanding of the customer's needs and adapting if necessary. So the customer can reassure him seeing that the project is still on track and the Agile team is even more motivated than before. As a project manager, you often have to fight to get some business decisions and choices from the customer. If you don't have it in time, you can be late or make your own choices (probably good... or not). The demonstration implicates the customer, he can see your progress and is generally more listening to you and your needs, he is more reactive. Costly feedbacks were rare, because of the good work of the team and I thing that in a short iteration of 3 weeks we reduce the risk of misunderstanding. I'm sure that these visibility we offered to the customer contribute to win his valuable trust. Concerning the managment of the team, I made the choice to apply the Agile principles. Game over for the Project Manager that decide, command and control the team members. I removed the hierarchy inside the team and called "coach" the experimented developers. As far as I can remember, I think I gave very rarely real commands. I just coached the team to help her to meet his objectives protecting it from the external disturbance and removing the impediments (so that's the ScrumMaster role). Every member of the team found his/her place, increased sense of responsibility, participated to the decisions to become a self organised team. I was several times impressed about the capacity of the team to take the right decisions, to propose improvement actions during the retrospective meetings. Now it's clear for me that most of the time, the team has the best position to make important decisions regarding to functional and technical constraints. Including organisational decisions. The other surprise for me was to see the powerful team spirit (everyone helping everyone). The daily scrum meeting, pair programming, and other Agile practices obviously raises this valuable team spirit. This is very important for the success of the project, it improves productivity and quality. The team was composed of (obviously) developers, a system administrator, a ScrumMaster and also a functional tester. 70% of the team were beginners in .NET technologies and Mobile development. We have 60% of experimented members and 40% more junior. The daily Scrum meetingThe daily scrum meeting is an important tool of Scrum, it is a moment of intense communication, listening, decision making, discovering impediments, coordination and team spirit enforcement... I think, this theme need a dedicated section or more. The 2 first months, there was about 7 members in the team, the conditions were ideal. However, the team took some time to feel the benefits of this meeting and to make it "their meeting". The begining was very scholastic, each member answering mechanically to the 3 questions speaking to me instead to the team. Slowly, the interactions became more fluid, more efficient. When the team size raised to 15 persons, it was a little bit harder. Scrum advises to stay under 8-10 persons by team. I tried to split the team in 2 teams but it failed. For different reasons I think. The most obvious reason was about the oversizing of the team regarding to the scope of the development (Mostly on Mobile part), so it was difficult to separate the team regarding to all the depencies. The other reason was that I made this separation too quickly and I left the project during the iteration just after (it was a sort of test to measure the team autonomy, but I think it wasn't a good idea to make this seperation in this context). However I'm convinced that Scrum can work with several teams. It works with traditional organisation, it should works better in an Agile organisation. I have no doubt about it. Pair programmingWithout applying literally all the Pair Programming rules as defined by XP, we used pair programming practice. In 2 cases : to help new team members to be quickly efficient (many of them hadn't developed in .NET language and on a mobile before), and to develop complicated things. Concerning the code reviews, we used the Crucible tool (a JIRA's plugin from Atlassian) that permit to make code reviews without disturbing the other member (the reviewer or the reviewed). In further project I'am thinking about generalizing Pair Programming practice applying the rules defined by XP, I'm convinced that we can increase quality and speed with it. I also think that using development dojos (every team member turning to code a same functionality during 2 hours with a video projector) is a really good practice to share development best practices to be more efficient. The most important difficulties I want to underline in this section are about the issues associated to Agile approach adoption by a customer, a team, managment newbies in this domain. I was the only person of the project knowing the Agile methods and convinced by their power. Advocating and building alone an Agile approach on a big project with a fixed contract was a big challenge. I had to brave my fear and the others' fear. I quickly understood why one value of Agile is "Courage"  For example the team had to change its way of working : developing vertically instead of horizontally, using pair programming, communicating everyday with everyone, presenting their work directly to the end users, hearing the continuous integration system alarm when the code is broken, moving post-it, etc. I clearly observed the known phenomenon about a short phase of enthusiasm and doubts, followed by a chaotic phase because of the loss of landmarks (a necessary evil) followed by a stabilization phase (the new landmarks are in place). Today, everyone wants to keep working this way. My superiors too had to adapt themselves to this new way of working. Quite skeptical at the beginning, and later more and more convinced by this approach. The most difficult was to forget the contractual aspects and the excessive effort on planning too precisely in long terms. I also had to be the shield of the team to protect her from pressure from my superior regarding to our delay indicated by any sprint burndown charts communicated to the customer with transparency. Sometimes, the relation with my superior was difficult because of his fear but it ended in a happy-ending. From my point of view of ScrumMaster bringing this approach, I have to admit that it wasn't easy everyday at the beginning and the feeling of loneliness in the Agile practicing domain dominated me (fortunately it was also very exciting). The project was important, I implicated the team, the customer and my superiors in a trip without knowing the path. Even I had learned a lot by reading many books and blogs, following the ScrumMaster course of Jeff Sutherland himself, the daily practicing of Scrum and XP with big issues is a big challenge. But I have strictly no regrets because today I see a team who takes real pleasure to work on the project, end users and customers very happy and hoping continuing to work with us. Moreover I have the feeling that we made our working world a little bit better  Some Agile pilot projects failed because of these difficulties and others. I think it is a good thing to be helped by an experimented Agile practitioner. Even so I think that learning from your own mistakes is very important. From the technical point of view, one of the difficulties we met was about building a continuous integration system for the mobile developments (Compact Framework technology for Windows Mobile). We failed to build it. The problem is that the unit tests can only be run on a mobile device. Our continuous integration system based on Cruise Control covered the rest of the application (web application and interfaces with others system) and compile the code of the mobile application. This tool is very important for the team to be confident in developing and refactoring maintaining a good quality. To make a conclusion of this long section, I want to say that it's important to make changes slowly, adding Agile practice one by one and always observe (observing and adapting, that is the key). In the same manner, for a company that want to apply Agile methods to all teams, it is important to experiment with only one team before. Tools usedRegarding to our budget, we chose the Atlassian suite in term of software tools :
What can we improve ?If we had to restart the project from the beginning, what should we change ?
|
|
|
|
Accueil >
Agile methods in action |
It's time to give some news. And the good news is that we pass the Nokia test ;-)
Now we have a clearly identified Product Owner, we release the product at the end of every sprint. When the Product Owner has enough new features after several sprints, he decides to deploy the new product version. The application is very critical because it's used to drive trains, so it's tested during sprint and also after the release. The Product Owner decides of the content of each sprint with us both user stories that defects to correct. We have very few defects and most of them are minor. We track our velocity. Everybody take pleasure to work on the project.
Concerning XP practices, it's difficult to convince the team to use TDD. We started small with occasional pair programming practice that help the new developpers to learn quickly and increase the collective ownership of the source code. Now, we also use User Stories cards writed by the Product Owner's team. It's very usefull for the conversation with the Product Owner's teams, to drive the development with the tests. The sprint planification is also easier with these cards.
The deployment of the application to the 16 000 train drivers is difficult because of social challenges.
The labor unions resist to changes without trying our application. These unions are only few persons but they have a lot of power and are in conflict with their top management.