One minute agiler

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 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).

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.

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?

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...

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.

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.