​One of the important steps in a retrospective is to identify the root cause of a problem that the team has identified. If we don’t do that, there is a risk that we will spend a lot of time trying to fix superficial symptoms. 5 Why is a technique to help with this.

Example: Solving a dependency problem

Suppose a team identifies that they got blocked by a dependancy. One of the dependent teams didn’t deliver their part of the work, and so the team couldn’t complete their user story.

Now the team has to figure out what action they can take to reduce the likelihood of it reoccuring in the future. Some ideas come up like:

• Follow up more frequently with the team
• Escalate the issue to their manager
• Explain to the team how important this story is
• Escalate the issue to the team’s PO
• … and so on

Here, the team is directly addressing the problem and coming up with possible solutions.

An alternative way using 5 Why technique

Now, suppose instead of solving the dependency issue directly, the team tries to find the root cause. The way to do this is to repeatedly ask “Why did this happen?” for each level of the cause that is uncovered. This is how such a discussion might go:

• What happened?
  • We were blocked because of a dependent team that didn’t complete their part of the work
• Why did this happen?
  • Well, they got the request too late and didn’t have time to stop their other work and complete it
• Why did they get the request so late?
  • We didn’t know about the dependency until we started working on the story
• Why didn’t we know about the dependency?
  • We had not groomed the story before hand
• Why didn’t we groom the story before hand?
  • The PO didn’t have the story ready at that time
• Why didn’t the PO have the story ready?
  • We didn’t have visibility on the plan for the release
• Why didn’t we have visibility on the plan?
  • We didn’t do any release planning

So the root cause here is that the lack of release planning caused a chain of events that eventually led to a dependency blocker problem at the sprint.

The place that this team really needs to concentrate on is on doing a good release planning. If they do this, then it will eventually reduce the blockages due to dependency with other teams.

The goal of the retrospective

The example above shows the difference between tackling issues at the surface level vs solving the root cause. As long as the team focuses on how to manage a mid-sprint dependency, they are not going to solve the issue. They will keep getting this problem again and again in the future, since the root cause is not addressed.

Also, it initially seems as if the solution is outside the scope of the team and there is nothing much that can be done apart from follow up and escalation. But the root cause is actually within the team and can be easily solved by the team themselves.

Finally, once we fix the root cause, we will have much fewer mid-sprint dependencies. The problem simply goes away for 75% of the cases.

A good perspective when tackling these kinds of impediments is:

Stop focussing on how to manage a problem, instead think about how we can prevent the problem from even occuring in the first place

Yesterday, I spoke at Absolute Agile @ Hyderabad. The topic of my talk was 1/3 Agile, or being a change agent. The slides are above, but they don’t make much sense on their own, so here is some explanation for the slides:

• The process itself: stories, feedback, incremental and iterative development…
• Building strong teams: Self organisation, collaboration, continuous improvement…
• Using effective technical practices: TDD, continuous integration, clean code…

Out of these three, most organisations focus a lot on the process, but ignore teams and technical practices. This leads to what I call 1/3 Agile, where we are limited to only a subset of the benefits.

What stop us from building better teams and using better technical practices?

The audience raised a number of obstacles that stop them from having strong teams and tech practices. These obstacles generally fall into three buckets:

• Culture: Some say that their organisation culture is still command and control, and these practices wont work there
• Authority: Some say that they don’t have the authority to make the change, and it must come from senior management
• Skillset: Some say that they would like to do these but don’t know how

What now?

We have two options when faced with these obstacles.

• We can give up and stay with the status quo
• Or we can be a change agent and shape the future

Do we want to be remembered as someone who wanted to do something great, but wasn’t allowed to by the organisation, and in the end you did nothing of note? I hope not and in that case, the other option is to be an active change agent.

Being a change agent

Three vital skills that we need to put to use are:

• Showing leadership
• Building relationships
• Exerting influence

Showing Leadership

• First, leadership doesn’t require authority. Anyone can be a leader–it is not reserved for the executive management. In fact, in 99% of the time, leaders do not have authority. Even in the case of senior management, whom employees assume have the most authority, most of the work is done without authority. This is because a lot of work involves collaboration across many groups and departments and unless you are the CEO, you don’t have authority across the organisation. So we have to dispel with the notion that leadership requires authority.
• Before the transformation, team members may be thinking of their job as showing up, writing some code or testing, collecting a paycheck and going home. They may be thinking the same during the transformation as well. So they may not care about the transformation: agile, waterfall, whatever it is is irrelevant, and you won’t be able to make a strong team if they don’t care. You need to ask them: why are we here? what are we doing? where are we going?
• When it comes to teams, the first step of to take is to communicate a vision. Most of the time, there is a lack of vision. Team members don’t know why they are doing this “agile thing”, apart from the fact that someone, somewhere said that the company is going agile (what does that mean?). It is up to you, as the change agent, to make sure the teams see a vision where strong, self organised teams are creating great software. Without teams buying into this vision, nothing else will bear much fruit.

Building Relationships

• There is a saying: “Role power gives compliance, relationship power gives commitment.” 
• Role power is the authority derived from your role. or designation, in the organisation. When you ask someone to do something from a position of authority, they will comply. Their performance appraisal and paycheck depends on it. But they may not be enthusiastic about it. They might just do the minimum required to make you happy, and then stop.
• There is another source of power in an organisation and that is relationship power. This is the power from having good relationships with other people. When you need something done and you leverage a good relationship, it gets done because the other person believes in you or trusts you. They always have the option to decline, so the fact that they are doing it means they will do it a lot better. They are not doing it just to comply with you.
• Compliance has no lasting power. The moment you look somewhere else, the compliance will stop as well. Commitment is the only way to build long lasting change.
• Building relationships is important. Of course, build relationships with the teams you work with, but also build relationships with others in different places in the organisation.

