One minute agiler

Gist of AgileCE

2010-04-13T13:17:00.005+02:00

Just a quick note about AgileCE conference…

Firstly, I want to say "Thank you" for preparing this event to Paul Klipp and his team. I hope they will continue this event – maybe we could consider organizing it in different polish cities? We’ll see…

It was really great pleasure to be there. I had a chance to meet few people whose blogs I’m reading (Rachel, Pawel). If you are interested in presentation’s summaries search Twitter on #agilece as there are couple of such blogs. Here, I would like to share one thought that has come to me after conference:

People factor ("Treat people as adults"), listening others and communication are the most important keys in every project.

Yeah, I know – it is not something new but we often forget about it.

Estimation trouble

2009-05-27T09:47:00.004+02:00

Estimation is an essential part of any projects. You should pay lots of attention for this activity. Thanks to estimation you can do a better planning and this is the beginning of your success. Moreover, it can help your team to organize its work better. In this post I will point out things that can disrupt your estimation. If you are facing at least one of them I encourage you to have a meeting with your team to decide on actions that should be taken.

Estimation is made only by one/few person from the team

It is whole team who is responsible for delivering given functionality, so all (or almost all) members should give their inputs on story estimation. They should agree together on estimation's result. Of course, there are some situation that only one person is an expert in given domain, however in such case others opinion is appreciated as well as they can have different views.

Estimation is made by customer (product owner)

It is a team who does a commitment, not a product owner. Some negotiation between customer and team can take place there, but the final estimation should be done by team.

Estimation is made by team leader

Team leader should act as facilitator during estimation process. He should help a team to provide an accurate estimations together with protecting customer's interest. However, he is not allowed to decide how many hours are required to finish given task.

Estimated work has not been presented to team in advance

Team is often asked to give an estimation ad hoc. The issue with this is that team does not have enough time to understand properly requirements so the estimation is less valued. Preparing list of work and giving it to a team in advance can help reducing misunderstanding during official estimation process.

Inappropriate story's description

Story can be sketchy or too detailed. To address this issue, one person (few people) should check the story's details before estimation process and decide if it is written in understandable form (review can be done with regard to the story clarification, acceptance tests). If there are any issues around this you should escalate them to project leader (or customer).

Team doesn't base on previous experience

Your estimation can be more precise if you learn from your experience. You can do simple exercise to practice this skill: choose a story for tracking at the beginning of the iteration and compare estimated hours work with the actual time spent after finishing it.

Room, where estimation/planning will take place, is not ready

It is team leader duty to make sure that the room is booked in advance and all team members are aware of time and date. So let's make planning visible to your team – you can set up online calendar, send the email's reminder. The good idea is to check the all facilities are available (i.e. flipchart, projector, computer, access to network).

1st Agile meeting = DONE

2009-05-11T22:33:00.002+02:00

Finally it happened! 1st Poznan Agile User meeting went to story. I had planned this event for few months but always had different explanation... until guys from Poznan Java User Group motivated me to schedule this meeting. So the date was set to May 6th.

I didn’t know what I should have expected, how many people would come, etc.. The information about gathering had been sent on few mailing lists. Although getting positive feedback, I was quite nervous. As it turned out, all my concerns weren’t necessary. Around 25 people came and all of them seemed to be excited about Agile.

Presentation started. The topic was "Implementing Scrum in OpenX". The meeting was conducted by Andrzej Swedrzynski. After presenting main rules of Scrum, the most interesting part had begun from my perspective. Andrzej told us how they are using Scrum, what is working well, what difficulties they are having. During this part lots of questions had been asked and often meeting had a form of open discussion. In my opinion, it was really nice to get opinions from different people. Additionally, I found out that problems that we are meeting in our projects are not so specific – I would say they are quite common and OpenX is struggling with them as well. After 2 hours of talking and sharing our experience we decided to finish our meeting.

