Agile
Tell me, how many consecutive years did you fail to accomplish your New Year’s promises and long-term plans for the next year? Long-term plans are just a way for human beings to feel less uncomfortable with the unknown. We kind of get the feeling we have control over stuff when we have a long-term plan.
The point is that all of the sudden, on January 15th, when you think you are in control of your life, you receive an email with a job offer paying twice more than your current job or you simply get fired.
What we don’t immediately realize is that a job offer paying twice more sometimes is not good (the job and people there are boring, they don’t care for development best practices, the environment does not encourage communication, and so on) and sometimes getting fired is not bad (your next job can be much better). This happens because human beings tend to react without thinking first. Very often we caught ourselves being thankful for something that initially we thought it would be bad.
In the software development context, the same happens when the client asks for a change in something that was already delivered or even is being developed. Sometimes, our first reaction is to become upset and think “why didn’t they think about it before asking? These guys don’t know what they want!”. However, after a while we did realize that the change is actually for the best and it will increase a lot of value to the whole product; the client will be more satisfied and the end users will benefit. The second Agile principle states: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Agile is not about being faster. It is about being able to adapt well to new situations. Imagine that you are in a building on fire. You can either be really fast and escape from it by throwing yourself out through the window or you can find the fire escape and escape from it in safety. Option one is faster, option two is agile.
Agile Methodologies for Software Development such as Scrum and Extreme Programming are based on the Agile Manifesto, which states the following:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Also, let’s check the Twelve Principles of Agile Software:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Scrum
Developing software in a non-iterative fashion is probably the reason why a lot of good projects with highly-skilled people have failed over the past years.
As I mentioned, the whole problem with this approach is that when you set up a long-term plan and strictly follow it, like the Waterfall model, you lose the ability of making changes and adapting the product to what the client really needs, which most of the times happens to be figured out only during the project development phase rather than the in the very first talks to the client.
In order to avoid this issue, the current recommended way for approaching most of the software projects is by iterations, that is, shorter periods of time (typically weeks) where the whole process happens (planning, development, tests, release, client feedback). This not only allows the client to start using the software earlier (adding value to his business) but also gives the opportunity for him to provide faster feedback, ask for changes earlier, change feature priorities, and so on.
A very well-known framework for software management that implements this idea is called Scrum. It has been successfully used along many years in companies all around the world.
Of course that there are many other factors that influence the success of a software project such as the code quality, the release process, the application architecture, and so on. Scrum does not define software engineering best practices, it is all about managing the software project. There is another Agile Methodology called Extreme Programming (XP) that approaches Pair Programming, Test Driven Development, Refactoring, Simple Design, Continuous Integration, and others software engineering practices. Software development teams often use Scrum and XP together to take advantage of both worlds.
Please download my free book sample (Continuous Delivery for Java Apps: Build a CD Pipeline Step by Step Using Kubernetes, Docker, Vagrant, Jenkins, Spring, Maven, and Artifactory) to learn more about Automated Tests (unit, integration, acceptance and performance tests), Continuous Integration, Continuous Delivery, Continuous Deployment, Canary Release, Feature Branch, A/B Tests, Feature Flag and many other relevant concepts.
The Scrum artifacts are:
Product Backlog: a list of items that represent the client “wish list”. These items can be [user stories], bug fixes, non-functional requirements, and so on.
Sprint Backlog: a list of items chosen in the Sprint Planning to be developed in a particular sprint.
Product Increment: the sum of all the product backlog items completed during a sprint, integrated with the work of all previous sprints.
A Scrum Team consists of:
Product Owner: defines and prioritize the items that make up the Product Backlog, answer to business questions that the Development Team might have, etc.
Development Team: make up the people that are actually technical, such as developers, system administrators, database administrators and so on.
Scrum Master: remove possible impediments that might show up for the development team during the development phase, facilitates Scrum Events, etc.
In short, Scrum calls each iteration as a Sprint. A sprint should always have the same duration (it can vary from 1 to 4 weeks) and it’s essentially composed of these events (in the presented order):
Daily Scrum: a quick meeting that takes place every day so that team members can inform what they did yesterday, what they are doing today and if they have any impediments.
Spring Planning: a meeting that takes place at the beginning of each sprint where the Scrum Team define which items from the Spring Backlog should be developed in the development phase. Basically, the Product Owner picks the most priority items and answer to business doubts that arise. Then, the developers estimate the effort to develop these items, optionally using the Planning Poker, and based on the average points the team is used to deliver in every Sprint, the Product Owner decides whether he puts some items back to his Product Backlog or he includes more items to the Sprint Backlog.
Sprint Review: a meeting that involves the Scrum Team and any stakeholder to review the work that was completed and the planned work that was not completed along with a presentation on the completed work (for example, a demo). It is also a time where everyone collaborates on what to do next, so it provides a valuable input to the subsequent Sprint Planning.
Sprint Retrospective: a meeting where the Scrum team discusses what went well in the Sprint, what could be improved and what they will commit to improve in the next Sprint.
This post should give you an overview about Scrum, but I would really encourage you to read the Scrum Guide, which by the way is available in several languages for free.
If you liked this article, don't forget to subscribe :)
Check out my other articles:
Check out my books: https://www.jorgeacetozi.com/books
