Agile Zone is brought to you in partnership with:

Aslam has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

Striking a Balance: Let Scrum Die

01.25.2011
| 26140 views |
  • submit to reddit

I live in Cape Town, South Africa.  Apart from the great beaches, a mountain in the middle of the city, good food, and good wine there is a great enthusiasm for agile software development in this town.  It's been around for a while but really started getting all hot and sweaty with the Scrum wave.  I estimate that it's been at least 2 to 3 years since some teams in Cape Town adopted Scrum.  Of course, there are teams adopting Scrum in this community every year.  That's all good, but I'm afraid it's shaping to be just like Table Mountain.

The early years

After the Honeymoon

Regardless of the hyper-performing tagline of Scrum, each team eventually settles down to something with which everyone is comfortable.  The big change that has happened is that of changed behaviour.  Scrum does that - it alters behaviours.  When everyone plays by the rules (i.e. they behave consistently) then you don't have chaos. This is certainly a better position to be.  However, it is also an overly comfortable situation, and I foresee signs of chaos not far away again.  This is what is happening and it is more common than many are willing to admit.  Some are off the table top already.

The plateua

Let me make the Scrumvangelists feel better for a brief moment.  Scrum won't kill you  - directly, but your adoption of Scrum can kill you if you ignore one thing - your code base.  It is a code base out of control that leads to certain death, and Scrum won't be the saviour this time.  Bringing your code base under control is not easy.  It is all about architecture, design and changing your style of development to live the principles that end up characterising good code.  I don't need to tell you what you need to do.  It's been told so many times - TDD, refactoring, continuous delivery, single code base, domain driven design and more(+).  These are the things that you hear from the software craftmanship community. Again, it is not about replacing Scrum for code craftmanship.  It's about striking a balance.

Let Scrum Die

Let's pause at the plateau of complacency for a moment.  This is an interesting place.  We may think we are collaborating but in reality we have just found a way to work together without causing chaos.  I call it co-operation.  It's just keeping chaos under control so that we can make the sprint, again and again and again.  A sure sign of being on the plateau is when we can't get rid of our Scrum master.  When we work the Scrum master out of the system, then the team will need to take on more on it's shoulders.

A major limiting factor to get off the plateau will be the people on the development team.  Hyper-performing teams have talented developers(*) that are able to design and express that design in code without breaking their principles.  A team that is unable to bring a code base under control will compensate by leaning on the process for excessive support. 

Often, the closest person in the process to lean on is the Scrum master.  This is such a subtle situation of dependency because the Scrum master is presented as a necessary part of the process when the state was that of chaos.  Instead, the chaos is under control on the plateau, and so the focus and actions of the team and Scrum master should be re-evaluated.  My view is that a step off the plateau to a higher level can be taken by planning the exit of the Scrum master, there by encouraging the team to take greater responsibility.  This can only be done when there is an earnest effort to bring the code base under control.

Not needed

When Scrum has died

In the journey of dramatic improvements to bring your code base under control, there are few things that you should take notice off.

  • An architecture will emerge that supports the design of the resident parts.  Things fit together sweetly and each part supports the other part in symbiotic relationships.
  • The code base will get smaller and the team will shrink to, perhaps,  just 2 or 3 people.
  • Each developer will take on greater responsibility and will find it difficult to break core principles.  The act of living those principles will result in a values that don't need to be listed on a poster on the wall.
  • The scrum master will become redundant.
  • The product owner will do more by working directly with the developers.
  • The developers will represent the interest of their customers directly.
  • The bottleneck will shift from development to the product owner and eventually the customer.

Why is this necessary?

Partly what motivated this introspection is the crazy blog and tweet war that started with Dan North's take on the software craftmanship manifesto.  I only followed the trail as far as Martin Fowler's view.  Martin and Dan put the customer's derived value from the software as the focal point.  The craftmanship movement puts the code that derives the value as the focal point.  I don't feel comfortable about either.  It is unbalanced. 

