An agile approach to Agile mindset.
The Agile methodology (or even better, Agile Mindset) is like the pizza recipe: everyone knows it, but when it comes to putting it into practice, the results are often disappointing.
Agile principles are 20 years old already. To give a little bit of context, the Agile Manifesto was created in 2001 by a group of software designers and computer experts.?The message could be summarized in these four points:
From time to time, what was a very lean and philosophical guideline, has become the basis for a proliferation of methodologies, and approaches, aiming to offer tools for different project needs, and to somehow distinguish themselves from the previous ones.?
Some of the most well-known methods are:??
Note that even if all those methodologies all fall under the Agile umbrella, they are not strictly Agile. Agile is a mindset, while the above are mostly methods or frameworks.
The Agile mindset is a powerful tool for designing, organizing, managing and documenting complex processes concerning:
It could relate to any process, specifically if it's about a technical development over a given, dynamic, requisite.?
Personally, however, I like to think of Agile not so much as a set of rules, processes, acronyms (there are so many), but rather a mindset, to be applied and used in addressing both business and personal life challenges, dependent on processes and interactions between multiple subjects.?
I would like then to extrapolate a couple of key concepts that can serve as a guideline to bring a bit of agility into everyday work.?
Time and budget are not project variable: the?traditional project development method (so-called Waterfall), define the product as something?to be realized as a monolithic entity, with fixed requirements. This often leads to the deploy of products beyond the estimated time, whose specifications have become obsolete in the meantime and at a higher cost than budgeted.?According to the Agile methodology, on the other hand, a minimum viable product (MVP) must always be released within the deadline and at the agreed budget. This allows to achieve market goals, control costs (and therefore preserve the ROI), and it does not preclude subsequent product increases, to be carried out perhaps after further validation and testing (in an iterative way).
领英推荐
The organizational model is subordinate to the operational one: the decisional driver is the product in its wholeness. Time constraints, economic constraints ties, customer satisfaction, adherence with requirements. The formal bonds of the org chart, are subsequent to the attainment of the business purpose.
Prioritize: for the business team, everything is super-urgent and hi-priority (if you know what I mean). For this reason it is difficult for developers, technicians and project managers to understand which requirements are essential and which can be considered secondary. The Agile methodology helps us in this important evaluation phase, with the MoScoW method:
a) Must Have: must-have requirement, without which there is no point in doing the project. Without this requirement the product could be illegal, unsafe or unusable. There are no practicable workarounds. Also known as "Minimum Usable Subset".
b) Should Have: still very important requirement, but not invalidating the delivery of the project. A workaround is possible, even if with some effort.
c) Could Have: requirement of less impact, for which there are alternative solutions, acceptable workarounds, or that do not invalidate the basic use of the product or service.
d) Won't Have this time: the most hated statement by managers around the world. It concerns functionality out of scope of the project, lesser in scope, or not meeting the time and budget requirements allocated to the project.?
Iterate: perhaps one of the most important concepts of the entire Agile methodology. Don’t draw, design, develop and deliver in a monolithic, unidirectional way. Instead, work in a circular way, in close contact with the end user, and in smaller batches than the overall duration of the project (i.e. measuring time in weeks). Test your assumptions, get feedback, make changes, repeat. Time, money and resources will be preserved and the product delivered will meet the needs of the business, which will often have been involved in the feedback phase.?
Communicate frequently: it may seem a?trivial advice, yet communication within projects is one of the most underestimated issues, often leading?to dead ends.The Agile methodology aims to break this vicious circle, advising frequent, rapid and informal alignment between business, technicians, management, and stakeholders. Forget three pages email, 80-page reports (which no one would read anyway) and massive Power Point presentations. Go instead for short daily meetings where everyone can contribute freely and informally. Create shared workspaces where it is easy to share files, documents, code, and encourages cross-functional collaboration.?
Have fun! If this one sounds strange, you should probably reconsider something about your work. The Agile mindset does not deal directly with having?fun (even if you can find many articles about this particular association), but it advocate about working in a united and cohesive team, pursuing common goals and managing conflicts and risk situations in a practical and informal way, completely dismantling the "culture of error". If this is not strictly funny, it’s a close call anyway. Working with passion, enthusiasm, creating something useful and relevant, having fun, is the best way to have a team motivated, enthusiastic, and totally dedicated to the project!?
Already using Agile at works? Share your thoughts in the comments :)
Editor's note: I got the Agile PM DSDM certification passing the relevant exam in 2019.?
Tech dev & strategy for energy @ Aziona
5 年(primo esperimento con l'editor di linkedin, ero curioso di provarlo. In sintesi, ho passato più tempo a formattare il testo che a scrivere l'articolo. Prossima volta, si torna su Medium???)