AgileConference India – 2013
During an agile refresher course that I conducted , I used the balloon game(Thanks to Tastycupcakes) to let the team understand concept Acceptance testing Criteria and the game went well and feedback that I got was it was nice to teach the acceptance criteria through such games.
How the Game was played?
Before I displayed the ppt to explain the team about the acceptance criteria that the team should concentrate while developing/ testing a story , I decided to play this game.
I started this way, it’s really boring to stare at the ppt’s for a long time . So Lets Play a game!!!
I showed the team a balloon which I had already filled with air, with a face drawn on it. I told the team , You’ve got 1 minute to fill air and draw some faces on the balloon. The moment I completed my statement, the team did not even bother to listen anything further. They just started doing their home work. I was just giving the countdown in between the speed up the team’s action. After 1 minute I shouted Time Over
Time Over still some team was doing their job tirelessly.
Then I went to each team to see their product with a small box in my hand, saying that I will accept your balloons only if it fits into the box and only if it has round eyes, equilateral triangle as nose and a semi circle as mouth. The team was really angry on me , since I rejected most of their work product.
The discussions that rose were … Ohh!! It’s really unfair, and you did not say all these Acceptance criteria in the beginning.
Then I said, I though you know that …They said you should have told that …The argument went on for few seconds.
Then I explained my acceptance criteria and played the game , this time the team were able to produce some good work product and most of the balloons and its drawing were as required and hence they were accepted.
Never start a user story on assumption basis.
Always ask the Product owner about the Acceptance criteria.
Till now, I thought the daily stand up is always a funny and interesting method to start the work .But now few seen incidents clearly made me to revise my thought.
Once in a team’s standup, the scrum master was late and hence he has asked the team members to postpone the standup till he comes. This made the team members think that the he is acting as a team lead.
In another incident one team member informed that he will be late and hence the Scrum Master postponed the stand up.
In my opinion on both the occasions the Scrum masters decisions were not correct.
The basic thing is that the standup should happen @ the same time and @ the same place daily.
It is not mandatory that the Scrum Master should be there for the standup. It is good for the Scrum master to attend the Daily stand up to sense any open/hidden impediments. Sometimes the team member may not even like to talk about the impediment that he is facing within the team and similar kind of impediments can be identified only if the Scrum Master is there. If the team is facing a common problem and the Scrum master is not there for the Stand up , then it is not the scrum master fault that he missed the stand up to sense the impediment. The team should approach the Scrum master later to talk and find a solution for the problem.
If a particular team member is not able to attend the stand up on a particular day due to his personal reasons, then it is absolutely fine. But if the same person is missing the stand up daily then I guesses there is certainly some attention needed to understand the problem and solve it.
The main point behind stand up is that the team gets self organized on its own to do the work. Once the team gets self organized and starts delivering, there is no need of a Scrum Master.
This is the meeting where all the people who are interested in the product development will be participating. The meeting is split in to two parts. During the first part of the meeting the Product owner pulls out the user stories from the product backlog and will start explaining about his expectations out of each user stories. This is where the team has to ask number of questions to clarify about the user stories. The team is encouraged to ask all the questions that would help them in understanding the user stories in a lucid way. More the questions the QA team asks more clearly the developer would understand about the user story. It would also help the QA make good test coverage while writing the test cases. The user stories pulled in for the new iteration may vary from any kind of new development to bug fixing. But while deciding the user stories product owner should keep in mind about the team’s velocity and the team’s availability in mind.
It’s always a good idea to ask about the team’s availability at the very beginning of the sprint planning meeting.During the second part of the meeting the scrum team pulls out the story that was decided to work on the current sprint. Each story is then divided into many tasks based on the discussions between the developers and the testers. Separate task is assigned for the tester under the same story. It is better not to include the automation testing task along with the manual testing tasks. If team feels that there is difference between the story points after putting all the tasks together, poker can be used to estimate the story points. The granular breaking down of stories into tasks should be done by the team rather than any individual like managers. It is the team that has to decide during the stipulated amount of time. Rather than the managers, the best people to decide what can be done during the time boxed are the people who are going to do it [Ken Schwaber]. When the team decides what to do, it’s pushed indirectly to make an open commitment which it will strive to make it DONE.
The artifacts that would arrive at the end of the sprint planning meeting would be  Sprint Goal List of user stories and tasks that are committed for the sprint put up in a document or any kind of scrum tool that is visible to the team and the management.
The common mistake that the team makes during the estimation is that the team always thinks in positive way and it tries to pull out maximum number of user stories. The scrum master should always help the team in picking up “Just Enough” user stories. Also while planning the, the stories and the tasks should be made in such a way that some kind of working demo can be given whilst the story is closed. Also keeping more tasks in a story makes the story to be in the open state for a long time during the sprint. So the scrum team has to make sure that there are only “Just enough” tasks for a user story. It always makes the developer/tester happy when some story gets closed during the sprint.
Yesterday, while going back home, I started talking with my co passenger. Luckily, I landed sitting next to a person who is a project manager & Scrum Master for two projects. We started speaking about various processes they follow in their organization and he said he is handling 2 projects.
Me: How big are your teams?
PM/SM: Hmm One is with 6 team members and the other one with 15 team members.
Me: huuh…I guess 6 will be the small and the happiest team and 15 will be little tough to handle for you..
PM/SM: yeah that’s true…It’s a big HEAD ACHE for me conduct daily stand ups..
Me: How about sprint length for both the teams?
PM/SM: For 6 members it is 2 weeks sprint and for the other team its 30 days length.
Me: Ohh Ok. Then how do conduct retrospective for both the teams?
PM/SM: For 2 weeks sprint I normally conduct along with the 1 month length sprint team, so that there is no need for me to WASTE TIME in retrospective.
Then my bus stop came and I wished him GOOD LUCK and got down.
I guess here in this case the management made few mistakes first my assigning the PM as a Scrum Master. Secondly I felt that the person is doing the job as a scrum master feels it as an extra burden.
Thirdly he is not much interested in Conducting retrospective, the heart beat of scrum to improve the team performance in each sprint. I guess people who learn scrum through books and papers are doing the same thing in the rest of the world too. I guess management should stop doing the basic mistake of asking PM’s to become a Scrum Master. In some case this may work. BUT in most of the cases it will be the other way around.
Currently, Most of the time an organization introduces agile into a development team to deliver better and quicker software. That’s faire only when the development team and QA team gets ample support from the management. In a traditional software development like waterfall, the software or the product will be deployed after it passes through all four steps like Design, Development, Integration and testing. After it comes out of the final step, it will be give to the customer for beta testing. If the software works fine then it’s well and good for the client. If it is not working as the customer would have expected, then that’s going to be staring point of the problem. At the final stage, you will be asked to fix the bug whichever the customer reports. Some bugs are easy to fix because they are at the top level. Some catastrophic bugs are really hard to fix if the root cause lies in the first gate of your process, which is Design. Also looking from business perspective it will be always easy to change at the design stage rather than at some other stage.
If any requirement change arrives at the design stage it’s going to cost less for the company to make the necessary changes. The cost is directly proportional to the stage at which the requirement change arrives. Apart from cost, what is lost is time and effort spent in gathering information prior to the design stages. In a traditional waterfall, lots of effort will be put in documenting stuffs at each stage. All these efforts are going to trash if a huge requirement change steps into the project. Normally the developers and the project manager curse the client for making such changes at the later stage of the project. But in a fast changing technological world, user needs are subjected to huge change.
If there are requirement changes at the end of the project, its always all going to be waste, your energy, meeting time and the documentation that you did in the very beginning of the project. When the markets were not so competitive it was always a habit of making a detailed design and then do the rest. If you follow the same scenario, I guess by the time your product steps into market, I guess you will be the last person with minimum features in your product. To survive in current scenario, I guess everything needs to more Agile.
Agile is a new way to develop a product. It’s a new method to deliver the most important thing to the user in rapid manner. It can also be defined as a new methodology to adapt to rapid customer changes. In an agile software development large requirement are developed and delivered in pieces. The large requirements are broken down into pieces and are delivered as output of small iterations or sprint. In an Agile environment the customer will realize the business value after few iterations. Remember Agile changes the way in which the product is shipped to the market and it does not do any harm in requirements flow.
It is better to keep a short iteration like 2 weeks. I guess 2 weeks time is enough to develop, test and deliver. Agile project have more transparency to the project. Nothing is hidden. All in the management can see the progress through some kind of visible charts or truth reflectors. Also as said earlier, it will be always quick to respond to market changes and requirements. When some new high level requirement steps in it can always taken into account in a new sprint and things can be developed and delivered quickly. Since Agile is an inspect and adapt methodology, it can be said that Agile if followed properly, it is a methodology which will teach how not to develop a software in a rapidly evolving market.
It is normal most of the scrum team will be able to attain a constant velocity after some or huge lessons from the past sprints. But I was wondering are there ways to make still team better than what they do after a certain period of time. A scrum master can help the team reach its average velocity by removing the impediments and providing all the facilities that the team need. But it seems there is still something that can be done to make the team a HYPERPRODUCTIVE SCRUM TEAM. Based on my understanding by reading papers and attending Scrum Meet up in Bangalore , Certain things need to be done and not to de done to make Super jet Scrum team.