Scrum and Structured Freedom

March 5, 2012 at 4:18 pm | Posted in Blogroll, Practice Excellence, Scrum and agile | Leave a comment

Agile manifesto values individuals & interactions, customer collaboration and responding to change. Fulfilling these value statements requires a much higher level of freedom to the individuals and teams as compared to the traditional project management. But this need for freedom must be balanced with the other value statement of working software (of high quality). So it is not absolute freedom but a structured freedom that we need to protect the interests of all stakeholders including teams & individuals.

Let me explain it with an example related to road traffic which all of us are familiar with. There are road dividers to separate traffic in opposite directions, lanes to help cars going at different speeds and signals to avoid getting in each other’s way for the cross traffic. Such structures though appear to restrict our individual freedom; actually help us in our collective freedom. This is fine as long as these structures are well designed keeping in mind the interests of the majority and also assuming that all respect the rules. When this does not happen, our freedom is seriously compromised and we have all sorts of problems. As we can see from this example, we are not really looking for an absolute freedom but rather the right freedom supported by good structures that protect and help us.

As we saw in my recent blog on structured freedom at, the structures form by repeatedly making certain choices over other possible options. This preferential treatment to certain options over others may either be due to compulsion as in case of rules or it could be voluntary when we choose them as a matter of strategy. In either case, the structures provide momentum which greatly facilitates those actions which are aligned with the structures. However, when we try to choose other options, the structures exhibit a strong inertia, which makes change from the status quo quite difficult.

Unfortunately we can’t directly change the structures when we need a course correction. The degree to which the change is resisted depends on whether these structures are hard or soft, rigid or flexible. So the solution available is to change the rules & strategies which led to these structures in the first place, and keep repeating new way of doing things patiently till the existing structures are modified or new ones formed.

Details of these concepts, along with examples, can be found in the blog mentioned above. They are very generic; systems level concepts which can be used in all walks of our lives, including agile software development as I had covered in my talk at the recent Agile India 2012 conference which has a link to my presentation at the conference. For the benefit of those who were not there during the talk, I am sharing below the salient points.

During the talk I showed how the concept of structured freedom can be quite useful to meet the challenges faced by leadership of software organizations in the current decade. The leadership includes both at the team as well as the organization level.

The four success factors for agile movement identified during the 10 year retrospective of agile manifesto provide a good starting point. These success factors are,

  • Demand Technical Excellence
  • Promote Individual Change and Lead Organizational Change
  • Organize Knowledge and Promote Education
  • Maximize Value Creation across the Entire Process

In the context of leadership challenges, these can be interpreted in a variety of ways. However, I took three most prominent ones to illustration application of structured freedom. These were,

Enhanced quality (“Done” within short iterations)

Scrum functions as a container for other techniques, methodologies, and practices. Probably in the enthusiasm of trying something new, the focus was more on the events and practices of Scrum and somewhere the role of Scrum as a container was lost. Added to this is the short duration of iterations or sprints which doesn’t give much time for anything else. A good definition of “Done” can win half the battle. We need to look more closely at the other half of achieving “Done” in short iterations.

Specific roles & responsibilities (Considerably different from traditional product development)

Scrum roles are highly non-intuitive. For ages, we are used to a top-down hierarchical structure of management. In Scrum there are just three roles and nobody reports to each other as such. This is unsettling and leads to risks if not handled well. For the leadership, there is always a fear of losing control. Another aspect which is unusual from traditional project management is the three roles have very specific and clear-cut non-overlapping responsibilities as well as authority.

Self-organizing culture (Supported by self-disciplined teams)

Self-organization which is an essential component of agile success is more a cultural issue than merely a matter of declaring a team to be self-organized. A very common argument I have heard is that we can’t allow self-organization because our teams are not yet mature enough. The obvious conclusion is that we need to continue planning, tracking and managing them as before till they become mature enough. But this is a catch-22 situation. If a team is self-disciplined, then it is easier to help them mature with self-organization.

