I have joined a company which applies Agile for software development for three months. But I still don't know how to apply it to my work correctly and see any benefits from it.
It depends on the Agile framework you are applying to. Today, the two most popular models of Agile are Scrum and Kanban . Kanban isn't well suited for new developers that need to be onboard. It has less structure and as a new developer, you'll probably need to adhere to some guidelines to get going. Scrum, on the other hand, features a rigid process - sprints; daily stand-ups; retrospectives, etc. The point being, it'll be easier for you to adapt to Scrum as a new developer. Though if you are using Kanban, try to learn more about it and see how can you apply it to your processes.
Agile is a methodology or culture of iteration and rapid learning. It aims to de-risk projects by avoiding very long periods of development without any validation that it is actually working, or solving a problem for a client/customer. Hence delivering smaller milestones and iterating towards a final product, not planning one massive milestone and spending months working on it... before showing it to a customer.
However that's just my take on Agile and many purists would disagree ;)
A big problem is that many "agile" workplaces just have non-age processes with Agile ceremonies sprinkled over the top - "Waterfall With A Standup". Or, they have sprint planning and a backlog but absolutely no higher-level strategy or goals - "Making It Up As We Go Along". Which isn't really getting any value out of Agile.
It sounds like the real problem is you didn't get any real onboarding or instruction on how your company does things... If you have any scrum masters around maybe ask if you can buy them lunch and get them to explain how it's all meant to work. You may find it's not really embedded yet, but they'll probably be happy you're interested :)
Or perhaps it would help to go along to an agile meetup and talk to people who are keen on it (not sure if Agile Vietnam still hold a regular meetup in Ho Chi Minh, they just did a conference though agilevietnam.org).
Agile was the attempt of Developers to find a better process for software development.
Nowadays agile is a buzzword that is abused as a new methodology instead of a set of ideas.
If you go for the core concepts of 'the agile manifesto' - where the term agile comes from
agilemanifesto.org/principles.html
you will see certain declarations:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
So we have fast cycles and continuous delivery instead of final shipping. Also the term valuable software is picked loose, because there can be different dimensions to what valuable means. So it's not only money.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
This is only possible by consequence of good software design otherwise it will break our necks rather quickly.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This is basically just stepping away from the old 1 year cycles of software. To make decisions we need feedback and we can only get feedback if someone is using it, the sooner we get feedback the faster we can react.
Business people and developers must work together daily throughout the project.
This is the break of the top down hierarchy with isolated compartments. We as developers need to be able to get our business people to get the needed information about the domains and in return we answer their inquiries so we can help each other.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
That is a big problem that is often ignored, motivation is hard to keep if you are micromanaged and not appreciated. The ownership within the team can also scare the business.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
this is basically .... lets talk not just write. The written form can be a consequence of the conversation but there are so many angles we could miss in written form.
Working software is the primary measure of progress.
This comes from the problem of a theoretical measure of project states based on a plan. It usually collapses. To quote a German general in the prusian wars
No plan survives first contact with the enemy by Helmuth van Moltke
Where we can think of reality as our enemy ;). So only if the software works this is progress not the idea, not the meeting only the applied product.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This is a tricky one, how do we achieve and maintain constant pace? Here is where planning and the parts before are come in place.
Continuous attention to technical excellence and good design enhances agility.
well this is the part we want to hear. In the end it's about quality.
Also it reflects on the point before about pace. Without technical excelence we probably cannot maintain the current speed.
Simplicity--the art of maximizing the amount of work not done--is essential.
This is something that is a connotation debate. I personally would dumb it down to: Solve the problem with the least amount of code in a manner that makes it replaceable.
The best architectures, requirements, and designs emerge from self-organizing teams.
This is because the team actually is facing the problem, and it's a counter movement to the big system-architects with UML diagrams and we're back to the 'surviving contact to reality'
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This is again communication and how we want to improve ourselves and reflect upon it.
And than we have certain Frameworks / Systems for the agile methods
.... the most common known are kanban because of it's simplicity and Scrum
as a rule of thumb
kanban is good for day to day business -> it's from the japanese factories to optimize the work process by displaying who is doing what. it is good for 'where are we now'
scrum is good for iterative software development with cycles and look-aheads it is about 'where are we going'
That's it in short .... very roughly and I left out a lot of details also my opinion about application. Because I feel strongly about certain parts of the implementations in Scrum or Kanban
The only thing I am fairly certain so I will stand by it .... most people by applying a framework from the management perspective already violate 1 key principle of agile .... the ownership of the team.
The team decides which parts of which frameworks should be used .... you don't like stories? throw them away! you like pair programming? lets go xtreme! you think retros are nice but standups are a waste of time? lets do it that way ...
Pick a system, try it out, keep what works, but don't confuse low hanging fruits with the overall result.
anyhow .... all spelling mistakes are on purpose :P ....
Xingheng Wang
Co-founder Moesif.com (API analytics). Previous Microsoft & Zynga. CS from MIT.
hmm...
If you have been doing it for 3 month, you still don't understand agile, perhaps there is something wrong with the project manager.
Generally, for a project to run well, for any process, you need a person accountable for it. That person should be the project manager (in small teams that person may wear multiple hats). His or her job should be make sure everyone understand the process and why (i.e. what are the benefits) of following those processes. If you don't know, then that person haven't done his or her job.
There are plenty of book and article on the details of running a scrum or kanban process. But at a high level, agile methodology is based on iterative improvement, while requirements and the software evolve as you go vs. the traditional waterfall approach, where all the requirement are defined before you code. Key benefit is that the theory that is really really hard to know all the requirement for software product ahead of time, it is better to delivery something and get feedback and iterate rather than "finalize" requirements and only to find out it isn't what the customer want.
Second question, what kind of project is suitable for agile process? Almost any project, but process should be proportional to the team size and complexity of the project. If you have only one or two people, too much process can be a blocker. If you have 3 to 10 people, scrum process can be good. If bigger than that, you can consider split into pods, where each pods is about 3 to 10 people. Each pods focus on one aspect of the product and apply the agile process,