autonomation consulting
Collaborative Software Testing
Jonathan Kohl's blog on software investigation.
- Interesting Posts on Agile Challenges
Scrum Challenges A couple of posts that describe how many teams are flailing and failing with Scrum: James Shore: The Decline and Fall of Agile Rob Bowley: Lean is the new Scrum, and it will fail for the same reasons I've observed similar patterns. However, my gripe with an oft-heard Agilist response: "they are failing because they just don't get Agile" or "if Agile failed for you, it's your (or management's) fault" smacks of blaming the victim(s). An emerging response that I support is: "Maybe a pure form of 'Agile' isn't appropriate for that team, in their context." (Time for some Process fusion?) Philippe Kruchten has a great talk on this: Situated Agility - Context Does Matter, a Lot. It's also very difficult dealing with the scorched earth of a failed Scrum project after the Scrum trainers have left and the team is struggling on their own, feeling humiliated. "Are we the only ones failing? Why do we hear all these wonderful reports of how Scrum would solve all process ills? What's wrong with us? We're trying..." It's hard to get them to retain the good practices they learned from Scrum and to encourage them not to throw out everything and return to a system that wasn't working before either, but is more familiar, so it feels safer. Rumours of Practice TDD - more of a rumour of practice than actual practice? (much like some of what is described in the two posts above.) Roy Osherove: Goodbye mocks, Farewell stubs My own observations about these and other Agile practices being more of a rumour of practice than an actual practice leads me to wonder if Agile practices are another flavour of a bubble. Time will tell, but some of the behavior is troubling. It still galls me that many blindly parrot TDD as an un-alloyed good practice, instead of TDD as another tool to think about using, particularly when people might be basing their conclusions off of rumours, rather than personal experience. This irrational exhuberance is one reason why stock markets ramp up on empty speculation, real estate prices boom on over-valued properties (using mortgages that people can't afford to pay back), and tulips are bought with abandon. (At least you can plant your tulip bulbs and enjoy beautiful flowers when the bubble bursts. What do you do with your old un-maintainable tests?) My advice to those who may be struggling? Don't worry about being "Agile", (particularly if you're trying and failing) and worry about providing value. That's what really matters anyway. (That, and enjoying your work.) Providing value to the users of your software, and valuing the people you work with is important. Value, coupled with the skill and interest level of the team members, will trump methodology in the long run. - A Post-Agilist Concept: End Methodology Wars
One of the Post-Agile ideals I have witnessed and encourage is the breaking down of walls between methodology camps. When teams apply practices, processes, rituals and tools from Agile methodologies and create a fusion with other, compatible processes in order to create value, interesting things occur. In spite of apparent differences, many good ideas can be gleaned from dissimilar processes, and applied and adapted on your team with great effect. This paper: Towards A Framework for Understanding the Relationships between Classical Software Engineering and Agile Methodologies expresses a Reagan-esque: "Mr. Process Zealot, tear down that wall!" ideal. While I may not agree with all the details in the paper, it has some important concepts I want to point out. First of all, they describe the tension between Agile and phased or linear "waterfall" methodology pundits. They point out that this tension is sometimes referred to as a "methodology war" and say that this behavior is harmful to software development communities. They also find evidence of compatibilities between seemingly incompatible methodologies, and introduce an interesting analysis framework for analyzing software methodologies called "CHAPL." (They get extra points for using a mnemonic, and for the "C" representing "contextual analysis".) An excerpt: On one hand, [some] software engineers ... dismiss agile methodologies and strongly advocate the value of classical [software engineering] practice, while others ... insist that agile methodologies will replace Waterfall-like models and apply to all software projects. This heated debate is sometimes referred to as the "Methodology War" ... It appears that the typical characteristics of the debate are that the proponents of the conflicting methodologies:describe each other in extreme and biased termsdevalue the opponents' methodologies and/or practicesjustify their own values through either experience-based explanation or inadequate comparisons between the methodologies. We believe that this war is detrimental to [software engineering] practices. In order to end the Methodology War, some researchers have presented the similarities and compatibilities between the two methodologies. Methodology wars are the inevitable outcome of process visionaries working against the grain to introduce new ideas, and the resistance they face from the more established process idealists. Sometimes radical behavior or extreme statements are an effective way to get attention for ideas that are dismissed. Now that Agilism has become as well known as other process communities, it's time to stop fighting and find the areas where we agree, and try to improve how we all develop software. Instead of posturing over what process movement is "best", let's focus on the value we can create together. The paper was published by APSO 2008: Scrutinizing Agile Practices, or "Shoot out at Process Corral", In conjunction with 30th International Conference on Software Engineering, Leipzig, Germany, 10 - 18 May, 2008. Yes, I was on the program committee. - Software Development Process Fusion Part 2
What is it? The Short Version Software development process fusion involves taking different kinds of processes and tools and utilizing a combination on your project to help you reach your goals. You aren't just using one particular methodology or school of thought or toolset, you are using a combination of tools that fits your unique needs on your project to help create value. What is it? The Very Long Version In Part 1 of this series, I talked about fusion in music from early days of the genre, when it was somewhat controversial and aimed more at enthusiasts, to the present, when most music we hear on popular radio stations is a fusion of styles. On country stations, we hear rockabilly, pop, rock and roll, blues and traditional country fused together in many songs. Popular music now has influences from all kinds of cultures, and we are seeing hip hop music fused with traditional Indian music and pop. In my collection, Canadian artist Cat Jahnke includes folk, pop, rock, gospel and film music in her songwriting and performing. A more obvious fusion might be found in fellow Canadian artist Rebekah Higgs music, categorized in the "folktronica" genre, a combination of electronica music and folk. Another Canadian group with a wide variety of styles fused together is the Duhks, who "...play a blend of Canadian soul, gospel, North American folk, Brazilian samba, old time country string band, zydeco, and Irish dance music..." according to wikipedia. These kinds of fusions of ideas are all around us. The fusions of styles from different traditions, cultures and ideas are due in part to our increasing interconnectedness and mass media and communication. In the effort to create something new in the market, we often borrow something old or unfamiliar in our culture and mix it with the current and familiar. We have fusion cuisine, for example (a Chinese restaurant near our home became an Italian restaurant and serves delicious Asian-Italian fusion cuisine). We see it in exercise with holistic training, and exercise regimes that combine eastern, western, kinesiology and spiritual elements. Often a combination of ideas helps us reach our ultimate goal, which isn't to create a fusion of styles, or to adhere to just one style, but to achieve a desired effect or outcome. The goal of each of these examples is quite clear. With music, the musician's goal is to create something that resonates with them, an expression of their art and their personality. Their other goal is to produce something that is satisfactory and enjoyable for their audience. With restaurants, they want to provide fresh, delicious food. With exercise programs, the goal is better health and fitness. Another important underlying theme is financial success. We all need to make money somehow to live, and even though we may produce something that is wonderful, it may not be recognized by the market. Sometimes our goals in software development aren't quite as clear, particularly for those of us down in the details of coding, testing, writing, etc. It can be hard to see the big picture and measure ourselves against it. It can also be hard to deal with the imprecise environment that our software is released into and instead cling to something that feels predictable and stable, like a well-defined process. Software development process fusion involves taking different kinds of processes and tools and utilizing a combination on your project to help you reach your goals. You aren't just using one particular methodology or school of thought or toolset, you are using a combination of tools that fits your unique needs on