Posted on May 6th, 2014 in Agile by siddharta || No Comment
One of the common complaints about agile is that there are too many ceremonies. The issue isn’t with meetings per-se. The problem is that too many of the meetings are not as productive as they could be. Here are 4 ways to make the meeting more productive:
Keep the ceremony on track
A common cause for an ineffective meeting is that the conversation goes into tangential topics and the meeting outcome is never met. This leads to another meeting to be scheduled, or delays in the work. Here are some examples:
- In a grooming meeting, the conversation goes away from preparing upcoming stories. The PO and team instead start discussing the status of current stories. By the end of the meeting, none of the stories are groomed. When the next planning meeting came around many stories will not be in a position to be picked up.
- In a daily standup, the discussion goes towards solving one particular blocker. The whole team is standing and getting totally bored while two team members have a long discussion on the blocker.
In all these cases, keeping the ceremony on track would have saved everyone some valuable time. The next time you notice a discussion going on a tangent, put the discussion on the parking lot, or schedule another meeting specifically for that discussion. Then get back on track for the reason you have set up the meeting.
Be sure to run meetings without laptops and phones on silent. The biggest meeting killer is when someone is talking and meantime everyone else is checking email or doing something else. When folks are distracted, the meeting loses its purpose, and further discussions have to take place during the to go over the same ground that was covered in the meeting. When everyone is focused, the meeting can be finished earlier and everyone can get back to work.
Set aside certain slots for scheduling meetings
Software development requires a block of time to concentrate. Having a meeting in the middle can disrupt that time. It is better to have a 60 minute meeting followed by 4 hours of coding time, rather than 2 hours of coding time, then the meeting, followed by another 2 hours of time. Agile ceremonies happen on a regular schedule, so you can easily schedule them in the most convenient time. For example, some teams schedule all their ceremonies in the morning and keep the afternoons free of meetings. This is more productive than randomly having meetings throughout the day.
Ensure that the ceremony pre-requisites are met
A few days before the ceremony the Scrummaster or team should make a quick check that everything is ready. For instance, the stories should be well formed, and ready for discussion. If they are missing acceptance criteria or there are outstanding decisions to be taken, then the story should be de-prioritised from the discussion. Otherwise you will waste time in the ceremony going off track. Similarly, if some architecture review was identified in the grooming, then ensure it happens before the meeting.
Posted on April 16th, 2014 in Agile by siddharta || No Comment
Here is a pattern that is commonly seen in teams — the scrummaster acting as the point of contact for a team. What does that mean?
- When the PO has a question, they ask it to the SM and expect them to relay it to the team. When the team member has a question to the PO, they tell the scrummaster and expect them to ask it to the PO.
- In conference calls, the SM is the one who does most of the talking. If there is a question from a team member, they ask the SM and the SM (who is near the phone) asks it in on the call on their behalf. Likewise, if there is a question from the other end, then SM relays the question to the team or team member, then relays their answer back on the call.
- The SM represents the team when attending the Scrum of Scrums, status report calls, calls with management and others such meetings
There might have been many other situations where you might have seen the SM acting as a proxy or point of contact between the team and someone else.
Being a scrummaster does not mean being a proxy for the team.
A good scrummaster will enable the team to self-manage. That means, leaving the team to take charge, and stepping into the background. So:
- If the PO has a question, they either ask the team directly, or if they are not colocated, then send it to the team distribution list so that any one of the team members can respond. If a team member has a question to the PO, they ask directly to the PO without routing it through the SM.
- In a call, the SM steps back and the team interacts directly with whoever is on the other side
- Send a team member to represent the team for Scrum of Scrums or management calls. Teams can even rotate the team member they send. In a good team, every team memberknows where the team is, where they are going and can represent the team.
The SM only steps in if there is some dysfunction happening, for example a discussion goes off topic and needs to be taken offline or put on a parking lot.
So what do you do if you are a Scrummaster and other people assume that you are the point of contact? At that point, you need to gently remove yourself from the middle.
- If a team member has a question to the PO, encourage them to email / lync / skype the PO directly. They can update the team after their discussion (if the team members sit together) or at the standup
- If someone asks you a question directly, forward it to the team DL and encourage them to send future questions there next time. Then leave it to the team to answer the question. Step in only if no one is answering it assuming that someone else will do it (the whole team sitting together helps).
- During calls, make sure you are not sitting anywhere near the phone Similarly, in meetings, take an inconspicuous position near the corner of the room or sit on the floor.
- Rotate between team members for representing the team in reporting calls with management or others
In some teams, the SM is also an engineer on the team. In such cases, the SM has to carefully switch between playing a facilitator role and a team member role. You may have to switch hats multiple times. Remember which hat you are wearing and play the role accordingly.
The goal of the Scrummaster is not to manage the team, but to help the team become self-managed
Posted on January 28th, 2014 in Agile, Kanban, Scrum by siddharta || 1 Comment
When teams start doing agile, one of the first impediments they usually run into is the inability to complete stories quickly. In Scrum that can result in stories spilling over sprint boundaries, whereas in Kanban in results in really long cycle times.
Do you have this problem?
Here are five ways to complete user stories faster
- Have smaller user stories: When you have smaller stories, developers finish stories earlier and testers can start testing them early. This way, testers dont get a big story to test later on. So, think hard about whether the stories can be further decomposed into smaller stories.
- Multiple developers work on the same user story: Don’t assume that only one person can work on a story. Look at your tasks and see if different developers can work on different tasks of the same story, so that it will be completed earlier. Also, dont assume that only a single person should work on a task. Sometimes it is helpful to pair multiple team members together to work on a single task.
- Automate some functional tests: When developers work on the development, testers can write automated functional test scripts during that time. Once development is complete, the actual testing time is reduced because you can just run the automated tests instead of manually executing each test case. As a bonus, over time you the improve the automated regression suite.
- Multi-skilling: Testers helping with simple coding tasks, and developers helping with test case execution are two ways multi-skilled teams work better. See how you can bring this capability in your teams.
- Co-located teams: You will be surprised how much time can be lost in communication between team members who are not co-located. Emails going back and forth over a period of two or three days is a big waste of time. By seating the developers and testers next to each other, a lot of wasted communication time is saved, and more can be completed.
Not all the above approaches are suitable for every team or every situation. The team needs to look at all available options and decide which is the best way for them.
Posted on August 6th, 2013 in Kanban, Lean by siddharta || No Comment
I recently did a short mini-webinar for SolutionsIQ on the topic of slowing down to speed up. The webinar is based on the systems thinking principle that local optimisations can sometimes be bad for the global system.
Often times in agile, we look for process improvement at the delivery team only. This is fine in the early stages when the team is the bottleneck in the process, but after about 8-12 months they stop being the bottleneck. At that point, it makes more sense to look at the rest of the system, rather than focusing on the delivery team alone.
See the video recording of the webinar below:
Posted on June 23rd, 2013 in Infographic, Kanban by Divya Sornaraja || 25 Comments