The agile paradigm adapts processes to human nature, in contrast to the classical management approach which obliges team members to adjust to a particular development process. Bateson's learning model can help us to go from doing agile - following an agile method - to being agile - having your own agile identity and vision.
Being brave is about doing what is necessary, even when you are afraid. The single most important thing in agile is to inspect and dare to change things which aren't working. You can start with small experiments to find solutions, and if it turns they do not work, then you can stop them.
Alistair Cockburn recently posted his viewpoint on the history of the Agile Manifesto, from the perspective of one of the original authors and signatories. He encourages readers to understand the perspective taken at the time by the authors, and also to explore the ongoing work of many of the original signatories. The original authors explicitly refuted the idea of rewriting the manifesto.
People stopped seeing the need to define the architecture or do software design due to incorrect interpretation of the agile manifesto, argued Simon Brown. Many software developers don’t seem to have a sufficient toolbox of practices and the software industry lacks a common vocabulary for architecture. A good architecture enables agility with just enough up front design to create firm foundations.
The survey on Agile Manifesto 2.0 investigates whether the Manifesto for Agile Software Development is still relevant and effective in today's environment. Kamlesh Ravlani, an Agile / Lean Coach and Scrum Trainer, created this survey to gain insight into the need for change in the Agile Manifesto. The survey is open to anyone who has experience with and an opinion about the Agile Manifesto.
At the recent Agile 2016 conference in Atlanta, Joshua Kerievsky, CEO of Industrial Logic and author of "Refactoring to Patterns" gave a thought-provoking keynote around the idea of Modern Agile.
Truly agile is what you are, and to become agile you need to overcome paradigms, argues Arie van Bennekum, co-author of the agile manifesto. It takes "being agile" and not "doing agile" to achieve success. Agile is an interaction concept based on the values and principles of the agile manifesto. Technology facilitates agile working, but tools don’t make you agile.
Sometimes organizations that are adopting agile complain that they didn't get the benefits that they expected to get out of it. One of the possible reasons could be that insufficient attention has been given to performing the technical practices that support the agile values and principles.
Dave Thomas and Martin Fowler participated in a panel for the GOTO Conference series, focused on ‘A retake on the Agile Manifesto’, inspired from Dave’s blog, ‘Agile Is Dead (Long Live Agility)’. In this Q&A, Dave (also known as Pragmatic Dave) explains his thoughts around the panel, his blog and why he believes it’s time to focus less on agile and more on the practical application of agility.
Agile retrospectives help teams to find and do actions to improve continuously. There are different ways to do follow up on the actions and to evaluate if actions are leading to better team performance and more value delivered to customers.
The Manifesto for Agile Software Development values "working software over comprehensive documentation". This core value asks us to think about how much and which kinds of documents are needed and when they need to be written.
A recent Gartner blog raised the issue of Agile projects driving "death march" behavior as each iteration becomes a drive to deliver more and more.
The principle of “responding to change over following a plan”, is it a strength or a flexibility that can’t work in practice? For example, what about agile projects that had difficulties managing changes and customers who expect too much flexibility? Can agile not live up to its promises, or is it the way that teams and organizations have adopted agile that is causing the problems?
Debates are being held in agile communities concerning the right way(s) to do or be agile. It is questioned if you are agile or not, and if you do good or bad scrum. How can you deal with this?
A new "Scrum Kickoff Planner" has just been released by Adam Weisbart with the aim of facilitating team discussion around the important facets of starting a new Agile team or project.