en-uspt-br
Written in 2023-08-23 Modified at 2023-08-25

Project Lifecycle - Agile Framework

Disclaimer

Most of the things I’ve written are in free form. Of course, I researched and have my sources linked in the text as it goes but take my writing with a grain of salt: I am not a computer scientist nor a great researcher. When in doubt, always check the sources. Thanks and on with the show!

Index

> Let’s Rewind A Little Before Moving Forward

Previously I talked about the Waterfall Project Management and how stiff it was: You had to follow everything by the book or else it fails.

If you haven’t read it, I highly recommend you to do so before continuing, I will heavily lean on it to explain my view of the Agile Framework.

As it is demonstrated, Waterfall cares more about the result and process than the team itself. What this means is that either the team adapts to the project or the team will be changed. While this may work with contractors and other service providers, what happens when the team is part of the project itself?

Well, things may get dicey: people may get fired, the project may delay, people may lose motivation, etc.

Before we suggest improvements, let’s list the problems in Waterfall first:

> Get In Gear: What is Agile?

Agile is a Framework that allows you to embrace changes as they come.

Agile is a collection of tools commonly named framework that allows one to manage a project in a way in which:

That is to say, things on the right have their value but one should prefer the things on the left. Knowledgeable readers may correctly identify that I have taken this straight from the Agile Manifesto and I admit it, because this is THE place to know more about Agile, though in a more Software-oriented approach while I want to take a more generalist one.

> The twelve Commandments Principles of Agile

While Agile is indeed a Framework of practices, there are twelve principles which should always be upheld. They are listed in the order they appear at the Agile Manifesto page and I have also added examples on how to use them.

List of Principles

>> Get Your Priorities Straight

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Let’s forget the software word for a second and change it for items, for a more generic purpose.

This principle focus on the idea that you don't need to deliver the whole product at once but instead partition it into multiple parts and deliver one part at a time.

Doing so will allow both the customer and the team to receive and process feedback easily, as there is more availability to discuss and validate the deliverable.

>> The Wind of Change

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Things change and always will: That is the principle in which the Evolution Theory and the Scientific Method are based upon.

Instead of fighting against it, we should embrace change at every step. What if you planned to build yourself a house for a family of 3 and suddenly you discover that you have a baby coming, would you simply abandon the project and start over or would you try to make changes to it in order to accommodate the new lifestyle?

One could argue it would depend on how far things have progressed and that may be a fair point but I disagree: There is always room for adaptation and that will make for a better result overall.

Going straight for the point in the principle itself: If you own a business of any kind, you will do your best to keep up with the market conditions, even if you have to reinvent your whole business. Isn’t that embracing the change?

>> Keep on Deliverin’

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

The First Principle makes it clear we must deliver items continuously but how much time between each delivery makes it continuous?

The answer to this question really depends on the team as well as the project being worked on. When talking about software there tends to be a preference for 2-week cycles but this is not a hard rule.

Going back to the Waterfall article and the civil construction examples: if your team is capable of finishing a floor foundation in two weeks, that’s your cadence of delivery, at least for this phase of the project.

>> One Mind, Many Hearts

Business people and developers must work together daily throughout the project.

In Waterfall once the requirements are written and approved, they never are revised. In Agile though, they are constantly being checked, rechecked and revised as many times as possible.

This ensures the team is working towards the same goals, always aligned.

>> The Team Makes The Dream Come True

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

In order to perform their best, people must be feeling their best. Nobody likes to work in an environment where they are just taken for granted, made fun of or generally marginalized.

Agile focus on people: Your team is your greatest treasure, take care of them.

>> Avoid E-Mails That Could Be a Conversation

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

If you have something to say, say it. Don't communicate with means where interpretation depends on the receiver: this may cause misunderstandings or even get lost in the process.

In order for the team to be close knitted, they must be open and talk freely. If there is something personal you would like to discuss, by all means get to a private place and let it out: the best way to trust your team is to be open.

>> How Far Are We?

Working software is the primary measure of progress.

No matter how much bureaucracy goes through nor the amount of meetings you have: what really counts as progress is the resolution of the problem.

Is the construction going forward? Are people building anything, have the parts arrived? That’s how you check your civil construction progress.

>> Keeping Up the Pace

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

I believe this one is pretty straight forward: If you want your team to to their best work, the pace must be constant.

High revving or slow traffic periods may kill productivity because they may get the team tired and/or distracted resulting in a demotivated team.

>> Attention to the Details

Continuous attention to technical excellence and good design enhances agility.

As we embrace changes, we must take some time to review previous work. We must take good care of the design and techniques being used by the team as they may need some tweaks.

Tweaking the tools, design and techniques over time will allow the team to perform better.

>> Give it a KISS

Simplicity–the art of maximizing the amount of work not done–is essential.

KISS means Keep It Simple, Stupid. The project and requirements should be easy to understand and you should’t have to complicate your or the team’s work needlessly. Also, getting rid of unnecessary bureaucracy is a MUST for agile teams to succeed.

>> Self Improvement Is Real

The best architectures, requirements, and designs emerge from self-organizing teams.

As the team goes along the agile process, it tends to become self-organizing. This means the team is capable of identifying and correcting its own flaws over time, be it technical or organizational.

Such ability also allows the team to make better decisions, faster which increase the value delivered over time.

>> Hindsight is 20/20

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

For a self-organizing team to exist, it must be able to reflect on past decisions and events. Quite easy to do, actually: it is normally called a Retrospective.

Retrospectives are events which should occur as regularly as delivers, so you can always iterate on the most recent achievement.

