Agile is for the disciplined professional. Prescriptive != Disciplined.
Agile shift is a journey. There are many things that need to be done to make a transition a more Agile way of working. Changes in the sizing and structuring of teams, their decision making, and team members’ levels of accountability and responsibility are just a few of the paradigm shifts you will encounter throughout the transition to Agile teams. So is Agile in your organization more descriptive or prescriptive? Does it mean more discipline or less discipline? Are you only doing Agile or being Agile?
Agile shift is a journey. There are many things that need to be done to make a transition a more Agile way of working. Changes in the sizing and structuring of teams, their decision making, and team members’ levels of accountability and responsibility are just a few of the paradigm shifts you will encounter throughout the transition to Agile teams. So is Agile in your organization more descriptive or prescriptive? Does it mean more discipline or less discipline? Are you only doing Agile or being Agile?
Agile is for the disciplined professional. Prescriptive != Disciplined. Agile is a paradox because it is not less discipline, but means more disciplines than any other development method. There is no hiding in Agile. Everyone has to tow their weight or the failures in the team would be immediately exposed. Because there is often considerable ground to cover to bring an organization up to a reasonable starting point for agile development, an incremental approach to improvement is usually more effective than a "prescriptive" leap to someone's canned-and-branded "agile" model. It requires more discipline than a prescriptive approach. In that sense, "prescriptive" includes incremental recommendations to the team as they build experience. So "good prescriptive" methods would be well grounded and ideally, means really best practices and principles. When, where and why should you be prescriptive in Agile software development approach? Well, at the beginning when you don't know what you are doing. In other words, when, where and why should you be disciplined? If somethings aren't prescriptive, and then what you have is a cafeteria menu, and potentially, anarchy and chaos. Agile does call for discipline.
The challenge of Agile, in general, is to identify a universal set of principles and foundational ideas: they are both more fundamental to the Agile Manifesto and more specific to the best practices. The philosophical foundation will identify key aspects of human nature. More specific disciplines include the best parts of Scrum and XP with respect to the Agile Manifesto. There are appropriate contexts for each principle and software development provides one such context. Of course, agile always requires discipline, as opposed to prescription, but not only in the application of good technical practices such as continuous integration and peer review. The Agile techniques such as Scrum and XP are simple enough to understand but complex enough to extend and adapt once we understand it. There are few situations where being entirely prescriptive is effective, but that there are huge variations in how receptive people are to the agile principles, the pitfalls of Agile include:
-Team gets the principles but are unsure how to get started
-The team has been told they must go agile so just want to know what it involves!
-The team understands the principles, want to do it their own way, but there are constraints stemming from scaling agility to a whole organization.
- Team recognizes the new way of working but wants a solid foundation on which to inspect and adapt
-The team assumes that a cookbook will be given to them and that the agile practices completely replace everything else.
Following "people over process" Agile principle: In most cases, organizations are not in a good position to leap directly to a mature agile team structure and supporting policies and culture. And to deliver effectively using a lightweight method depends on "people over process" to assure high-quality results. Most programmers are unaware of basic software design principles. Most analysts only transcribe whatever stakeholders tell them to do. Most testers never go beyond basic "checking." Most managers understand cost accounting but not throughput cost optimization, and many still depend on Theory X approaches (a negative view of human nature that assumes individuals generally dislike work, are irresponsible, and require close supervision to do their jobs.), not Theory Y approaches (a positive view of human nature and assumes individuals are generally industrious, creative, and able to assume responsibility and exercise self-control in their jobs) (referenceforbusiness.com). Most stakeholders are skeptical about direct collaboration with delivery teams and tend to rely on indirect methods of communication. If so you can't expect most organizations to get very far very fast with a prescriptive introduction.
The Agile manifesto indicates the things on the left that are more highly valued than the things on the right. You can measure whether practices are being done and to what degree, but each team is different, hence it isn't really prescription, but more guidelines and heuristics. Agile is more about principles and philosophy, at its core, Agile is a mindset to run today’s dynamic digital organization.
0 comments:
Post a Comment