Agile Software Development - The Wonder (Teen) years!


What stage is Agile Process of Software Development in its life?

 The Agile Manifesto was created around 2001, so Agile development processes is now entering its teen years. During this year there is probably a lot of dilemma that software developers encounter with this method of software development. Like a teenager that succumb to peer pressure, Agile software methodologies becomes popular based on the most influential advocates of that process.
But by now most software developers ,who tried most of the agile software methodologies, already know what works based on the successes it brought to our practice. Knowing what works means that we also know what doesn't work. Here is the dilemma, there is no one size fits all solution for agility because that is the whole point of agility. You need to react to factors of the current situation to best decide what is going to work.  If I understand Agile development, we start building before the outcome is fully understood. Adjust our plans as we gain more knowledge and continually collaborate with all of the stakeholders of the system.

YAGNI (You Ain’t Gonna Need It)


But here are some important points that I am realizing after a semester of studying software architecture.

1. Most of the task in an Agile board are user stories (functional requirements), where are the architectural task that will dictate the structure of things to come?

Since most of the user stories are created by the product owner there isn't enough technical architecture task that will support the functional requirements.
Here is a great article about Phillip Kruchten's What is the color of your backlog ? which hits the point of what i am trying to articulate. If i understand Phillip's presentation he is suggesting that an architect should interleave the architectural task with the user stories. The architect can also validate the architecture after every iteration.

2. But isn't it that Software Architecture needs upfront planning? So how would that fit in, in an Agile process? Wouldn't we have made the decisions to early?
After a little bit of digging this article Agile Architecture suggests that an architect can plan for alternate architectures but not commit to it yet until there is enough information that would suggest a choice would best fit the need of system. But THOSE are hard choices to make.

Good thing that the Software Engineering Institute developed a game to teach the point of when to make those choices Hard choices game 
the point of the game is are you going to take shortcuts before you have enough tools? or are you going to gather enough tools before moving on ?

As I have experienced in my current team now, we deliver functionality at a tremendous pace. We always say that "we can refactor it later" but later never comes, and often if the business wanted to add a new feature it often comes with a very high price because we did not need it then. I should introduce my team to the hard choices game










Comments

Popular posts from this blog

OAuth 1.0a Request Signing and Verification - HMAC-SHA1 - HMAC-SHA256

Spark DataFrame - Array[ByteBuffer] - IllegalAurmentException

Gensim Doc2Vec on Spark - a quest to get the right Vector