So, what will provide an equally powerful balancing force to either of these two focal points?  I think it is the economic viability of the code base.  Earlier, I said that Scrum practioners need to give due attention to bringing the code base under control.  It is simple.  A code base under control is one that is economically viable.  Without an economically viable code base, you have problems bigger than Scrum and craftmanship.

 

Striking the Balance

In the discussion above, the key message is that Scrum should not be the end goal but a means to get somewhere better.  At some point it will outlive it's value and I propose a moment in time when that will happen, and one way to force this (i.e. plan the exit of the Scrum master).  I also describe "talented developers" which, perhaps, feels like a craftmanship-esque thing.  It's not about that at all.  It's about the balance that is achieved when developers will represent the interest of the customer, and the code base is under control (i.e. it is economically viable).  We need to balance the focus on methodology with a focus on the economic viability of the code base.

At the same time, a narrow focus on just clean code and code craftmanship is equally unhealthy. Look at yourself and look at what you create (i.e. the code base).  Also look at the person next to you.  That is vital because the economic viability of the code that you create will affect that other person also, including the entire organisation and its customers.  We equally need to balance the craftmanship with the economic viability of the code base.

There is one area where I don't know of a powerful enough balancing force.  I recently blogged about it in Politics of Software Delivery.  I draw attention to organisational power grabbing that will always result in non-delivery.  I suggest raising the importance of the delivery value.  But I think this force is still too weak to balance the power battle.  I don't know how to fix that one.

Am I being idealistic?  I don't think so.  It’s about pragmatic decisions and the pursuit of freedom.  It’s hippie Scrum.

Footnotes

(+) Jimmy Nilsson reminded me of an article he wrote about TDD, Refactoring, DDD, and why all such things matter.

(*) By talented I mean developers who have the ability to communicate, share, solve problems simply and elegantly, and can sniff out bad design and architecture.  Talented developers are not code monkeys that can churn out code.  Their single differentiating trait is the ability to design well and express that design in code.

References

This article is derived from my following blog posts.

The Politics of Software Delivery

Let Scrum Die

You can't let Scrum Die

Balancing Craftmanship and Methodology

Published at DZone with permission of its author, Aslam Khan.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

George Dinwiddie replied on Wed, 2011/01/26 - 11:46am

I completely agree that there needs to be a balance between customer concerns and technical concerns.  The funny thing is, these are not in opposition to each other.  Craftsmanship done right is in alignment with the customer concerns.  See http://blog.gdinwiddie.com/2011/01/17/trades-crafts-and-certification/ for an illustration of how these are aligned.

I don't know how you, Dan North, and others have come to associate craftsmanship with people who just want to play with code for its own sake.  Certainly Corey Haines is not saying that.  Uncle Bob is not saying that.

Instead, the impetus for craftsmanship comes out of the very danger you point out above.  If we don't write good code, we cannot serve the customer's needs

 -- George

Einar Landre replied on Thu, 2011/01/27 - 4:10pm

Aslam, this was a good post with several important points. I also took my time to read Dan and Martin´s posts and I think they have good points as well. In my experience good solutions or products are the result from three things:

  1. Visionary and bold leadership
  2. Technical excellence
  3. Continuos value creation
Scrum provide rhythm and transparency, and as such it is the workhorse of continuos value creation on the tactical level. Implement these features first within the scope of this release and sprint.

Technical excellence delivery #1 is a manageable code base. Such code base will typically be recognised by a set of common properties, such as modules and classes with high internal cohesion, low external coupling and clear responsibilities. In addition we expect to find an automated build and test system with useful tests as an integral part of the product. If those providing this call them self craftsmen, programmers or architects does not matter to me. What matters is their products high quality code base that serves the product.

Finally, we find visionary and bold leadership that drives innovation. Without this, the product or solution is dead despite the capabilities provided by technical excellence and continuos value creation.
It´s the lack of visionary and bold leadership that leads to employment of 400 unskilled developers to produce a software system.

Take a look at Apple, who combine visionary and bold leadership with technical excellence to produce well crafted products.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.