Scrum meetings! huh.. I’m not interested...

Have we ever felt that scrum meetings are waste? If the answer is yes, then we need to identify the reasons for that.

Why should we attend scrum meetings? Such concerns are often raised within scrum teams.

There are several reasons that scrum team member feel that such meetings are waste of time.

Let us take example of estimations.

A common problem with a new scrum team can be seen during estimations. It is generally observed with teams transform from waterfall to agile. In such teams, veterans dominate the estimation process and their estimates are finalized. Sometimes the situation gets worse where only veterans/specialists estimate and make a commitment. Junior team members are not involved during estimation. One of the reasons is at times most of the team mates of new agile team had worked together in some projects which followed waterfall methodology and accepted that the ways estimations were done and committed, the specialists know better.

While sometime it is taken as granted in new and immature agile teams, which do not have understood the significance of all the ceremonies of agile, some team mates feel that once the decisions have to be made by these specialists and they will be dominating the ceremonies, what is the use of attending such ceremonies?

Annoyed team mates feel that instead of attending these ceremonies they can put this time for some other purpose.

One other reason is being monotonous and not creating enthusiasm in these ceremonies. Ceremonies are for Transparency, Inspection and Adaptation and when due to any reason, no significant outcome or improvement is visible, it creates dullness.

This is true that apart of other responsibilities, facilitator needs to be energetic and innovative. Bringing new scrum games also play great role in such cases where team mates show unwillingness to join the ceremonies due to such dryness.

ScrumMasters/facilitators need to sense such alarming situations well in time and take the appropriate action before it gets late and spoil the team bonding. ScrumMaster also need to encourage all the team mates time to time, not to participate but participate together in scrum ceremonies.

Agility everywhere!

 

Our annual day function was nearing and our CEO announced to make it big.

The HR team and the cultural team were indicated to plan a big bash. Fortunately a few members of the cultural team are part of one of my development team. This team is comparatively new to agile and I got a chance to provide them this opportunity as a scrum game.
The pitch was ready.

·          They had a vision: Vision from our CEO - ‘Let us have a grand Annual function party!’

·          There were stakeholders: CEO, VP, AVP and the guests (of course).

·          There was a Product owner: HR executive

·         and a ScrumMaster:  Most active member of the cultural team who is in my team and a guitarist also.

·         There was a development team: Members from HR department and members from cultural team.

I asked my teammates to plan this function in an agile way.
It started with a product backlog. The scrum team (HR executive as Product owner, Most active member of cultural team as ScrumMaster and members from HR department + members from cultural team as development team) started to put Product backlog items in a spread sheet.  The product backlog started taking shape. It was one sprint with number of tasks.

Product backlog items:

·         Prepare list of guests, hosts

·         Finalize venue

·         Finalize  name & logo to our annual function

·         Decide theme of the party

·         Decide dress code

·         Prepare List of eatables and drinks

·         Send invitations

·         Appreciation for employees for contribution to the society

·         Appreciation for Best employee(s)

·         Prepare list of dance performances – Solo /group

·         Prepare list of Plays/skits

·         Prepare list Songs – Solo /group

·         Other Surprise Events

Sprint Planning:

Team started sprint planning. There was only one sprint planned. 4 weeks time was to go. The shippable product was the ‘Annual Function’. Team started Daily Scrum meetings for 5 minutes after lunch to know what each member has done since yesterday. What they will do today and if anyone faced any impediments. Definition of Done was created for each items of the sprint.
User stories were broken down to tasks such as while preparing guest list, include the food preference.

Sprint Execution:

·         All team mates started their tasks and peers were doing the review. Regular feedbacks were being provided during the peer reviews.

Sprint Review:

·         As a shippable product, the Annual function was celebrated.

·         All stakeholders enjoyed it.

Retrospective:

·         START Doing – More such events.

·         STOP Doing – None

·         CONTINUE Doing – Encourage more participation to make the event more joyous.

Observations:

·         As a self organized team, all team mates were taking up the responsibilities actively and willingly.

·         Regular feedback during cultural activities was very helpful to prepare for the final event.

Mission ahead:
After the success of Annual function, here came the next vision from the CEO – ‘Clean and Green City’.
Product backlog is growing for this vision. Really BIG Mission ahead…..

‘I wish’..My vision!

Friends, today we will have a quick tour of a sprint. This journey will give us an overview of sprint taking place.

This is a fact that any product development starts with a ‘vision’- a clear vision. In scrum the vision need not to be created as a large multi page document. Only a small vision statement is sufficient.

The vision is further converted into stories (epics) in this initial phase. It is not necessary that scrum team will write these epics as scrum team may/may not have been formed at this stage.

This high level road map is created in the form of initial product backlog.

