On Agile and Technology Evolving Software Development Processes

 

The Agile Method is a tool and nothing more or less. It is not an opinion, but just a tool. To understand this tool, one must first establish the context. More often then not, tools are meta-solutions to problems. They aid in forming the solution, but are not the solution itself. Since the introduction of technology, we’ve inherited rigid processes from

the material and blue collar world. This came to be known as the Waterfall Method, as technology evolved and the infrastructure it inhabited, too, the processes we use were forced to follow suit. The time it took to complete an iteration loop of going from understanding the problem, to designing a solution and making that solution has been significantly decreased. The advent of faster and interconnected technology has enabled quick and less risky development. Not to mention, that unlike the blue collar work, software and technology lives in the creative and unlimited spaces, hence the vision or goal is constantly moving. What a customer wanted yesterday is not what he wants today. So the iteration loop becoming smaller, is more reflective of our industry, in comparison to others, that have set goals.

To say that Agile is but a quicker version of Waterfall, would do it a great disservice. What has transpired through the reduction of development time, was bringing in the customer as soon as possible. With smaller iterations, now it was possible to repeat the development iteration in the same project. With this drastic change in timeframe, the product is not made in absolute but instead evolutionarily. Every iteration, which would last around two weeks, the customer is brought in for testing, feedback and helping shape the new goals.

Goals are captured in a list, usually called a Backlog. This list is constantly triaged and prioritized to reflect the customers’ evolving needs. Due to the speed of execution, much of the meta-work, namely: documentation, designs and other forms of software scaffolding is kept at a minimum. In this minimum the tasks that populate the Backlog, are called User Stories. They contain a description, acceptance criteria, and sub-tasks required to materialize said User Story.

To aid in building these User Stories, Agile stimulates imagination through narration. In order to build a good narrative, we need characters and stories. Queue Personas and Scenarios. As their name indicates, an Agile team will create Personas that will be most interested in the product. These Personas are used throughout development in order to indirectly encourage the team to empathize with potential customers. This has many benefits, of which, it makes communicating with the marketing and design teams easier, as they too use similar techniques to help design products and find target markets. Scenarios force the team to create context through a story where the product is used. The latter two, help breath life into the idea and from there, the team can create User Stories to fill the Backlog.

Visual techniques are of great aid too. Nothing too fancy in order to not slow the Agility of it all. Wireframes, Storyboards and UI Mockups are a few examples of quick but certainly not dirty ways to help establish the vision.

Talking about Vision, it is often used in a brief paragraph in order to guide the project. It isn’t concrete or precise, but gives a high level narrative arc to the teams’ goal. In fact, it should be high level in order to encapsulate the evolving end goal.

They say that the best secret to creativity is constraint. It is critical that the team agrees on the Scope of the project. Knowing what not to do limits the creative space, and hence increases focus on depth rather then breadth. As the old saying goes, “You can’t do everything”. Since were on the topic of limits, it isn’t also important to know, understand and deal with risks (aka: risk mitigation).

There is a form of estimation to Agile, which uses an abstract variable usually called “effort points”. This User Story grading system, allows estimation as well as postmortem analysis on a team’s rate of work also known as Velocity. As a team collects iterations or Sprints they become more aware of their Velocity. This awareness betters estimation of Velocity for upcoming Sprints.