Software Engineering for Humans #3

Software Engineering for Humans #3

 

The number 3 is said to be the perfect number, and today we mark our third instalment of this series, in which I explain to you, dear reader, what Software Engineering is.

In the previous blog, I broke down the agile model and what exactly makes it so special, but since it’s so terribly important and widely used, I, as promised, have dedicated this entire blog about it. Get excited!

 

History

Before agile came into existence, the software industry used to follow the waterfall approach, which as I explained on our last blog, was extremely problematic due to reasons I won’t delve into again. Now, this caused a bunch of men in suits who work industries to be understandably very frustrated over the fact that project management was one hell of a nightmare at that point. Among these men in suits was a guy named Jon Kern, he was so frustrated that he threw his hands up in exasperation and thought to himself, “There’s gotta be something better than this!”.

So, in the early 2000s, our man Jon formed a group of 17 software developers and started meeting in Oregon to brainstorm the idea of speeding up software development in an efficient way, and that was the first big step in our story.

 

The Agile Manifesto

Remember that creepy website I linked to last time? Yeah.

After that Oregon meeting, Jon and his band met again in Utah in 2001. During this meeting, they further discussed how to develop a stronger solution for the development problems they’ve been encountering and within days, they came up with what is now called, “the agile manifesto”.

The Agile manifesto has four core values:

 

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

 

And they didn’t just stop there, they also added some principles:

 

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
4. Businesspeople and developers must work together daily throughout the project
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
9. Continuous attention to technical excellence and good design enhances agility
10. Simplicity–the art of maximizing the amount of work not done–is essential
11. The best architectures, requirements, and designs emerge from self-organizing teams
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

 

Expansion

After their string of successful meetings, our band decided to form an alliance to promote their values (not a cult) and they aptly named it, “Agile Alliance”, a non-profit organization with the goal to help teams adopt the Agile methodology by providing resources.

Throughout the 2000s, some contributions have been made to the methodology by some software development groups. Including, “role-feature reason” – a template used by product owners to create user stories – and “retrospective” – a meeting that’s held at the end of an iteration in Agile software development – and many more.

The Agile Alliance has since expanded its presence over the years.

 

Now that the history is out of the way, let me tell you what REALLY happens in the industry.

 

Why do we (Tech Hive) love Agile?

 

For quite a couple of reasons actually…

1. Let’s say you’re developing a Software product that could take YEARS (as per your client’s request) so, now you, your client, and your team look like this one SpongeBob meme with his brain on fire and a bunch of small SpongeBobs freaking out inside of it.
   (GIF for humor purposes: https://c.tenor.com/iDYg-7xD7M4AAAAC/burning-office-spongebob.gif). Chaotic, right? Well, fear not!

   Agile allows your developers to work in an iterative manner, but what would happen if you were not to use Agile? Your launch date would be a nightmare to set! That would completely jeopardize the market opportunities, but with the iterative approach, a primitive version of the product in real life or a minimum viable product will be available for review within a month at the latest. This will not only keep your client satisfied and happy, but it also allows you to receive user feedback that the team can use to make changes accordingly.

 

2. In this scenario, you own a crystal ball. You use the crystal ball to get predictions on what features to put in your Software product that would satisfy your customers. Cool right? So, you release your product thinking that your plan is infallible only to find out that humans are actually very unpredictable and the reviews on your product come out mediocre. “How did I get it so wrong?”, you ask yourself one night as you smash your useless crystal ball into the floor. What you needed to consider in this scenario is user feedback. Feedback could be extremely drastic that it revamps your entire application or extremely miniscule, but it’s very important to your customer satisfaction. Agile allows you to get feedback via its iterative approach. In each iteration, you factor-in the user feedback and with that, you end up with a better product. You could be asking yourself right now, “Hey, this could happen with the client too!”, and yeah you’re right. The whole point of the iterative approach is that it improves upon itself and the client’s feedback is the main driving force apart from the customer feedback.

 

Another instalment of our blog has been concluded, dear reader, and we only got ONE blog left in this series. Make sure you bring some tissues next time, its farewell.