Agile made easy, the quick Tutorial

In this quick tutorial we’re gonna leave the more technical topics to land into the Agile world, a methodology that allows us as startuppers to quickly adapt to frequent and unpredictable changes in projects’ requirements.

The Agile movement takes origin in 2001 from the experience of some prominent Software Developers who taught us some principles in Software Development which can make life easier for developers, deliver value to customers, build successful software projects. Among them we find Kent Beck, Martin Fowler, Robert C. Martin, Ward Cunningham, as first signatories.

The agile programming team

You can discover the others, as well as the movement’s 12 core principles at the following website: the agile manifesto.

The main innovation regarding Agile is the paradigm shift behind software development: from a waterfall cycle of delivery, we pass to an iterative process of development.

The main point in creating an iterative process is to cut a software projects into small chunks and get continous feedback from customers.

Some of the most common Agile practices are Scrum and Kanban, we have also Scrumban which is, you guessed it, a mixture of the two.

In the Agile process we have three main roles: a Product Owner, some developers, a Scrum Master in the case of Scrum or an Agile Coach for Kanban.

A Product Owner is the main collector of customer’s needs while a Scrum Master works as facilitator between the development team and the Product Owner.

The Agile methodology is inspired by the Toyota Way, a lean production process based on 14 principles, you can read about them on wikipedia, there’s also a good book with the same name, just google it.

And in fact we have some sort of “oriental” ceremonies in the Agile philosophy: like a daily stand-up meeting and a retrospective, something ritual like saying what went wrong the previous day and what can I do today to make it better.

A methodology, tech and a new philosophy

Not surprisingly, one of the four values of the Agile manifesto states: “individuals and interactions over processes and tools”: developers have to talk to each other, no reason for your customers to hide their needs.

The second manifesto’s value is: “working software over comprehensive documentation”, any piece of software should have exahaustive automated tests. Each feature must have a test, and tests have to be created before the feature; following the cycle of: failing test, green, refactor.

Refactoring is the process of modifying code to make it cleaner, simpler and more understandable by other programmers, who are humans, as well as you are.

Wearing the refactoring hat, you cannot change code’s behaviour, even if it is bugged, you will do it in a debugging session.

The core concept here is to create a continous stream of value to customers beacuse any new working feature adds value, even if the day after it gets changed. In that case, value for customers stems from learning from their own mistakes.

While in my opinion the most useful principle is “simplicity”, get the most with the least. If a software is contrived, it does not good its job. It is not maintainable or upgradeable, for example.

In particular with Scrum, we focus on a product (better say a solution) rather than a project, we are fully committed to build something real, through the constant dialog with our customers: we have a product backlog which is split in many features, each feature gets done by a sprint, which is a job iteration. Each iteration has a guessed execution time.

The Kanban lean method has a work in progress time instead of a sprint and it is based on the principle of a pipe, first in first out. You cannot add someting new to the pipe, until the first job inserted in the work in progress pipe gets done.

A widely used tool for managing projects under Agile practices is a tool called Jira from Atlassian, we also have Trello which is completely free.

Another useful tool is Jenkins, for deploying and automating projects, for devops and continous integration.

And that’s all for now: in this lesson we talked about the main Agile values and principles as well as its origins and history, we introduced Scrum and Kanban and we quickly contrasted them.

As you can expect, this is only an intro, and reflects my own views and understanding of the matter. I encourage you to search more on the internet about the terms we’ve introduced so far.

Did you like this post? Please comment here below and share it on your preferred social networks, thank you!

2 thoughts on “Agile made easy, the quick Tutorial

  1. I don’t understand, why not correct a bug while making a refactoring change? What’s the matter…?
    I appreciate a reply.

  2. I’m replying as soon as I can,

    The answer is this:
    while you are refactoring you have to make sure that your code’s behavior is unchanged, because correcting a bug may cause another bug or another, and undesired, change in behavior.

    Instead if you touch one thing at the time you can be certain of your code’s behavior and bugs, through a complete set of automated tests.

    That’s all

Leave a Reply

Give me your opinion, I will be grateful.