The Blog
The tale of the catching team
published September 10, 2010
Have you ever been in a situation where a software project is started with a clear roadmap and beginning works very well? Then after a while, “easy” parts of the software are done and suddenly new features are harder to implement because future plans are not clear enough.
It is almost like the story of the tortoise and the hare. The role of the hare is played by a product owner, the tortoise is played by a Scrum team. If product owner has other responsibilities or vision is not clear, we might end up in a situation where team “catches up”. Suddenly confusion increases because team is not sure what to do next and how to do it. The role of the hare can also be played by other system that team is trying integrate to. If both “client and server” are developed simultanously, client code can be ready before server which will hinder final testing.
An advise “Just make sure everything is ready enough when implementation starts” is very easy to give, but harder to implement in practise. You should, however, be aware of this if you want to avoid “the tale of the catching team” ;)
Maybe it will work out in the end
published August 20, 2010
Say you are a product owner and you are building up a solution using Scrum. You have decided that sprint length is 3 weeks and team will show you the results after each sprint. Unfortunately, after each sprint the results are not quite what you have expected, but you think that maybe it will work out in the end just like you have visioned. Stop right there, it won’t.
The final results you are getting at the end are those you see in the sprint demo. If demos are buggy, you will get a buggy solution. If demos feel “not quite right”, you are not building the software you are seeing in your dreams. If this sounds familiar to your current situation, you will be needing x “finalization sprints” after you are “ready”.
The key is to stop immediately when you get the smell and trust your gut feeling. Increase your definition of done and start building production ready software, that is how you will succeed.
Scrum Master as a team member
published August 3, 2010
In small teams it is common for Scrum Master to work as a team member and work with code by developing new features. Does it work? Well, it depends, but it can easily lead to problematic situations. I feel that one person can work as a Scrum Master for max. 7-9 people and these people can be divided into multiple teams or work in a same team (although 9 team members might be too much). When there is not enough work for Scrum Master and he also works with new features, there is a possibility that:
- He will concentrate too much on code and neglect real Scrum Master work
- Dual role will hinder team self-management
- Scrum Master can become a bottleneck if he is working with architecturally key components
- Dual role can cause role conflict
Unfortunately, having non-coding Scrum Master is not always possible but if you can, you should try to fully utilize Scrum Master, so that he works with multiple small teams simultaneously.
However there are clear benefits if Scrum Master is very familiar with used technology, knows codebase, and understands architecture. This way he can coach younger developers and help team to avoid pitfalls.
Managing Product Backlog
published July 2, 2010
A good product backlog is essential for sound agile development. However, there could be more information about backlogs available and best practices for managing it. A basic explanation can be found almost anywhere.
What follows are my personal findings about Product Backlogs in Finnish culture. I believe that role of Product Owner will differ between cultures and what works in e.g. feminine (Finnish) culture is not necessary a valid way to work in a masculine culture (e.g. Japan). See more here.
Who writes it?
Scrum Alliances’ website says that Product Owner “defines the features of the product or desired outcomes of the project” and “Prioritize features/outcomes according to market value”. In reality there are often multiple persons writing the backlog. Product Owner will usually write most of the backlog, but it might be that he or she simply does not know all aspects of themes well enough to write stories about them. So, product owner can delegate some writing to other business-aware people, and once written, prioritize stories together with the writer while making final decisions whether task will get made or not. Other items are best written by the team, such as highly technical stuff that will have to be made.
Where to store it?
I have tried Jira, Confluence and Excel. For me, Excel has been the best of three. Items are easiest to edit in excel and you will be able to draw charts directly to backlog. Other tools have been in my opinion harder to use.
Format
I Recommend writing items in a user story format “As a [role] I want to do [action] in order to [goal]“. Last “in order…” clause is sometimes present, sometimes not.
- As a blog writer I want to write a new blog post
- As a blog writer I want to edit published post in order to fix my spelling
- As a reader I want to submit a comment
- As a reader I want to delete a comment that I end up regretting.
In addition to story text, we have added fields:
- Priority number for story (we have often given the most important item value 1000)
- Acceptance criteria (list of things that story must or must not do)
- Time estimate
- Comment field (so that people can add temporary TODO comments)
Some backlogs also use an id number for a story, but since there should not be two stories with same priority, I have left id out and used the priority as id. It has worked so far.
Estimating user stories
The team will estimate the user stories. I have used “ideal working days” and storypoints which are just numbers showing relative size of stories. There are some benefits using Story Points, since people are better estimating relative than absolute sizes, but ideal working days have also worked out just fine for me. Sometimes we use planning poker cards, sometimes not. Main thing to avoid is groupthink.
When do we estimate?
We usually do 30-60 minutes at a time. We have also tried to estimate 2 stories every morning after daily scrum, which also worked pretty well. Set time aside from every sprint and do estimation in small bits.
Attributes of a good story
Stories should be independent, negotiable, valuable to users of customers, estimatable, small, and testable (User Stories Applied).
Are all work tasks written into the backlog?
No. We also do other things in a sprint that does not fit neatly in to the backlog, such as:
- Backlog grooming
- Helping customer with technical stuff
- Test and production environment deployments (although these should be automatized)
- Analyzing of bugs (not that we have these :)
- Etc.
Instead, we reserve time for these tasks in sprint planning and then fill rest of the sprint with user stories from the backlog. This way you can establish pretty constant velocity and use that information to calculate release dates.
Quality of the backlog is revealed in the sprint planning
If a product backlog is in good shape, your sprint plannings will be easier. Turned that around, long and painful sprint plannings will probably have something to do with a messy backlog.
After the sprint
Once the sprint is ready, we move finished backlog stories onto a new excel sheet called “finished stories” so that we can see our velocity later. Stories that are not finished will not be counted to velocity.
Velocity chart
After stories are moved to the “finished stories container” I feed sprint velocity to a “velocity-o-meter” (excel table) and let it draw a new velocity chart, which looks something like this:
Release rhythm
The velocity chart above is an imaginary one, but it demonstrates release rhythm that I feel is often present. Amount of new stories can drop during a release (sprint 5 in our picture) and gain new momentum after release (sprint 6 in picture). Depending on sprint length, velocity can drop for couple of sprints if sprint is a short one. Ideally, this drop would not happen but I have not managed to fully prevent it. This has very much to do with the definition of done and the quality of deployment process. In addition, some solutions just need more “field testing” than others.
Summary
There are lots of things that I have learned through experience and probably other people working with Scrum do some things differently. Main goal for me is to fit Scrum into organizational culture and work with it, not against it.
Agile project ramp up
published May 6, 2010
The current project I am participating started without ramp up and the whole team was brought on-site right from the beginning. Now, 2 months after the start, I feel that some kind of team ramp up would have been useful. We started the project without a real product backlog, architecture plan, wiki or bug tracker. First two sprints were pretty much filled with infrastructure work, initial architecture design, backlog work, and the “normal sprint 0 stuff”. Still I feel uneasy.
Do not get me wrong, our customer is really good and in my opinion, doing lots of things right. But I think that we would have been better off had the project been started only with a team member and a scrum master. Then say after 3 sprints, rest of the team would have been invited to the party. I feel that in the beginning there are too many obscurities to fully utilize whole team potential and unnecessary waste is generated.
Also, Scrum.org’s Scrum guide says:
The ScrumMaster works with the customers and management to identify and instantiate a Product Owner.
But for my current project, it was other way around.
One could argue that by inviting whole team from the start, each member will know project history from the beginning which will help them grasping social representations among other things. Also by ramping up the team, you will unintentionally divide the team to “old-timers” and “newcomers”, but that will hardly be a problem because team is still very much forming and open for the newcomer innovation. During ramp up period there would be time to get product backlog started and initial prototypes/mock-ups made.
What do you think, do you ramp up your agile projects?
Importance of a coach
published March 23, 2010
During yesterday’s morning exercise I once again realized importance of a coach. When you feel like giving up, you will need someone to kick your fat ass forward because you definitely can do one more. And then one after that. While sweating with weights, trainer kept pushing me forward. And push I did.
In IT projects we encounter same challenges. We have a defined process in place and we know what we should do but it is easy to cut corners and start slipping. To keep a team on a track, the process must be followed. If the process does not work, it must be redesigned. In addition, we must always try to move forward towards greater value and better productivity because if we are not moving forward, we are sliding backwards.
I know some teams that are doing “Scrum” but without daily scrums. I believe that this is a first sign of a lazy team. I also believe that a lazy team is not building a great product. If the team does not have a discipline to follow a simple process, can you realistically expect that the team is writing good unit tests and actively sparring a product owner? I do not think so.
So whose job it is to see that process is followed in Scrum? Thats right, it is yours, dear Scrum Master. You are the coach who is pushing team forward. It is your job to cheer for the team and keep pushing them forward.
Monthly learning sessions
published January 12, 2010
I have started to organize monthly learning sessions. The idea is that I choose a topic suiting to current sprint, gather information on the topic and finally organize a half hour event where we discuss about the topic. So far we have had sessions on java serialization and character encoding that sound like basic topics, but as it has turned out, people have not known every detail about them and have had presumptions that have been proven wrong. Of course juniors know less than seniors and it is a great way for seniors to pass knowledge forward. Nice addition is that this requires me to dig into the subject thus increasing my knowledge, because teaching about a topic is the best way to understand the topic by your self.
Passing a Scrum master role forward
published December 18, 2009
My coaching week is almost over. During this week I have been working as a developer while mentoring our temporary Scrum Master. We decided to change roles as it was OK with a customer and team member had interest in working as a Scrum Master. Week has been a success and I have learned lot about my assets:
- I still have skills to work as a developer :)
- I have ability to work as a coach.
- I am pretty good at grasping big pictures.
- I have an intuition about upcoming problems.
Also by watching Scrum Master to work, I clearly see a lot of value in keeping daily scrums short, focusing on impediments, and keeping the team on a sprint track. If you have not tried changing roles, I recommend you try it.
A question to ask in a sprint retrospective
published December 15, 2009
“What should we do differently during the next sprint?”. That was the way I opened our retrospective on Friday. No one answered. Hmm, everything is as good as it gets, case closed, Right? Wrong, you should dig deeper. “Ok, name one thing that you will not want to do during our next sprint”. This one sunk in. Answers and corresponding actions were:
- Team member 1: “I do not want to do software development” (this was a joke, but we decided to take action) = Ok, you will be working as a temporary Scrum Master for the first week of the next sprint.
- Team member 2: “I do not want to fix so many selenium tests at the end of the sprint” = Great, we will fix all tests first thing every morning.
- Team member 3: “I do not want to do as much bug fixing, testing and deployment as I did in this sprint” = We will have to find a way for you to make more new features.
- Team member 4: “I do not want to code javascript in the next sprint, but if I have to then I guess I must” = Sometimes you just have to :)
And now during first week I will be doing development and first task is building of a Liferay community POC, sweet.
Differentiating between bugs found in a quality control and those delivered to a customer
published November 30, 2009
In our software delivery process at the current customer we end our sprints to a production release. This is a very nice way to keep iterations compact and to minimize huge testing effort before deployment. So, how do we keep track of the bugs that are found inside a sprint by our own quality assurance and those that are shipped to the customer in the new release? We use custom issue types for Jira.
We create the bugs found inside the sprint as “notices” and the shipped bugs as “bugs”. This way we can easily keep track of how our quality control process works, what is the ratio between the notices and the bugs, and to track exactly how much time is spent on a bad quality. This important data is later used in sprint planning to make sure we have reserved enough time to fix notices before the next production deployment. This is a must if you want to release quality software at the end of every sprint.
« Newer PostsSubscribe to RSS feed
The Tag Cloud
Agile Business Coaching Coding horror Conference Customer Design of Experiments Future Group dynamics ITIL It should not be that hard Java EE Kanban Leadership Lean Liferay Methodologies Natural UI Performance tuning Process Productivity Quality Retrospective RIA Scrum Six Sigma Social psychology Software Software architecture Testing This is great TOGAF
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
Samuli's Links
The Blog Archive
February 2012 (1)
January 2012 (1)
November 2011 (1)
June 2011 (2)
May 2011 (1)
April 2011 (2)
March 2011 (2)
February 2011 (1)
January 2011 (1)
December 2010 (1)
November 2010 (1)
October 2010 (3)
September 2010 (3)
August 2010 (5)
July 2010 (2)
June 2010 (3)
May 2010 (4)
April 2010 (2)
March 2010 (6)
February 2010 (7)
January 2010 (3)
December 2009 (7)
November 2009 (6)