Exerting Influence

• Al Switzler and the folks at VitalSmarts have a book called Influencer. Their influencing model is based on six leverage points on influencing which fall into 3 categories: Personal, Social, Structural
• Personal is when you try to change a person’s outlook directly
• Social is when you use peers, groups, communities to influence change
• Structural is about changing the system or environment in such a way to influence change

Alignment

• When trying to make a change, it is important to align the message to the person or group. Only when it is aligned is there motivation to make the change.
• For example, if you are trying to transform a team, you need to first understand what each individual wants from their work. Some may want an opportunity to write beautiful code. Others may want the excitement of delivering value to their customers. Some people want work life balance to spend time with their kids. You need to show a vision of how agile can help team members reach these goals in the future. Maybe you will emphasise technical practices to the first person, and rapid incremental delivery to the second one, and sustainable pace to the third one. Of course, you will also explain that this is the end state, it may take many months to get there, but you will get buy in for going on the journey.
• Similarly, when talking to senior managers, you will need to align with their goals. Maybe they care about time to market, or innovation, or delivering quality with high customer satisfaction.
• If there is no alignment, there will be no buy in. If you talk to developers about time to market, they may not care; they may thing that agile is just a way to manipulate them to get more work from them. Same way if you talk to a manager that agile gives work life balance, they may not care; worse, they may think that it is a touchy-feely thing which will reduce the company’s profits.
• Often times, a big problem is that a few people believe in agile and they declare a transformation for the organization. But the vision is only from their point of view. For example, a CEO might tell at an all-hands, that we are adopting agile because we need to deliver faster to the market. But unless the message is translated to benefits for all the other people in the middle — from senior management, middle management, first line management, and team members — then without that no transformation will happen. Maybe something might happen only to comply with the directive, from the role authority of the CEO. But there will be no commitment. It will fizzle out.

Culture

• One of the biggest obstacles that gets highlighted is that of culture. Be it organisational culture, or the Indian culture, it is the most common reason given as to why team practices and technical practices cannot be implemented.
• Some people say that Indian culture is by nature command and control, right from schooling to the society, and the same continues even when people come for work. Hence self organisation cannot work.
• Others say that Indian companies are built as command and control organisation and cannot be changed.
• Still others say that since most Indian companies are service companies with clients abroad, and their USP is about competing on price, hence command and control is required.
• I don’t buy these arguments. There are companies in India where self organised teams are a reality. These companies are hiring the same Indians as everyone else. Hence I don’t buy the argument that self organisation is not possible in India due to culture. There is something more to it.
• Similarly, even in highly command and control organisations, there are certain departments or teams where the culture is different.
• If we look at it, there are three levels of culture: The country culture, the organisation culture, and the team culture. Generally, team culture overrides organisational culture, which overrides country culture. Certainly all the cultures have an impact, for example when dealing with other departments, the organisation culture may play a primary role. And when dealing with relationships, country culture is primary. But at a team level, it is possible to create your own cocoon of culture through leadership and relationship building.
• Lots of people talk about culture as an excuse for not even trying. This is the big mistake we make.

Running your own experiments

• Sometimes the reason given for not trying team and technical practices is that someone in the organisation will not approve of it.
• Actually, the truth in most organisations (especially larger ones) is that as long as the deliveries are being met, generally no one cares what else you do. So, if the team is excited about TDD, they can just go ahead and do it and no one will even notice. Just make sure that the delivery is not getting messed up, and you wont attract any attention to yourself.
• What this means is that it is possible to make incremental changes for the better, slowly over a period of time. Just make sure you don’t tell anyone It is only after you become successful that people will even take notice.
• There is a quote attributed to Grace Hopper: It is easier to ask forgiveness than it is to get permission
• In some organisations, it is better not to ask. Some people are tuned to saying No for anything that they don’t understand. Often you can just go ahead and do your changes and no one will even care. And later if someone questions, then you can show them the benefits you are getting.
• Sometimes, running experiments this way sounds risky and change agents are unwilling to place themselves in a vulnerable spot like this. But a change agent has to do it. Hopefully, you have built relationships with others that will reduce this risk.

Networking

• Do not ignore networking. Take every opportunity to build relationships with others, especially people outside your team or department.
• Social capital is very very important for making change happen.
• In his book Tame The Flow, Steve Tendon contrasts span on control vs sphere of influence.
• Span of control is the number of things that are directly under our control. Usually this is quite small — maybe the team, perhaps a few more things.
• Sphere of influence is the number of things that we have no direct control over, but we can influence. We can get things done in the sphere of influence, but it has to be done via someone else.
• Being able to get things done through other people is the single most important skill for a change agent, and this is only possible through having good, strong relationships.

The power of community

• One person cannot drive a large change. It is vital to build a community to support the change. Find the folks who are supportive, and encourage them.
• Don’t limit the community to a single role. Who knows, maybe there is a director in another department who is interested in agile. Welcome her. Maybe she could influence the director in your department who is lukewarm to agile.
• A healthy community also helps to drive social influence. People are most likely to listen to peers. If their peers are talking about self organisation or technical practices, then they are more inclined to try it than if an external person like you tried to convince them.

So, what is YOUR vision?

• Being a change agent is a unique opportunity to learn and put into use crucial skills that are very important to career success
• Don’t wait for change to miraculously happen from elsewhere
• Don’t wait for the organisation culture to miraculously change before you take the next step with your teams
• Building these skills takes a long time, and lots of practice, so start today!
• Remember, that YOU can make the difference

 

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:

1. ​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.
2. 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.

Reduce distractions

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.

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.

• 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