Looking closely – TO REview OR NOT REview

16. December 2009

Looking closely

Lately in our project we discovered a little bit of a quality issue. Actually it was more kind of luxury problem we noticed as we thought that the quality of our current release is pretty good already but we had been better before. While we had only three to four issues after a sprint the number of tickets have gone up into the twenties to thirties.

Therefore this fact was brought up in the retrospective and the time thought about what the cause is and how we go about it. One of the causes was that in fact the software has grown, hence the likelyhood to fail has become higher. Also the mix of experienced and rather unexperienced developers has changed. We were a bigger team now and have more unexperienced developers (especially within this application). Therefore the testing guys were kind of annoyed of the sudden quality loss – on the other hand you could say they had been to spoiled of the last sprints. So be it – but still the team wanted to something about it.

One of the proposals that came was to do more code reviews before it leaves development. A lot of discussion came up the the developers would like to substitute the tester’s work while the testers said their tasks wouldn’ be to test quality into the software – they were here for quality assurance. Finally the team decided to setup some rules how the review should be done and how much time and work should be put into it. The following is an excerpt of the teams ideas and rules.

  • What exactly should I review?
    • Do we have unit test, frontend unit tests?
    • Is the userstory implemented as written?
    • Is the code documented?
  • Frontend
    • Can all forms/screens be opened?
    • Are the validations implemented?
    • All menus/context menus are done?
    • Are shortcuts applied?
    • ….
  • Backend
    • Did we use the right architecture / software design pattern?
    • Is the persistence correctly implemented?
    • …
  • How should I document my review?
    • Every review should result into a comment to the user story in our tracking tool, which gives the testing people and the product owner feedback what QA we did in development.
    • For every review we add an estimated task to the user story
    • If rework has to be done we add another task
    • Tell if changes may have an effect on other not so obvious areas to be additionally tested

The above list only should give you an idea how we moved forward. Those ideas that – of course – were written to the wiki (thanks to Eric who wrote down and collected these ideas) and work as a guideline for the team.

How long?

One question that we discussed was how much time each developer would invest as they thought they shouldn’t substitute of what the tester would do. First of all, tester test differently: They have learned not only to look at the user story itself but also have a look at the some other areas in the surrounding. So developers will never make testers obsolete.

We then decided to relate the work to be invested to the review to the size of the user story, ie. to the story points. We defined 5 minutes per story points which of course is different in each project as points are only relative values and we surely will eventually adapt that number too. Just make sure you put that time into your original estimation – you would have needed typically that time (or even more) anyway for unexpected rework.

Experience

We quickly noticed that every review resulted into rework. Most of the time the rework had to do with fixes in the software because some part of the required functionality had been missed. Hence, we would have gotten back to that user story anyway.

Another tip would be not to procrastinate reviews. Do them just in time! Try to review not only more than a few hours after the user story has been finished

Finally make sure the reviewer and the developer should change as it turn out every (developer/reviewer) pair tends to have its own review pattern. Some even hardly wrote any review documentation (like only “user story was reviewed”) which helped nobody. So we mixed the experienced with the non-experienced, the un-motivated with the responsibility-driven people and so on…

Finally: the quality definitely went up again.

These binoculars are those of my son. The glasses contain some code from our project that was photoshopped into the picture. Thanks to Gerhard for the right trick to do that efficiently

Agile Estimation

1. December 2009

People are important

One of the questions that I am asked mostly is about planning and estimation. Therefore a recent question of a colleague led me to today’s episode:

Why do we distinguish story points on users stories and hours on tasks?

The reason is granularity and accuracy and also the relation to people and the efficiency of estimation.