I’m looking forward next presentations and discussions. Meantime you can trace Poznan Agile Community at usergroup http://groups.google.pl/group/agile-poznan. Keep eye on it as there will be announcement about next meeting.

Scrum, Scrum-ban, Kanban

2009-05-06T12:45:00.005+02:00

I've been hearing about Kanban methodology for weeks. Finally, I had a chance to read quite good comparison Scrum and Kanban thanks to Henrik Kniberg. The basic rules of Kanban are presented below.

My thoughts on Kanban

WIP. Defining the work in progress per given state (column at whiteboard) seems as nice idea. Thanks for this you can set a state’s capacity and you can ensure that the team would not be disrupted by asking for some urgent thing to do and you keep your team busy. The interesting thing is how to set this right "capacity". Hmmm.. Kanban says the team needs to give a few tries to find out correct number – there is no example how to designate it.

Commitment. According to Kanban there is no defined time period for delivering given functionalities. My concerns here are doing a demo builds and delivering releases. How should we do them? Should we wait for customer’s request? Should we add then new request into "TODO" column? Would event-driven approach work? Is the lack of commitment the right thing? Kanban does not mention release plan at all (prioritized product backlog in SCRUM), so the common goal is not visible to the team. Would it demotivate people? What are the priorities for "TODO" column? Should team take the most top one?

Finally. How Kanban can work in fixed-price project?

What about merging Scrum and Kanban making Scrum-ban? What’s your feeling? Do you think it could work?

This movie is a must to see

2009-04-29T09:29:00.003+02:00

Thanks to my team, I was reminded about some great YouTube’s movie yesterday. The first time when I watched it was Scrum course. I remember I was so excited about it. No, I do NOT tell you what it is about! Check this movie to find out what people can achieve together, what is real strength of teamwork...

Power of No

2009-04-23T12:15:00.013+02:00

Agile often relies on negotiation between customer and development. This negotiation means agreement of planned work, changes and requests during iteration.

For example, you have Sprint planning in Scrum during which Product Owner presents stories that he would like to have finished in the first place. However, that’s the team who does a commitment for given iteration and there should be possibility of saying

No, we can't commit that this story will be done.

You should give a good reason of discarding work (some example can be: not enough resource, story not clear enough, too much work, etc.). When you would like to drop stories from iteration, there will be some discussion between customer and team, for sure. Customer always wants to have done as much as it’s possible, development team does not want to do be overworked. Personally, I prefer take less work and finish all of them rather saying that everything will be done and finally not much will be completed in the last iteration’s day.

Another situation when you can say NO is the changes in iteration. Iteration’s priorities can be changed when work has begun. You need to be aware of the impact of changes. If request disrupt current work, say: NO together with the reason (i.e. adding this would cause in not finishing some story).

These two cases present the usage of NO. But what if customer says:

We are paying you, you should do what we are asking for.

Well, it does not seem to be a healthy situation in agile project. Agile is about feedback, shipping often, collaboration, following customer requests, working together towards common goal. I think that sentence below is the nice conclusion of NO's impossibility:

If you can't say No, your Yes won't mean anything.

Agile Is All about Feedback

2009-04-06T21:48:00.002+02:00

Searching through the Agile’s news I’ve come to very dandy sentence:

Agile Is All about Feedback.

After short time of consideration I found out that this sentence is really cogent! That’s true that Agile is a quick response to change of project’s assumption, continuous (iterative) delivery to customer and adjusting product to current requirements. In short, that’s customer’s duty to provide feedback and the next steps (i.e. requirement’s change, project’s assumption) are based exactly on it. Obviously, faster we get the feedback faster we can react to change – faster reaction lower cost!!! That’s why talking with customer and presentation of product during its implementation seem to be natural process. For instance, demoing product can be easily achieved by using nightly build. According to Agile’s spirit, we need to remember that developer does not get full requirement’s specification at the beginning – it is usually short description with some basic acceptance tests. His responsibility is to clarify the requirement (user story), put some questions for customer. What about the customer??? First of all, he needs to be aware that there will be some questions, he needs to be willing to conversation and finally, he needs to schedule a time for this activity (for example for daily check of his email-box). That is customer who decides about the way of implementing requirement, it is his feedback that is responsible for product’s shape.

