How to start a new Scrum project

Yesterday, with the Cara, we did a little Game on how to start a new Scrum project. I’ll try to summarize the key points, and encourage the personn who’d like to have more info to read proper books

1. All the team (product + developers) : The Product present his vision quickly (5′) and the key objective
   ex : We want to create a new website for an hospital to better handle the relationship among the patient and the hospital. This tool should first help the hospital to make some economy, allowing patient to go home earlier, and the second objective is to make patient to be more confident at home.
2. The product and the team discuss on the stories .  Story : what + acceptance criteria + benefits for the end use
   ex : As a patient, I’d like to contact a doctor to have information on my disease
   AC (acceptance criteria) : During the demo, i want to select a doctor to contact, ask him a question.  On a second screen, as a doctor, i want to see the question only when i decide, and answers it.
   B(benefit) :  For the patient the ability to ask any question to a doctor, for the doctor the possibility to answers all questions in a row, without being disturb all the time.
3. The product can do a A4 page with : The key idea of the project, the key benefit … and may be the key story of the current sprint and it’s key benefit …
4. Group the stories by themas … In order to have a kind of groups of functionalities.
5. Prioritize the groups … only the first one and the second one … don’t need to do more … (don’t forget work only on what you can do soon …). Of course, if you need a full vision, or a more precise road map to share, do it, but it’s can be done after the real start. You don’t need it to start.
6. Estimate your features : poker planing is a solution. Doing poker planing at the beginning may be difficult (new techno, new tools, …). In order to avoid the complex and useless task of precise estimation, you can do relative estimation. Relative to the smallest task you have (the smalest is 1), others are 2,3,5,8 …. You can also choose the average task (8), and others are relative to this average (1,3,5,13,20,40,…)
7. Once you have estimate your first potatoes (or features group). You can start to plan your first release with the MMF (minimal marketable feature).  You may have to split some of your potatoes in order to match your sprint. The first release can occur after 2 or 3 sprint (of two weeks). To achieve this, you may have to define your velocity. The experience of the team may help you… don’t worry, if you over/under estimate that will be a good exercise for future sprint.
8. Define your meeting schedule, …
9. Start it !

Agile Development (Theory in practice) : James Shore and Shane Warden

During a trip, I’ve read this book.  I think it’s a very good book to start with when you plan to implement agility in your team. Both as a developer or a Product.

Was chatting with a friend of mine some days ago, on the ‘where to start’. Indeed it’s difficult. You may be frighten to introduced agility as a whole, but it’s the best solution. Remove all your usages, challenge your team.  But this required both a highly motivated team, and a good Agile/Scrum practitioner to ask for help on a regular basis.

So, I’ll try why I love the book :

• Reminder of the agile manifesto … most of the team who plan to move to agile, have read it one day … but it’s a good reminder
• The book addressed different aspect of agility : developers, scrum master (scrum method), product, client ….  I’ve seen several team forgetting to quickly that one of the objectives of Agility is to make product and end-user happy. It’s not only about making developers happy.

Among the key tips & trap I’ve  read  in the book :

• Stories : Ensure the team share the product vision, challenge your stories by asking : what’s the value for the customer … I especially love the challenge card game. One card, one idea challenge the feature….  Product should define MMF (minimal marketable feature). During TShirt sizing, product and developers should challenge each other, if product requires a feature complex to implement, sometime he will be happy with an ersatz of the feature, but easy to do. The product should also define, how to test the feature.
• Sprint planning :  the team (or a team member) should have prepare the sprint planning, he should have understand what the product want, and anticipate most of the technical issues. Define the success criteria of your sprint.
• Estimate : time give you idea on how you did mistake on estimation … a team will all the time estimate the same way… (same X% error)
• Sprint :  remove task as soon as possible (if you have some delay), it will help team working on the most priority one, and will involve product on definition of the new priorities.
• Demo : don’t lie … if your demo don’t work, be honest .. don’t hide something … elsewhere next sprint, or the “Go live” will be a disaster …

Release process:

• Each release made by a different person, should be part of the sprint, as at the end of the sprint you should be able to go live …

Pair programming , the magic solution ?

After several year of watching/reviewing agile project, I’m wondering what make a project a success or a massive failure.
First, to clarify my definition of success is : the team has delivered what the product and/or the end user was expected in a timely way. With this definition, i removed the aspect of a product team not delivering what the end user expect that’s occur … sometime … often …
So, assuming you have a group of 7-10 engineers, what make a project a success or a failure :

Success key :

• team spirit : everyone is happy to help each team members
• task sharing : everyone in the team can take every task
• release : everyone can release the project
• bugs : everyone works on bugs
• refactoring : everyone re-factor the code, enhance it
• Code quality is the first priority of the eng. team
• Delivering backlog item is the second one.

Failure Keys :

• each task can be take by only one or two guys
• Delivering poor quality backlog item, requiring post sprint refactoring … never done in the real life … so increasing the technical debt.
• Having several backlog : one for the product team, one for the technical stuff … We are delivering software, so technical issue is part of the product.
• Team changing often … introducing a new person is the team, is not so easy, as the team is working as one guy, it’s may be difficult to be part of it.

That still a list under progress, but from my experience, the two keys for success are :

• Good communication among engineer and product team
• Good team work, and in this context, pair programming seems to me the best way to achieve most of the engineering requirement with one practice.

Indeed, by doing extreme pair programing, even team programming is a easy way to achieve all the success point.
Let me explain a bit. What i call extreme pair programming is a pair programing practice were :

• you change the pair often (at least once a day)
• as soon as you need an expert point of view, change the pair, to get the help you need
• as soon as you are block, change the pair, explaining your problem to a new comer, often unblock you.
• when you need to define a new team practice, take a projector, all the team looking at the screen, only one keyboard … and do an time boxes open discussion to present the benefits of the practice …
• change keyboard often … may be one developer write the test, and the other one write the code ….
• you wrote faster code : development is not writing text in a code source file … you have to think, analyze, design, test … So, two brain for one keyboard is not a waste of time
• Do not interrupt the code writer too often, you have to think about design issue, code enhancement … you don’t have time to focus on typos.

So as a conclusion, may be one of the first development practices to put in place is pair programming for the success of your project.

L’achimiste Agile est de retour

Après avoir vécu dans la peau d’un elfe au cours d’une soirée, j’ai voulu à mon tour faire partager l’aventure a mes petits camarades.
Première erreur, faire ça un lundi matin …. J’avais pourtant été prévoyant, et n’avais mis l’atelier qu’a 9h30 …. mais 2 pannes d’oreiller, un enfant malade, et un oubli ou eu raison de 4 lutins…..
Du coup, j’ai un peu adapté les groupes

L’achimiste Agile est de retour

Après avoir vécu dans la peau d’un elfe au cours d’une soirée, j’ai voulu à mon tour faire partager l’aventure a mes petits camarades.
Première erreur, faire ça un lundi matin …. J’avais pourtant été prévoyant, et n’avais mis l’atelier qu’a 9h30 …. mais 2 pannes d’oreiller, un enfant malade, et un oubli ou eu raison de 4 lutins…..
Du coup, j’ai un peu adapté les groupes et leur taille.
Résultat : que du bonheur.
J’ai profité de la séance pour tester une idée : sous traité à un animateur des activités genre ‘gestion de la timeline’, ‘du vote’, ‘recherche de la cause, avec la méthode des 5 pourquoi’.
Cela principalement pour laisser un peu de temps au scrum master, le temps de reprendre un peu “son souffle” et d’observer le groupe d’un peu plus loin. Effet secondaire intéressant, une implication plus active du groupe.
Conclusion : que du bonheur …