One minute agiler

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.

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.

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:

1. 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.
2. The Customer – act as gatekeeper, protect team from distractions, keep customer from changing requirements.
3. The Iteration – plan team’s budget (ideal hours), help customer with prioritization, motivate team, owns iteration planning and retrospective.
4. 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:

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

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:

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