Above feedback from customer there are some internal team’s feedbacks as well. For instance, developer gets a feedback of his code quality during pair programming or code review. Tester notifies development team about the stories that passed/failed. Further, retrospective - metting where team says what went bad and good, shares thoughts and decides on actions.

Feedback is the main factor of the successful project.

Making Scrum funnier

2009-03-27T16:26:00.008+01:00

Following process can be boring, so let’s change it by playing games with your team dedicated for agile projects. You can find nice summary of them under http://tastycupcakes.com/index.php?title=Main_Page.

The benefits of applying games into your Sprint/Iteration are obvious:

you increase team's morality and cooperation,
you are doing process in more informal, funnier way,
the whole team is involved,
you exercise the team’s communication skill.

What needs to be done to success in playing these games? First thing is the team’s awareness of the game’s rules, all members need to follow them (there is no exception as it can disturb the game), secondly the team need to have a positive attitude and willing to try new things.

In our project, we tried "The Story of our Sprints". The whole team sat down in the circle, everyone was obligated to continue the story began by his predecessor. The general impression was quite good, we enjoyed it a lot. It was different than usual retrospective. We did something similar to the timeline by telling the story – we reminded the most important activities and facts in the iteration in the amusing way. However, some of the team member prefered the “old fashioned” retrospective – rather than saying words in the form of story, they did it without any poetical form. It wasn’t good as it had been killing spirit of game. I tried to persuade them to “build” the story but they followed their own style - I was powerless to change this. Lesson learned from this is that you can benefit from playing an agile game only if all members cooperate each another.

Iteration manager role

2009-03-25T13:41:00.006+01:00

I’ve recently read an essay about Iteration Manager role by ThoughtWorks. I was so excited before going through it. After all, it has appeared I’m already aware of IM’s duties. Generally, the Iteration Manager role is close to the one role from Scrum – Scrum Master. In short, the IM should focus in the following areas:

The Team – track iteration’s progress (day-to-day work), report impediments, make sure iteration’s commitment will be fulfilled, point bottlenecks in the delivery process.
The Customer – act as gatekeeper, protect team from distractions, keep customer from changing requirements.
The Iteration – plan team’s budget (ideal hours), help customer with prioritization, motivate team, owns iteration planning and retrospective.
The Project – form group of people working together towards common goal (they success or fail together); IM needs to aim for productive and happy team members and satisfied customer.

The main responsibility of Iteration Manager is “building well-oiled delivery machine, continually feeding it story cards, and tuning the machine”.

Some activities that can help you to organize your iteration (Sprint in the Scrum) are:

Day-to-day communication with the team,
Informing customer about progress and potential risk.
Avoiding noise and reacting on it if necessary.
Making sure that team has defined goal for iteration and all team member are concerned in the iteration’s tasks.

Being a team player…

2009-02-12T11:23:00.000+01:00

In the IT market there are lots of talented people who possess brilliant technical skills. When you ask them to solve issue, implement new feature, you can rely on them, and you are sure that high quality solution will be provided when they will work by themselves. So what is wrong with this? Basically, from the company’s perspective, individuals are not so important as the team. When you work individually then you don’t bring any value to the project and sometimes you disrupt project’s work (you even are not aware of it). You are not concentrated on the common goal that team has committed at the beginning of the project. Your success is to finish your tasks, not to delivery working software.
So how to be a good team player? In my opinion there are a few ideas that you can follow and they can help you to become team oriented person:

Subordinate your aspirations.
Work with others to achieve a common goal.
Be interested in project’s progress.
Help and support others when necessary.
Share your knowledge and expertise.
Never keep information to yourself.