InfoQ

InfoQ

Article

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

The Hidden Face of Agile

Posted by Mukund Srinivasan on Jun 23, 2009

Sections
Process & Practices,
Architecture & Design
Topics
Stories & Case Studies ,
Teamwork ,
Team Collaboration ,
Agile
Tags
Trust

Before the storm

When we, as an organization, were first exposed to Scrum a year ago, our first inclination was to believe that it was one of those areas that management wanted to see addressed, because there needed to be change in the way engineering functioned, and soon at that. Back then, it felt like it didn't have to be "Agile" that cut the bill; it could just have been anything that was different to what we were doing, and it would have gotten washed in the then popular "sweeping winds of change".

RelatedVendorContent

Case Study: IBM's Agile Transformation

Agility at scale, become as agile as you can be

SCM best practices for multiple processes, releases & distributed teams

A Guide to Branching and Merging Patterns

The Agile Tester

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

Winds of Change

Fast forward a year and there are numerous benefits we have reaped as an organization, due to the transformation we underwent, thanks in no small part to our then new VP of engineering who introduced us to Scrum. Putting a stake in the ground this moment, a few of the touted benefits we can claim points (see I can even speak the lingo!) for:

  • Better, coordinated reaction to the ever changing market place and the demands they place on the business - relevant more than ever in the current economic tsunami we are in.
  • Obstacles hitting us in the face right from the get go - we cannot be grateful for this enough, for there are obstacles no matter what process you follow and the earlier you get past them, the better it is for everyone.
  • Prioritized and focused execution (period). Ask any manager that's worth his/her salt and the quote "the plan is the plan until it changes" will seem like the back of the hand. Can't find fault with the statement per se but putting accountability and responsibility together in the hands of the Product Owner was the best thing that ever happened to us as an organization.
  • Self-managing teams: what better way to drive home the point of taking ownership than having to ask teams to make their own commitments and stand up to it?

Not that any of this wasn't happening in any of our teams a year ago; it is the synergistic nature of all these points coming together in every single team that was missing then. Lest this article becomes another "driving" home point about the benefits of Agile, I wish to quickly move away - there are far more qualified experts to drive home that point if the results of Agile transformations don't speak for themselves already.

The Hidden Face

My inclination to pen this note stemmed not from the visible changes I have seen in our teams, but rather from the intangibles; the hidden side of the transformation, so to speak - the changes in perceived values of interpersonal relationships, the enhanced necessity for trust, the soon-obvious need for enhancing cross-site communication inefficiencies, etc that I wish to delve upon. In all the thousands of links I have clicked and forwarded in the past year, the white papers in every document kind and format you can imagine that have been shared, hardly not even 5% (or one-twentieth) of that have touched upon the point I am noticing as a by-product of our transformation. I don't remember where in that sea of information I found it, but I vividly remember a quote from last year - "Truthfulness is the foundation of Agile". A colleague later pointed me to a link that expressed this in better words.

By no means am I implying that a whole bunch of my colleagues and friends were dishonest and have become otherwise overnight; far from it - in fact, I am yet to encounter a professional situation wherein I have sufficient proof of anyone ever being dishonest intentionally. Rather, in my humble opinion, it is the circumstances that make or break an individual's reaction to a situation when it demands total truthfulness in all forms of it. Before I am branded naïve - the dishonesty as I understand it does not have any shades of grey whatsoever; you are either ethical or not; honest or dishonest, period. The weeds that don't conform to the ethical standards we have as a society possibly disappear from our radars over time as we humans tend to have a scenario of wanting to remember only pleasant thoughts and it applies to people as well.

Back to mainline, the honesty and truthfulness I am referring to is as abstract a concept as it can get. It is the commitment we make to ourselves and to those around us that makes our conscience clear. As a simple example, I wouldn't have hesitated twice if a couple of years ago, I was asked to take a swag estimate at what it would take to build something new, in my then role as an architect. Now, nothing's changed as far as my engineering biased estimating abilities go; it is the added sense of "am I committing something on my team members' behalf that I am doubly sure of?" For when I see a team member doing whatever it takes to live up to the commitment they made to the team, I want to hold my end of the bargain and wouldn't want to make a commitment that he/she cannot live up to. If you see closely, the lines are blurred and the roles are merged - team dynamics win! Before our Agile transformation, we could have made a commitment to those around us, but for various reasons outside the purview of those immediate actions, not have had to deal with it then and there or subsequently have to face the reactions emanating from those direct actions. With Agile and Scrum, because obstacles stare at us in the face and because we want to be part of the crowd we live in (herd mentality?), we are consciously looking to make a commitment - one that we can live up to, so as to not be isolated from others around us.

Application to daily lives

Think about it for a moment - if in your own ecosystem, every single individual speaks his mind about committing to something and owns up to it, honestly, it puts that extra bit of what's commonly known as "peer pressure" on everyone else to live up to one's own commitment. I am confident enough in the thought that given the control over our sphere of influence, we can control our destinies - implying there shouldn't be excuses to commitments we make to ourselves. Somewhere I read an article that our personal lives are just an extension of our work lives considering the amount of time we spend at work. For all my abilities to search on Google or any other search engine for that matter, I could not come up with an article that correlated how Agile development methodologies at one's workplace translated to a better quality of life outside work. But just cogitating on that thought a bit - if we were to adopt the same principles to outside of work, in our personal lives as well, can there be a better lesson we can convey to our children? Legacies are not made or created by monumental single actions, in today's world, as they were say in the era of wars a few centuries ago that created possibilities for overnight heroes. Today our legacy is not about what heroic actions or deeds we performed today, but actually what contributions one has made in his / her career that spans 2-3 decades.

If it means that the effect of a transformation in one's career has a direct correlation to a positive impact on society, then that needs to be celebrated. If we have an opportunity to set an example in our lives and thereby create our legacies (in our own small ways) thanks to the not so obvious faces of Agile, then I am all for it - therein, my friends, lies the hidden face of Agile.

Yet, there is one aspect of Agile doesn't apply to our daily lives - "life is a marathon, not a sprint"!!

  • This article is part of a featured topic series on Agile
Nicely done. by alan myers Posted
Good Job by Gustavo Veliz Posted
Conceptual Source by travis birch Posted
Great Article by Murali S Posted
  1. Back to top

    Nicely done.

    by alan myers

    Good perspective.
    I'll share this!

  2. Back to top

    Good Job

    by Gustavo Veliz

    you expressed a important aspect about agile philosophy. Ill share this too

  3. Back to top

    Conceptual Source

    by travis birch

    I was really excited to read you latest post on truthfulness. I happen to work with Mishkin Berteig at Berteig Consulting and am aware of the original source of the concept of truthfulness as the foundation of Agile. In the writings of the Baha'i Faith (bahai.org) it is stated: "Truthfulness is the foundation of all the virtues of the world of humanity. Without truthfulness, progress and success... are impossible..." (reference.bahai.org/en/t/ab/TAB/tab-497.html#pg459).

    Agile is about "uncovering better ways" of doing work. In order to uncover better ways, we must utilize certain human capabilities (i.e. virtues) such as imagination, thought, creativity, search, wisdom, tact, insight, foresight, etc. The foundation of all of these is truthfulness. Therefore the foundation of Agile is also truthfulness.

  4. Back to top

    Great Article

    by Murali S

    "Agile development methodologies at one's workplace translated to a better quality of life outside work "
    This is true. I am working on an Agile project from last 2 years and I realize that I have become a better human being- thought process has changed.

  5. "life is a marathon, not a sprint >>"
    I think life is also made up of sprints. The only difference here is that the sprints are of 5-6 years long.So plan it accordingly.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.