The retrospective should focus in what went well, what didn't go well and how can the team improve. Of course, this is not a rule and the team is free to adapt it to use what is best for the team itself.

> What Does It Mean to be Agile?

Contrary to popular belief, being agile is not the same as being fast. Crazy, right?

At least in the context of project management, being agile means being able to react to changes as soon as possible.

This is a good contrast to Waterfall, where any and all changes would mean the project termination.

The changes handled in agile don’t include only project changes but also team-related changes as well. This means agile is ready to embrace individuals coming and going from the team just as well as it handles requirement changes.

> The Puzzling Framework

I have already stated that agile is actually a framework, but what is that?

Essentially, a framework is a collection of tools, practices and processes but without a fixed structure.

This allows you to combine those tools, practices and processes in whatever way you want, as long you don’t go against the principles.

This allows you to have a tailor-made approach as to how your team works and because of the agile nature, it also allows you the flexibility to change anything, anytime.

Of course, this can also present a challenge: no two teams work the same way. This amount of customization may introduce some confusion as to how teams operate among each other, as they each have their own way of doing things.

At the same time, this is exactly what agile is good for: Individuals and interactions. Because the teams are agile, they should easily transform this perceived difficulty into something useful for both teams.

> Where Are My Deliverables?

In Waterfall we had many artifacts or deliverables, pretty much one for every phase. How does agile handles this?

The short answer is that it doesn’t: there are no artifacts in agile, at least in principle. Maybe your team decides to output some artifacts but that will depend on your own goals for the project.

Agile focuses on delivering value. While some artifacts are important overall, they do not directly add value to the project or they may even cost too much time to maintain.

The Business Rules are a great example of this contrast between Agile and Waterfall.

In Waterfall, there is no turning back once the Rules are set and they get documented into a very thick paper tower. If, by the will of the universe, those rules need any kind of change, the current version of the document must be trashed while a new version is produced. Not only that, the team would have to halt work on the project until such changes are made because they cannot afford to rework on something.

In Agile changes are part of the daily life, therefore a update on any of the rules is not only expected but also welcomed. The team, using it's own tools, practices and processes will find its own way to document and implement those changes seamlessly, without adverse impact to the workflow.

In essence, everything in agile is decided by the team, including what a deliverable is and how to approach it.

> The Dream Team

At this point of the article there’s a sense of too much responsibility being at the hands of the team, but that’s a good thing.

After all, the team is composed of anyone of interest to the project, even if they are not directly working on the deliverables.

In agile there is less focus in what role you possess and more in how can you help the team succeed which means your job title doesn't affect how the team operates, only your actions matter.

Let’s imagine a football (soccer) team and how it works. There are 11 players in many different positions with two objectives for every match: Score goals at the other team's goal and do your best to block the other team from scoring at your goal.

In order to better organize the team, it is broken down in about 4 main groups: offense, mid-field, defense and goal keeper. Each group respects the two main objectives but each accomplishes them in different ways:

Having roles is important for a team, it allows everyone to know what part they should take during the match. At the same time, the role does not limit them to that specific position at the field. There are no rules against a defense player getting the ball and scoring a goal, nor a rule against a offense player making a daring dribble and saving the team from taking a goal.

You also have team members which are not directly part of the match. This includes the coach and the assistants, for example. Their job is to help the team get to the match in top-notch condition and even handle some unforeseen circumstances such as strategy changes or player substitutions.

All that matters is that all the people in the team have the same objectives. In this case, it’s to win the match, no matter what your assigned role is at the beginning.

> Framework Pre-Fabrication

So agile is pretty forgivable in how you organize your team and how your work is laid out because all that matters is that you always follow the principles.

But does this mean you have to build your team workflow from scratch every time?

Of course not!

While agile is a framework and doesn’t force you to follow any specific method, there are some, let’s call them implementations of this framework which can be used out-of-the-box.

The two most common, at least for me, are: - SCRUM - Kanban

There are many more ways to use the agile framework than just those two, think of it as a LEGO brick.

Those two do follow the agile principles in their own way but they are NOT interchangeable. Choose them wisely before starting because they have very distinct ways of handling work and changes.

> Embrace Agility

Agile does not mean you will deliver faster nor finish the project earlier, so why choose something which seems so random instead of the structure Waterfall provides?

Simply put, agile allows you to have better previsibility, better quality control and greater understanding of the project.

The ability to embrace changes and take care of the people allows agile projects to adapt better to changing conditions, be it market, weather or even political ones.

> Fake Agile

Not everything smells like roses, unfortunately. Because of its framework nature, agile allows people to implement their own version of it.

Some implementations are great such as the examples above. Others, however, convince you they are agile when in fact, they are their own flavor of doom.

Make sure you really understand and stand behind the agile principles before choosing or creating your flavor of agile or this will mean the downfall of your project.

Some examples of anti-agile methods include but are not exclusive to:

> The End of the Race

Let’s conclude your agile adventure, shall we? I hope by now you have a good understanding on what agile is, how to use it and how to make it better.

Like every tool in the universe, it's power comes from how you use it, not from the tool itself. You don’t have to exclude Waterfall from your life, it may be a powerful tool in other scenarios but I personally think you should start thinking about agile first, regardless.

As always: if you have any questions or comments, send me an e-mail or message me through Telegram, the links are at the top of the page.

Bye for now.

agileanalysisdeliveryfeedbackframeworkiterationmanagementmanifestonavigationpeopleproblemprojectresultstatementstructureteamtoolwaterfallwork