Then I looked at how rules and strategies can be suitably modified to bring about desired changes to the structures.

Enhanced quality (“Done” within short iterations):

Scrum as a container for best practices

As we saw earlier, Scrum is only a container for other good practices, especially those which are important for quality. A container protects the contents, so should Scrum. This is a good reason to setup suitable org rules in areas like code quality and reviews, continuous integration, test automation, and appropriate documentation. Such rules can vary from organization to organization or even from client to client in case of offshore vendors. However, for a given project, these must be seen as rules with consequences for not following them.

Requirement readiness

This is probably applicable more to the distributed teams, especially involving multiple organizations, where product backlog grooming is given a go-by or done occasionally. In such situations, even the product owner’s availability to the development team when they need it becomes an issue. Out of site; out of mind. Here again, my experience is that agreeing on it as a rule by both the organizations greatly helps.

Change in code – test sequence

We earlier saw that strong beliefs sometimes tend to be treated as rules. Start of testing after completion of coding is one such unwritten rule which exists in many projects coming from non-agile environment. This rule is even more rigorously followed if developers and testers belong to their own hierarchies, sometimes going up to the director level. Here is a good case to convert a rule into strategies. Once this option is open, there are many possibilities. Testing can happen before, during and after the coding in short cycles. Lot more communication between respective developers & testers can take place. Another interesting possibility is to redefine the roles of developers and testers. Testers who are good at thinking of different ways to fail can define a rich set of test cases. The developers can carry out such tests immediately after they complete the module level code or integration as the case may be. This can drastically cut down the completion of a user story from start to finish till “Done”.

Roles & responsibilities (Clear-cut responsibilities and authority):

Scrum defines the responsibilities and the authority of three roles very clearly and explicitly as we can see in the Scrum guide.

As rules for incumbents

Though the rules are defined quite clearly, it is often that they are either not followed as intended or completely forgotten if inconvenient. It is for the leadership to understand them along with reasons why they are important and to see that they are being followed.

Roles support each other

Apart from the leaders playing their part, it really helps that the three roles help and support each other.

Need strategies for all others

Those who are outside scrum teams may not understand them or may not find convenient to use them. It is here that the leaders need to step in and use the strategy as appropriate to the situation.

Self-organizing Culture (Needs self-disciplined Teams):

The biggest bottleneck to self-organization is the belief that only mature teams can be self-organizing. As seen earlier, such beliefs tend to become rules for those involved.

“Can do” belief

It is necessary to change this rule to the belief that it is possible to create self-organizing teams with not yet mature individuals.

Progressive empowerment

The way to do it is to approach it step by step. First take care of bringing disciple through rules. Repeated use can help create self-discipline. Once it is in place, slowly more and more work is transferred and letting them make small failures.

Collaborate, learn and share

In this learning process from small successes and failures, the team as a whole working together in all the important Scrum events greatly helps. So this should be implemented as a rule. However, each person has his own way of learning. Such strategies should be shared within and outside the teams.

From the above we can summarize possible actions for the leadership.

At the level of Scrum teams:

The executive leaders need to Work closely with Scrum masters in making suitable changes and ensuring that these are repeated till they become second nature.

Help the teams in achieving self-organization by progressively transferring control as the team members gain greater confidence.

Take care of managing other stakeholders by using strategies appropriate to the situation

At the organizational level:

It is important to observe the existing structures and watch of any signs if they are becoming bottlenecks to smooth and efficient functioning. If so, the rules & strategies currently in use need to be carefully modified and repeated till they lead to the new desired structures

The traditional approach of defining processes is by so called process experts. Another, more agile, approach is to try out various combinations of rules and strategies and see what works in majority of cases of similar nature; then document those as processes and support them till they become accepted way of working.






Leave a Comment »

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Create a free website or blog at
Entries and comments feeds.

%d bloggers like this: