When trying to get waterfall teams and organizations to move to a more Agile development methodology there are two training strategies – philosophy and practice.
The philosophical approach relies on teaching the history of software development and the philosophy behind Agile – the manifesto and principles. This approach assumes that as long as one is equipped with the proper overriding principles then one will be able to make the correct decisions as challenges occur.
The practice strategy relies heavily on training the ceremonies, especially scrum ceremonies like standups, retrospectives, reviews, etc. This approach assumes that if you do the rights things that overtime the reasons for the practices will become apparent.
Continue reading “Philosophy Versus Practice”
I have spent a great deal of time lately reading blogs predicting the end of Agile. There are a lot of good people making a lot of good points but I think that there are some major problems the arguments predicting the end of Agile.
There is a very real tendency for people to confuse Agile (the philosophy) with Scrum (a process created to achieve the principles of Agile). Agile is only 16 statements – 4 values and 12 principles – nothing more. Of those 16 statements I am sure that there are some who would argue against them, but these would be a fringe element. Don’t believe me? Follow the links above and see which, if any, a rational software developer or business person would disagree with. You can disagree with them, but principles, in and of themselves, cannot fail.
Continue reading “What Agile Processes and Diets Have in Common”
“Business people and developers must work together daily throughout the project.”
I was in a backlog grooming meeting this morning when I was given reason to reflect on this, the fourth, Agile principle. The reason was that the team I was working with was struggling/arguing about the proper wording of a story. To a few on the team the absolutely precise wording of the story was of paramount importance. While I am a big fan of precision, the vehemence of the need to be precise was a bad smell. It took me some time to realize where the stridency came from.
Continue reading “The Fourth Agile Principle”
Whenever I work with a new Agile team I have some stock “speeches” that I tend to give. One of my favorites “speeches” covers my expectations are for a newly formed Agile team, namely increased transparency and predictability. Notice that I did not say increased velocity. That may or may not come with time, but the first two hurdles are getting to a point where one can understand what is going on at any time – transparency – and what can be expected to be delivered over time – predictability.
One of the biggest hurdles to getting any software development completed is endless interruptions. Transparency provides a safe haven where anyone associated with a project can see where the team is at anytime so that constant status and interruptions can be calmed.
Continue reading “What to Expect from a New Agile Team”