Agile principles were created as a solution to all the challenges that traditional teams had. Initially, they focused on software development, later evolving into overall team managing methodologies.

This shift towards agile principles signifies a significant shift in attitudes, with many teams all over the world adopting them for their teams.

I applied agile principles to my startup and felt the benefits almost immediately. I wanted to share this, so, other teams might be encouraged to emulate or use my own ideas.

What are the agile principles?

There are 12 agile principles. These are:

1.Customer satisfaction through early and continuous delivery of useful software

2.Welcome changing requirements, even late in development

3. Frequently delivered software

4. Close, daily cooperation between business people and developers

5. Projects are built around motivated individuals, who should be trusted

6. Face-to-face conversation is the best form of communication

7.Collocation and pair programming

8.Sustainable development, able to maintain a constant pace

9.Excellence through reflection

10.Simplicity – the art of maximizing the amount of work not done

11.Self-organizing teams

12.Regular adaptation to changing circumstances

All of these were designed to increase the success of your projects, making sure productivity remains high and that there are no interruptions to the flow of development. So, how did I apply these agile principles to all areas of my startup?

The ones that stand out

All of the 12 agile principles support project management. However, principles 2, 8 and 10 are probably the easiest ones, to begin with. Welcoming changing requirements, sustainable development, and simplicity. These were the three points that I started with.

Changing requirements in a startup are probably the most common factor. The problem is, most teams struggle to adapt to them, and so find themselves stuck. Unable to move forward. This was one of the first steps that I made to turn my team into an agile one. This also covers principle 12

Sustainable development, I feel, goes hand-in-hand with this. Growth should come natural, and an ability to maintain a constant pace is something that your team should strive towards. No off-days, and no super busy days when you can avoid them. Just a continuous flow of progress.

Now, the art of maximising the amount of work not done has always been a confusing point in Agile. In my start-up I’ve translated it to, everything can be improved. Nothing is ever not-finished, which means that minimise the minimise the output and maximise the outcome. We shouldn’t be striving for a finish line, just goals to be made, and making a difference.


Number six was another of the first principles I adopted. Although, seemingly effortless, when you’re running a team it can be hard. However, I always make time every week to have a face-to-face conversation with my team. It’s really the only way to get honest answers, and authenticity in your organization.

No more checking up over emails, a meeting face-to-face, some way or another is the best way to talk to your team.

Number four is a principle that also lies in communication. Close, daily cooperation between business people and developers. Too often, we don’t communicate or cooperate with other teams, people or developers. Having regular communication with other developers really helped. I did this emailing, calling and face-to-face interviews.

Communication is significant in agile teams, and it allows us to make informed decisions, and be clear on how happy everybody is in the group.

Principle number one: Customer satisfaction through early and continuous delivery of useful software, also revolves around communication. You must always be ready to check up on your customers and make sure that they are super happy with everything you’re providing them. After all, you have to make sure your customers are satisfied – they are always right.

Communication, in an agile way, shouldn’t be long, critical meetings. It should be useful encounters, where both parties exit feeling positive and refreshed.

Excellence through reflection

In my startup, this basically meant that everybody had to reflect on their work, and see how they can improve. Regular check-ins, and self-analysis was the best way that I achieved this. Rather than through lengthy board meetings.

Again, incorporating other principles, this also meant that we would be focusing on velocity and capacity, rather than the time it took to complete.

Self-organising teams.

This point is absolutely something that agile beautifully masters. My startup embraced everything that came with this amazingly.

Too often, as team managers, we micromanage. Basically, we double check everything our employees are doing, make sure every idea is passed through multiple people, and it just makes the team feel less motivated. Micromanagement is never good, and agile doesn’t go hand-in-hand with this.

I created a working Trello board of projects and tasks, creating a backlog of jobs and prioritising others. This creates the perfect organising tool, which allows teams to just get on with it.

Frequently delivered software

I’ve spoken to many other agile teams who believe this is crucial to agile. No surprise as to why. Without regularly producing software that matters, none of the other agile principles will really matter.

My team uses the other principles, especially the Trello board, to ensure that they are regularly pushing for a release schedule. This helps work against the “never done” part of agile.

Trust in your team

With principle five, it came super easy. I trust my team, and I know their individual strengths and skills. I would never try to diminish this from them, or make them work in a role that doesn’t wholly suit them.

Point five – Projects are built around motivated individuals, who should be trusted. I did precisely this, and continue to do this. I listen to my team, and find ways that they work their very best. There’s no one size fits all in a team.

Co-location and pair programming

Last, but by no means least is point number seven. It’s basically the idea that two programmers will work together at one workstation. One will be the driver, and the other is the navigator/reviewer. Both are crucial roles, and this method works perfectly together.

The two roles will switch their roles frequently.

I found all these principles easy to apply to my own startup. First and foremost, because they make complete sense. Secondly, because they are, in my opinion, the best way to manage a team.

A team that feels free, inspired and successful, will continue to produce some of the best work, and that’s always the goal.

How did you apply your agile principles to your business? I would love to share (and perhaps copy) some of your ideas.

Leave a Comment