Once the vision gets approved by the stakeholders and scrum team has been formed, a release planning is done to establish the next logical step toward achieving the product goal. A definition of done (DoD) is also established. Product backlog grooming is one of the processes taken up during release planning. Release planning is done generally considering either fixed date (only those features are considered which could be delivered on planned date) or fixed scope (features will be decided first and based on that date is finalized). Team’s velocity is also taken into account.

The very next step is to conduct a story writing workshop. Epics are broken into stories and the stories are estimated in story points. Though Product owner is the primary person to write these stories, however if needed the complete scrum team helps him to write user stories.

A release generally consists of many sprints. Before each sprint a sprint planning is done. This planning takes 4 to 8 hours. The Product owner produces the prioritized product backlog consisting of the estimated PBIs with the defined acceptance criteria. Scrum team selects the stories and this makes the sprint backlog. Sprint backlog contains the break-up of user stories in tasks which is estimated in hours.

Here starts the sprint execution. Daily scrum (also known as daily scrum meeting – timeboxed for 15 minutes) is a part of sprint execution and as name indicates, occurs on daily basis.

When the sprint is about to finish, two most important activities are done. Sprint review and sprint retrospective. Sprint review (Timeboxed 120 minute max for 2 week sprint) is done by the stakeholders to see the completed work and ascertain that the sprint is executed as per the definition of done. Sometimes sprint review is also called sprint demo. However sprint review is more than a demo. It’s an ‘inspect’ activity.

After sprint review the last important activity Sprint retrospective is done (Timeboxed 60- 90 minutes max for 2 week sprint). In this activity the scrum team review all the scrum related activities performed. Team also envisions whether any activity needs improvement? And if yes, how to achieve that? Three important points discussed are:

• What we want to continue doing?
• What we should stop doing?
• What improvement should be done?

Outcome of every sprint is a shippable product increment. The subsequent sprint starts very next day once the current sprint finishes.

Any point needs more insight, please let me know. See you soon!

Kanban or kanban? Chocolates are decisive!

       One of my friend and colleague returned back from USA after a month long official visit. While we were going through the road-map of upcoming projects he had with him and the planning to apply suitable agile practices in these future projects, he cracked a joke on my previous posts on scrum saying, ‘Hey… in all your posts you do promise for at least one topic to be explored in future. This reminds me of television soaps which are generally left incomplete at such a point for the next episode that it becomes necessary to wait till next one.’ He also pointed my out for mentioning kanban as Kanban at places and for my promise of posting something about kanban.

Though I have yet not finished the initial planned posts on scrum but as my friend got me chocolates from USA, I am bound to start some ground up for kanban.

Kanban or kanban?

You must be thinking what sort of question is this? But he was correct* as the practice is called kanban.

* Moreover a few chocolates are still in my pocket so how can I argue on this. Readers, who have not got the chocolates, may follow any of these- kanban or Kanban.

Kanban is made of two Japanese words kan and ban. Kan means visual, and ban means card. kanban approach is based on the principles of Lean. The concept of Kanban came from Toyota, where it was invented as a scheduling system for just-in-time manufacturing in the Toyota Production System.

The most common problems faced during development:

• Wrong estimates
• Inability of delivering tasks on the committed date.
• Unclear priorities.
• Improper distribution of tasks.
• Tasks bombarded from everywhere.

Kanban the savior: Kanban is a very young yet popular methodology based on three principles:

• Visualize
• Limit work in process
• Manage flow

Visualize: First principle of kanban is to make information visible. This can be achieved using electronic kanban board or simply by creating sticky notes representing each task with it’s most current status on a board. The visualization of work-flow on the board becomes apparent to everyone in the team. At times there are a few tasks exists which are often not visible clearly but consumes a lot of time of the team.  Such tasks can easily be captured on the visual board so all team mates including the management also get aware of these tasks and hence can be planned in a better way.

Limit work in process: The second principle of kanban is to limit the WIP. In this principle we  establish a limit for items we will work on at one time. The benefit of taking up a fewer items being worked is that each item will be done more swiftly. Team will focus on the work which is

Manage flow: To manage the flow up-to finish of the task is the third principal of kanban.

This principle indicates to manage flow in a quick and uninterrupted way and keep the work-flow continuously improving.

Kanban methodology started with three principles however recently, David J. Anderson and a few fellows have extended the three basic principles to five properties and six practices. These are known as ‘Core practices’.

As the last chocolate I had, has been finished hence I am taking a short break now. We will continue with kanban in next few posts but before that I have to provide a quick and complete flow of Scrum which is still in pipeline. Most probable this weekend we will see that flow.

Any question on kanban? Please do not hesitate to ask. I will be replying as soon as possible.