Specifying and estimating the requirements:

  • First we prepare the product vision of our product to be built. This is something like a short essay what the key features of the product are.
  • When we start with the project, we actually specify use cases – but not all of them before we started developing. Only the most important features and only enough to get started. Of course we continue with them over the project
  • Now, we extract user stories. Fine grained “use cases” that build small features that can be implemented. These user stories are linked to the use cases. One user story can be used in multiple use cases to fulfill the use cases requirement. (This is need to for setting up testing)
  • With the user stories that have been dropped into the product backlog, we start estimating those based on story points
  • Based on product backlog user stories and their points and based on the team’s velocity (see below), which is measured in story points per sprint, we take the number of stories that sum up to the velocity and move those into the sprint.
  • Only now the team starts to break down each user story of the sprint into detailed technical tasks that can be implemented. The main difference here is that we have decided that those developers that are most likely (but not necessarily) to implement the tasks should do the estimation. However estimation always should take into account that someone else in the team should be in that range of estimated hours.
  • After all estimations have been done, the hourly total of the user stories’ tasks is compared with the hours of available development capacity (minus some overhead)
  • Only now the team is asked for commitment to the sprint.

Why do we estimate story points first and how is it done?

  • The main point here is that estimation of story points is about SIZE. A story that has three points is three times bigger than a story of of one point. A story of five point is almost twice as much as a story of three points.
  • All story points are estimated by the whole team. As such the points (and therefore the size) are related to the whole team. We estimate the size of the stories for the whole team, so it is not person-related.
  • The teams velocity for a sprint is easily measured: Just take the number of story points that have been performed by the end of the sprint. The average number of the last three sprints make up the velocity.
  • Based on that velocity the next amount of user stories are taken and put into the next sprint.
  • To put it into a nutshell:
    • User story points are size (not effort) only.
    • Points refer to the whole team not an indivual
    • Points can be quickly estimated (we strive to estimative on average in two minutes)
    • Points are used for mid and long term planning

Why do we estimate tasks in hours?

  • As stated further up tasks are technical details that have to be implemented during the sprint.
  • As a best practice and to be more efficient we do not estimate each user story with the whole team. The team distributes the user stories to smaller teams or pairs who then split down the user stories into tasks. The people who take care of this work are most likely but not necessarily those who do the implementation. Thereby the accuracy of definining the tasks, the preciseness of the hour estimation and the commitment is pretty high. We experienced an accuracy of about 5% for the team for a sprint on avarage which is extremely good.
  • To put it into a nutshell:
    • Tasks are tied to Sprints
    • Tasks are estimated on hours to get effort  not size
    • As a best practice we try to let those estimate that are most likely to implement the tasks (though is not a rule)
    • Hours are compared to the available capacity

Commitment

  • Commitment is therefore a two step process
    • The first part of the commitment is when the velocity meets the number of the story points for the sprint. Thus the team feels a realistic setting for the task building and estimation
    • The second part is when the hours are estimated and compared to the capacity
    • ONLY THEN, the team commits.


The above picture shows a close-up of one of our candles.

People ARE important

16. November 2009

People are important

This is the start of some episodes based on theAgile Manifesto. Even though a little bit aged (it is from 2001!) it is such a nice treasure in terms that it puts the idea of the agile methodlogy in only four taglines:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Please, not again…we know them by heart already. I know, we do but I learned that many times they are totally misunderstood. There are many false interpretations and myths about them which is why I like to add my five cents to them. In today’s post I will write about about Individuals and Interactions over processes and tools, which is the first tagline of the manifesto.

How do you read it?

Most people “overread” the word “over” – at least, this is what I notice. So the tagline becomes “All about people” but don’t care about tools and process. People ARE important, actually very important, but processes and tools, too!

Do we need processes?

Yes, we do. The process is one thing what the ScrumMaster is for. The ScrumMaster is not the project lead (again something quickly misinterpreted) but the coach and mentor to make sure the Agile Process (here the scrum idea) is undertaken the right way. Compared to approaches like RUP, CMMI, Waterfall, Catalyst or others Agile Methodologies are rather thin and lean approaches. Still they give guidelines that of course should be followed in an adaptable manner. SCRUM is a process that is important to be understood and followed but not blindly.

Do we need tools?

Yes, we do. Tools ARE important as they do make projects more efficient. You shouldn’t use tools only because they are fancy, you should use them to make them team more productive and underpin the aims the team likes to achieve. Not only if you are a developer you should use tools, the whole team can find tools that help to work in a more fun way. Don’t think only in software, paper and walls are fine, too.

