This piece is yet another installment in my series on Agile methods and mindsets. Each article in the series progressively elaborates on the subject and shouldn’t be consumed on their own, but along with the other entries. The form in which the articles are split isn’t along any lines except for those of my convenience. At a later stage, I may re-organise the content so one article flows into the other, however, my primary concern for now is to share the knowledge in my head as quickly as possible. Please please feel free to share your thoughts and excitement in the comment section below. Thank you.
Agile is a project management approach that was first adopted by cool people building software. Today, is adopted to drive the delivery of different types of projects irrespective of the domain.
The Agile Manifesto, puts forward 12 principles to guide software teams (and really any team) that uses or plans to adopt the Agile mindset.
Some key advantages of Agile is that the teams detect potential failure(s) in delivering the project early and can then take steps to remedy the situation. The team(s) understand change and are quite adaptable to it. And the customer knows what is being built, sees the work being done take shape and can thus re-evaluate their priorities, bring new information that can impact the product being built to the attention of the project team, commence the process for making changes etc.
At a very high level, Agile, lets teams build and deliver a working product quickly and then continuously flesh out the product by adding all required features iteratively‘. In some cases the product can be commissioned into service by its owners and users continuously informed of new functionalities and features as they are introduced. Sometimes, learnings from the use of the product can be looped back into the delivery process to improve the product.
Agile thus aids in the delivery of the right product.
A few variants exists thus:
SCRUM – which takes its name from the sport of Rugby is perhaps the most popular variant of the Agile approach to project delivery. It is one I also find useful outside the domain of software delivery. I have adopted it pretty much in every project where requirements are either not absolutely clear on day one or they are quite susceptible to change. At a very high level, SCRUM works as follows:
- Team members are assigned time-boxed tasks – often two weeks
- Time boxes are called sprints
- Team meets daily for 15 minutes or as may be required (shorter is often better, everybody gets the chance to go back to work sooner than later) to answer all three questions below:
- What did you do/complete since we last met?
- What are the challenges you faced (SCRUM master adds these to a risk register and attempts to resolve all as quickly as possible)
- what do you have planned between now and our next meeting (next meeting is usually tomorrow)
SCRUM has names for people in the team thus:
Product Owner – the person who is responsible for the product being built. May be the SPOC from the client or business, [I often believe this could also be someone on the project delivery team who understand the client extremely well that s/he could play devil’s advocate when viewing the work being done and that can raise issues, provide clarifications etc. and can also walk the client through the demo of the product being built].
SCRUM master – the project manager and the political head of the project team. Coordinates SCRM meetings. Negotiates for resources. Interacts with management. Interacts with the product owner. Interacts with vendors. Does all the pampering and hard talks.
SCRUM team member – everybody who contributes from within a SCRUM team to the work the team is doing or that may have been assigned a task in the team.
SCRUM has a planning stage where requirements are reviewed and catalogued and then scheduled. This is called backlog planning and the catalogue is called a backlog.
There is also a review session at the end of every sprint where the efforts and outcomes of that sprint is reviewed, lessons learnt discussed and documented and if possibly adapted for future sprints.
Courses and Certifications
There are a few SCRUM courses and certifications out there, however, SCRUM.org appears to be the most respected – in my opinion, though.
However, my suggestion is that you check with colleagues before committing to a certification process, in order to end up running fast and efficiently in the wrong direction.
Further readings:
- SCRUM is a learning framework, not a methodology – Michael James
- A quick rundown of Agile methodologies
—
Credits – Cover image copied from Wikipedia
