Release vs PatchLevel

Leave a comment

That was one of the big question in a previous life. On a medium size project (20people) what’s the most valuable (and/or less risky)  for the team when we need to do emergency stuff.  I’ll try to give concrete example of benefit and risk of both approaches.

Before starting a bit of vocabulary :

  • Component : a part of a system, can be seen as one Database(DB), one web service(WS), one Backoffice, …
  • Library : can be seen as a DLL,jar, .so,… a peace of code. Several library made a component. A library can be shared among several components

So, when you need the fix a component, most of the time the change requires only an update of a small set of libraries, or sometime that can be solved by adding a new library.

Taking the assumption that such stuff are made most of the time during a rush, the first stuff to ensure is the quality of the change. There’s a bunch of techniques to help you to secure the change :

  • Pair programming
  • Code reviews
  • Risk analysis.

Once the change is done, the big question is what are you going to update on your production site. Even if you use Continuous Integration you may not want to deploy the current version of the application. On large system, some of the test are not easily done (performance,  GUI, …) and requires some human time, that you may not have (security issues, …).

So, you have mainly  two possibles approaches : ( I’ll try to describe some alternatives)

  1. Rebuild the component and deliver it totally. So, depending of your delivery process, you consider your Patch as a standard release and deploy it as usual. That requires first a build totally under control (no automatic update of third party library, no automatic update of resources file (translation, configuration),  no automatic refresh of your build environment from CVS/SVN (so you are using  tag and/or branches..).
  • The benefits of this approach is : if you need several patches, you take fewer risks, as all your patches are included in the release process. If you need to install a new box, your application is delivered as a block, and not as a main version and several patches to apply after the main install.  Your next release is more predictable as you may not forget some patches to include in it. You avoid the risk of the patch store only on a developer box at lost/forget after few days.
  • The risk of the approach, depend mainly of the quality of the build. If it’s totally under control, nearly no risk, if their is lot of fancy stuff (automatic numbering of some stuff, automatic update of library, automatic update of translation…) the patch can be very difficult to control.2.

2. The second approach is to do a patch, that is to say deploy only one library on the box where the component is installed. This seems less risky as you (think to) control totally what you deploy.

  • The main benefit is the list of impacted file is under control
  • The main risk is the lost of the patch. For example, if you create manually the patch, the files in the patch may not be stored in CVS/SVN. As the library may be build outside the standard release process you may expect some manual error (if your library can be build independently you avoid this risk). As the deployment may be different than the standard release process a lot of human factor can interact with your patch.

So, In fact, the magic solution to have both a secure and quick patch cycle, is to have a build process that is able to do incremental release (build only what’s needed), and controlable by a human (the human decided what’s needed).

If you don’t have such sofisticated build process you have to take care of :

  • Ensure the quality of the patch, ….
  • Ensure all the files modified for the patch are stored under CVS/SVN and they will be automatically take into account at next release
  • A risk analysis of the change : for example to fix a bug, you update a library L1, used by L2,and L3. By fixing an issue on L2, you can create a bigger issue on L3.
  • A quick sanity check to ensure the bug is fix, and doesn’t introduce new issue
  • Try to use the same deployment process than for a full release. Most of the time installation time is more link to time to stop/start the application than copying some megabyte of the box …
  • Ensure to track this patch for the next release.
  • Roll back plan : define it … as the cure can be worst than the disease …

I’ve tried to summarize the keys issues of doing a patch or a release, but this is some other alternative.

For example, if your component is install on two boxes, you can deploy the patch/release on the second one, have both boxes live for some time. As soon as you are confident enough with your patch, you can deploy it on the first boxes.

How to start a new Scrum project

1 Comment

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

Leave a comment

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 ?

Leave a comment

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.