I have been hearing about 'Agile' in relation to Project management. I understand from dictionary that Agile means "able to move quickly and easily". Very well said and extremely desirable for business success under VUCA and what not!!
Further search informs that this concept was coined in 2001 and mainly for managing software development projects.
I read the menifesto:
*Manifesto for Agile Software Development*
"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools,
- Working software over comprehensive documentation,
- Customer collaboration over contract negotiation,
- Responding to change over following a plan."
I could not understand much and so looked for commentary. I read:
"Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly."
Am I wrong if I conclude that unlike waterfall (traditional methodology) there is no method in this madness? Does this methodology suggest there is no need to develop basic user requirement document and no need to plan or plan on daily basis in stand up meetings?
I read there is an associated concept of 'Sprint' as opposed to traditional way of developing detailed plan and execution. Does Sprint mean changing plan on daily basis? Is there a recommended shortest period for Planning without change? I learnt there was specification of few days to a month. Is it that the nature of product will decide period for which one Sprint will last?
There are experts in this broadcast group and in IT field. I will be obliged if you can help me understand this methodology.
I believe and I may be out of date, there is difference between agility, dynamism and parkinson's disease. Organizations can not be dynamic to the extent of loosing stability.
In my opinion there must be a balance between agile methods and plan driven methods employed. Breaking down the plan into smaller OKRs and focusing separate teams on them can be useful. The focus remains on teamwork and collaboration but there is a definite target to be achieved
ReplyDeleteMoving fast while thinking clearly.
ReplyDeleteHello,
ReplyDeleteThe basis of agile is still Waterfall but it can be described as an iterative Waterfall.
The base principle of agile is to fail early fail fast so that you still have time to recover.
Waterfall had the concept which took the entire tool and tried to deliver it in one shot, imagine an online banking system being developed as a monolith.
Agile suggests do login first, then saving accounts then investment accounts, you further split that into RD, FD, PPF & Demat.
10 years ago the entire thing would take months for requirements, months for design, and a few years to roll out the first draft.
Agile suggests that you chunk it up and run a 15-30 day development cycle, pick only the bit you can chew, with clear scope defined (at the start. if you think you can'tdo it, revise the scope).
In the practical world lot of planning goes into a sprint (way in advance).
You show the output to your customer every 15-30 days and get their feedback, this gives you an ability to do a course correction in 15-30 days Vs after 6-8 months.
Hope this helps
A sprint is a short, time-boxed period when a scrum team ( formation of players)works to complete a set amount of work. Sprints are at the very heart of scrum and agile methodologies, and getting sprints right will help your agile team ship better software with fewer headaches.
ReplyDeleteVery helpful comments here already.
ReplyDeleteKey goal of Agile is to have user/customer feedback early.
Sprints usually can be anywhere from 1-4 weeks. Decision on duration is taken very early and usually the sprint duration doesn't change after deciding, unless there is a very strong reason.
Each sprint has 'ceremonies' - for planning, ongoing tracking and then for introspection and improvement. There are metrics for measuring development process.
There are strong notions of requirements, design, architecture etc. Usually, all user requirements are broken into smaller pieces such that each unit is a feature that can be independently shipped and consumed by the end users. The user requirements themselves can be done iteratively although there is some planning and prioritizing involved there upfront.