Before you go, check out these stories!

Hackernoon logoSome of My Experiences Regarding Agile Software Development Methodology and Its Core Team Members by@doyanaydun

Some of My Experiences Regarding Agile Software Development Methodology and Its Core Team Members

Author profile picture

@doyanaydunDoğan Aydın

I remember: In a day of 1998, I was in school and showed my personal web site to my school friend. It was absolutely amazing, I had felt myself really cool person among my friends. Because, at that time, although using a computer was unknown and complicated for people, I had successfully created my own web site by using HTML, JavaScript and a service of Yahoo(GeoCities).

From that time up to now, more or less 20 years passed and I have been still working on software development. I have been in different positions apart from software developer but I have never give up writing code in my works and my life. I have used different programming languages, tools, services in these 20 years. I have been working as a manager for last 7 years.

In this article, I will try to share some of my experiences regarding software development process and types of software development team members.


Nowadays, it is obvious that all people fully agree with Agile Methodology for software development. So, do I. But we need to know that Agile methodology is not a new thing or a unique experience. It has been used by software development teams for many years before the announcement of Agile manifesto. As known, generally intelligent people are interested in software development and they had already discovered and started to use this methodology in their processes.

Let me give you an example to define why methodology is important.

Today, if you want to build a building, you need to hire workers, need to prepare a building plan working with an architect. Then, you can create the building by spending your time. How much effort would you spend to maintain it after building this structure? Not too much, right since its solid, unchangeable construction. For instance, anyone doesn’t come to you with an extreme idea: Let’s add a rocket to this building so that it can move from one place to another!, whereas it doesn’t work in software development. Because, changing requirements is a normal thing in software development, it will happen. Thus, people come up with many different extreme ideas after you start to develop their requirements. Even, they are likely to change their ideas one hundred and eighty degrees for the product you develop for them. So, responding to change is becoming more important than following a plan. This is just one of its reasons for using a methodology but we need to know we are in a different challenge. So, at least one of them should be preferred in this challenge.

None of software development methodologies is the best one. Saying “one of them is the best approach” is not true. Software development methodologies depends on company’s culture, project and people, etc. The main responsibility of a software development leader is defining the right methodology that fits with company’s culture and project, etc. Therefore, leaders should know company, product, people and should take an active role for defining it.

You might ask that Agile Methodology is already well-defined, why do leaders need to define it again? You are right, however almost all company modify agile methodologies according to company’s needs, culture, project, etc. That’s why leaders define it again.

On the other hand, saying “waterfall methodology isn’t right method for software development” is also not true. Some projects are needed to be well-defined before starting projects such as military projects or health projects. For instance, after releasing a health product, it is not true saying that “we haven’t thought this case, let’s fix it”. It might cause of death. Therefore, before releasing this kind of product, all requirements should be defined and it should be developed according to these requirements.

As far as I have seen, regardless of which methodology is selected, the most important thing is commitment of team members. Each team member should become committed into the project instead of involving it.

The chicken was involved. The pig was committed.
Both were committed now.

This is a really good story for understanding the different between commitment and involvement. The pig provides its own a part(meat), whereas the chicken only supports the restaurant with an output of that it generates. Here is the difference between commitment and involvement.

The other important thing is daily meetings. It updates people and makes them ready for that day. In my opinion, everything of agile methodology can be modified except for daily meeting. It drives the team, so it always should stay in the methodology.

I am not going to mention the methods of the agile methodology in this article. The reason why there are tons of papers written by experts knowing more than me regarding the agile methodology.

Let’s focus on team members.

Team Members

Project Manager

The ideal size for an agile team is considered as six to ten members. If your one team consists of more than six people and if you have more than one team, it is better to work with a project manager.

For project managers, three main qualifications are required according to me.

  1. Communication skill for gathering information and directing people
  2. Characteristics of committed people
  3. Analytical skill

KPIs of a project manager could be

  1. Schedule
  2. Cost
  3. Allocation of resources(sometimes, they want more than they need)

Software Developer

I believe that a software developer is similar to a taxi driver. Think that: What happen if you travel with a good taxi driver? He/she takes you the place where you want to go in safety, by using the cheapest way and fast. If you travel with a bad taxi driver, he/she uses a way that is not shortest one, it takes more time and that causes you need to pay more money. Besides, you get stressed out. Like taxi drivers, software developers sometimes take your time, get you stressed out with their unqualified works.

Traveling with a bad taxi driver

I have worked with different level software developers, so far. Regardless of good or bad software developers, I always take into account to work with a senior in the initial phase of a project. When a new project is started, you should start it with definitely a senior software developer. Otherwise it is likely to be upset at the end of the project. It is regardless of how he/she are motivated, committed or intelligent. It is naturally process and they haven’t seen the right structure, not spend their enough time to understand what is good or bad for software development. Therefore, I always keep consider to work with seniors in the initial phase. After initial phase, junior developers can take an active role in the project.


  1. Curious
  2. Team player
  3. Characteristics of committed people
  4. Technical knowledge

Technical knowledge is required however it is at the end of my list. Regardless of how much technical knowledge a software developer has, it can be easily increased.


  1. Schedule
  2. Using best practices of software development
  3. Bug ratio in code

Business Analyst/Tester

I believe that BA and tester should be the same person. Otherwise, BA gathers requirements of customer expectation, tester controls it. It is obvious that tester doesn’t understand all requirements from BA documents or other materials. That causes problems. Therefore, I believe working a person that have two hats is better that working two people that have different responsibilities for this position. I am not trying to say that working only one BA person in a project. More than one BA/Tester can join the project according to needs.

BA should have a curios personality and love to work with tools such as mockup tools, wireframe tools, workflow tools, etc.

Visualization is important to tell expectations.
Wireframes is another important thing in software development.


  1. Team player
  2. Characteristics of committed people
  3. Communication skill for gathering information
  4. Curious


It is really hard to find a KPI that can be measured to show the performance of a BA. However here is my list for this position.

  1. Finding the information fast
  2. Being commited
  3. Define problems in a proper and detailed way
  4. Showing requirements by drawing them

The position number can be increased with product owner, team lead, scrum master etc. I just want to mention about the core members of a team. I hope it becomes useful for you.


Doğan Aydın

Linkedin Profile:


Join Hacker Noon

Create your free account to unlock your custom reading experience.