What constitutes “minimally viable agile”?

Posted on June 25th, 2014 in Agile by siddharta || No Comment

There is an interesting discussion on LinkedIn on “minimally viable agile“. What is the bare minimum that a team should do in order to be considered agile? Should a team do standups to be agile? What if they don’t do standups, does that mean they are not agile, or is it possible to be agile without it? What does it even mean “to be agile”?

This is a topic that comes up every so often without fail. Here are some approaches that are inevitably put forth. I have ordered it in terms of my personal preference, from my least preferred approach to my favourite.

It’s agile if it includes these practices

This school of thought professes a set of practices, like standups or retrospectives, which need to be followed in order to be agile. So, if you aren’t doing retrospectives, then you aren’t agile. The problem with this approach is twofold. First, there are many different agile processes–Scrum, XP, Kanban, FDD, Crystal–and each has its own set of practices, with only very small overlap. So it is hard to nail down a set of practices which MUST be followed. Secondly, there are so many teams that follow ALL the practices, but someone who observes them would not call them agile. Maybe they are co-located, but they dont talk much. Maybe they are developing software incrementally, but rarely release to production and get user feedback.

It’s agile if it follows the manifesto

Another school of though is that it’s not agile if it doesn’t follow the manifesto. Individuals over Process, etc. But there are problems with this approach because it is just too vague. How do you really tell if a team is following the manifesto? The manifesto is a very high level vision statement rather than something actionable where you can go and say, “Yes, this team is following the manifesto”. It can also lead to strange situations, for example a team doing cowboy coding, because the team members just feel like it, would be better aligned to the letter of the manifesto. After all, it is the individuals who have decided to dump the process. But it is hard to think of such a team as being setup for success.

The 7 properties of successful projects

If a set of practices is too constricting, and the manifesto is too vague, then what is the solution?

My guide has been Alistair Cockburn’s excellent 7 properties of  successful projects. Crystal Clear was one of the very first books I read and it made a very strong impression on me, and I’ve been carrying this list around ever since. Unlike other though leaders who are mostly working from anecdotal experience, Alistair’s list comes from specific research into successful projects. Based on this research he identified 4 core properties that most successful projects possess, and 3 additional properties that improve the chance of success, but are not totally critical (ie, it is harder, but possible, to succeed without them).

Here are the 7 properties (top four are the core properties):

  • Frequent Delivery: Do you deliver software to production, at least once a quarter?
  • Reflective Improvement: Do you take time to look back at how you are doing, and where you can improve?
  • Osmotic Communication: Does it take less than an hour to get the answer you are looking for?
  • Personal Safety: Can you give people bad news?
  • Focus: Does the team know what their top priorities are?
  • Easy access to expert users: Does it take less than three days to get an answer from an expert who understands the customer?
  • Strong technical environment: Does the team have automated tests, frequent integration, etc

There are two things that I love about this list.

First, they are outcome based. Take Osmotic Communication for example. Maybe one team might want to make it happen via colocation. Another team might be distributed, but ask all the team members to be online on team chat. Both practices can deliver on the goal: Does it take less than an hour to get the answer you are looking for? Conversely, there may be a team where everyone is sitting together, but they work in isolation without talking. If a team member has a problem, he tries to solve it himself for days without asking anyone. Such a team might be colocated, but they don’t have osmotic communication.

The second thing I love is that it is easy to evaluate. It is not a pie in the sky vision statement. It is specific, and you can easily go to a team and say whether the delivery frequency is good or not, whether communication channels are good or not, etc. It is a great way to figure out where a team stands on the path to agility.

Best of all, it is practice agnostic. This list is applicable whether the team does Kanban, or Scrum, or some custom hybrid.

Identifying root causes using the 5 Why technique

Posted on June 10th, 2014 in Uncategorized by siddharta || 2 Comments

​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

Being a change agent

Posted on May 25th, 2014 in Agile by siddharta || No Comment

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:

What does it take to be agile?

There are three areas to focus on to improve agility:

  • 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.

Continue reading ‘Being a change agent’ »

Four ways to make agile ceremonies more productive

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:

  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.

Scrummaster is not a proxy

Posted on April 16th, 2014 in Agile by siddharta || 2 Comments

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 :)

« Previous Entries