There is a lot of discussion in the agile world whether electronic tools should be used for the process (like for project planning and tracking). There is less discussion when it comes to development like in Continuous Integration, Automated Testing, Wikis, Bugtracking.

Use what is most applicable to your team. My current team has chosen electronic tools over the wall (for project planning and tracking) to manage userstories and the storyboard and automatically generated burndown charts and the like it but as always, everything has its pros and cons. In our situation the pros far outweigh the cons.

People’s attitude

Having said that, people ARE more important than processes and tools. So much of the sucess of the project is about the people. But remember the tagline doesn’t say “People and Interactions” but “Individuals and Interactions”. Quite some time we forget that we are all different. People are far from being the same.

We all have different

  • experiences
  • social competencies
  • motivation and engagement

It is very easy to think that the ideal team consists of ideal humans that form the ideal project. Whoosh! Back to reality! There are no ideal people and no ideal teams.

The book says the team member should chose the project and not the project the team member but often we cannot chose to staff the member we want – the situation just dictates who will belong to the team. Differences in expectations and aims of the members are the typical situations. In my current project I had the opportunities to do the staffing for the majority of the members. I was happy to be able to do interviews. I told everyone about the upcoming project and then asked them why they would think they would be perfect for the team. Thereby I learned a lot about that person and his or her attitude towards the project. The technical skill actually was secondary to me!

Experience, social competency, motivation and engagement are very important for the project but don’t expect all the same amount from every member. Some will be drivers, some will be driven. Some are the extroverts, some will be the introverts.

The ideal team manages itself

How often have we heard that. I do believe it is true but not realistic. We are individuals and the team changes from time to time, so it will have its storming phases. My experience is that the team needs someone who guides them. Of course, this can someone “inside” the team. It could be a well-experienced member who has a distinct social competency.

Beware of one fact though:

Grassroots Democracy sometimes becomes

Grassroots Democrazy…


This is one think the chicken are afraid of: The team does what it wants. It doesn’t listen anymore to anyone outside the team. The pig team in itselfs perspective becomes the most important – having forgotten that they are actually a service provider for the chicken. Don’t let the agile democracy become grassroots democrazy! As a ScrumMaster guide the team to a performing team that is happy to deliver what the product vision is.


We need tools and processes but Individuals and interactions are still more important


The above picture was taken at the beach on a german island called Foehr. It shows the shadows of a very good team – my family!

Opening the portal to become agile

8. November 2009

portal

This is start of my new blog. It thought it may make sense to begin with a starting topic…

How could one actually start to become agile?

Most people think it is a major challenge and that they need to dive deep into agile “methodologies”. Even though I wouldn’t recommend to start all alone without help of someone experienced, you still can start small without calling it agile. Let me describe how I started to become agile.

I think it is important to distinguish two areas:

  • The agile methodology and process
  • Agile techniques or practices

I started to become agile without even knowing I was following the agile ideas. That was far from following an agile process. I must admit that I even didn’t really understand what agile meant when I signed the “agile manifesto”. There the term agile was coined  to give a common name to those ideas that were floating around for years already.  So what was I doing by that time?

Use techniques
I was using techniques that are widely adopted in agile teams like the following

  • Write and automate unit and functional tests to improve quality
  • Establish Continuous Integration to reduce integration issues of developers software units
  • Talk to each other frequently and efficiently to improve communication
  • Be efficient about documentation
  • Produce the most important things first, the unimportant things never
  • Understand what it means to be a team – spread responsibilities and get commitment from all

I was implicitly mainly using Agile techniques and practices without knowing or understanding the agile mindset (yet) but who cares? It eventually led my to the idea of studying the whole agile mindset. Only much later I started reading about Scrum and understood that there is a more comprehensive approach to all of the different practices and a framework that puts these and other ideas into perspective.

Start using these techniques and try to understand them by talking to someone who knows and cares.  That way you begin with a small toolset to eventually master the bigger thing to become agile in terms of the Agile methodology and process.

« previous