The Second Noble Truth of Software Development

We previously talked about my lack of mindfulness while in meditation and the similarities of Buddhist wisdom to software development challenges.  I am continuing my work on a wandering mind (will most likely be a lifelong journey) but do recognize how you can put this wisdom into everyday practice including that of software development.

Buddha’s second noble truth states that ‘The origin of suffering is attachment’.  In a nutshell,  this basically points us to the recognition that suffering results from an attachment to transient things and the ignorance thereof.  Transient things by nature are impermanent which Buddha tells us all things are.  Ignorance comes from the lack of understanding of how our mind is attached to these impermanent things.  This can be often demonstrated through the actions of craving or clinging.

In software development terms, this can easily be demonstrated by what happens when too many requirements are presented for a product.  The ‘craving’ for too many features in one release can lead to suffering for all on the team, including the customer themselves.  Too many requirements in one release can lead to lengthy release iterations.   It can also lead to distracted developers from the looming nature of what lies ahead which will often take them into pondering tomorrow more than they are thinking about what needs to be done today.  The drawback from this approach comes from  the transient nature of our world and how fast things change.  Often, too much time is spent pondering requirements that will never come to release or used by customers.  Shorter iterations can help address the ‘now’ mentality, meaning state of the world as it is today and lead to higher product satisfaction (i.e. less suffering).

This is one of the reasons I like Kanban as an agile approach.  By keeping the team focused on only a few features at a time  (limit work in progress) and deciding as you go when the product is releasable as a product owner,  you have the ability to adapt to this transient world more in harmony with its true nature.  The team stays focused on what needs to get done ‘now’ versus designing the for a changing future.

Next we will discuss the similarities between the third noble truth which states that ‘The cessation of suffering is attainable’  and my version which states that ‘The cessation of suffering is attainable through Kanban’.

The Four Noble Truth’s of Software Development

You may recognize the similarity here to that of most Buddhist practice. I would never want to plagiarize Buddha so must give full credit where credit is due.  I was in a meditation class the other day and the teacher was talking about the suffering caused by the nature of wanting.  Now I recognize the irony here from a wandering mind while in meditation but I immediately connected what she was talking about to the suffering also visible in software development.  For the sake of the meditation practice I did file the thought away for another day and went back to my oms.  So here I am rethinking the concept but this time sitting at a desk and not on a mat.

Let’s start with the first noble truth which states ‘Life means Suffering’.  My summarization of this noble truth is simply that we are never able to keep permanently what we strive for.  In technical terms this is best translated to mean processes continuously change.  Even processes that are good one day will inevitably become bad another so you should anticipate this constant change.

Let’s break this analogy down a little further for the sake of the skeptical mind (which could also translate to someone who denies that change is inevitable).    The world around us is constantly changing so therefore our processes must also change to adapt to the need at the time.  Suffering manifests within those individuals that do not acknowledge this truth and resist a constantly evolving process.

The beauty of agile methodology in respect to this noble truth comes inherently through the usage of sprint retrospectives.  If used properly,  the positives and delta’s are adapted into the agile process so that it is constantly evolving.  The happy agilist embraces this constant change and also recognizes that the good times are also fleeting moments.  The changing world will throw challenges into your process and you should simply acknowledge the trying times as the sign to evolve.  Don’t suffer from these challenges but simply recognize them as part of the ebb and flow that is this world then retrospect on how to make tomorrow another ‘happy’ day.

Next we will discuss the similarities between the second noble truth which states that ‘The origin of suffering is attachment’  and my version which states that the origin of product suffering is too many requirements.

Lessons learned from an agile scrum shop - Why Agile Business Analysts, con't.

An interesting statement came the other day from an agilest with the Mile High Denver conference.  They discounted the use of BA’s in an agile shop as something that only a bureaucratic company would do and not many mainstream agile shops.  I found that compelling and would love to hear from other development shops as to their experience on this.

My thoughts are that every development shop has someone that is filling the role of the business analyst in their scrum.  The agile process allows for scrum team members to rise to the occasion and fill the void that is presented which is the beauty of agile.   My challenge to this concept comes not from a bureaucratic company but one that has an ever increasing volume of products to support.    It is easy to say that those experienced can rise to the role of BA when necessary until you have spread those key resources (lead engineers, lead QA Engineers,  Product Owners, etc.) too thin for all the active products going simultaneous.  Not all junior team members have mastered the concept of Business Analysis and are often trained through pairing with lead team members.

Having a dedicated BA that serves as part of the scrum team can greatly facilitate an increase in overall scrum team velocity.  This came as a result of developers having very well vetted and designed requirements at the start of a sprint.  We found that tasking these BA resources as part of the scrum team can also facilitate the knowledge transfer amongst the entire team.  Similar to the scrum master or product owner roles, we find that we can task BA’s at only part capacity (depending on the product) so that they can take on more than one product.

Before we added BA’s to our agile role definitions, we had struggling velocity with some sprints actually accomplishing nothing but requirement vetting by sprints end.  After BA’s came into play, we found sprint velocity and overall customer satisfaction increasing.  I’m not saying we couldn’t have done this in a multiple of ways.  Some shops hire more senior QA engineers that often fill this role or hire only experienced developers.  For a smaller company (we are less than 25 developers), hiring a couple of BA’s to facilitate the agile process was a very cost effective way for us to operate with almost immediate results (within 1 – 2 months ramp up).

Anyone else out there have any similar experience?