When someone compares agile with “traditional’ development I have no clue what they are talking about. I have never worked in a software company that produced software as if it were a widget on a factory assembly line. I have never worked in an organization where people didn’t talk to each other constantly. I have never worked for a company that didn’t periodically reflect on its own processes and/or procedures to identify areas of improvement. I have never worked for a company that wasn’t capable of adapting to changing to ‘requirements’ when necessary. And, I would say that the majority of people that I have worked with are highly motivated individuals who strive to do the best possible work, and who are capable of adapting, improvising, and over-coming obstacles in order to ship complex world class software.
This is the way it has been for me during my almost 2 decades in this industry. So, when I read books and papers that compare agile to “traditional” approaches I ask myself, “What in the hell do they mean by “traditional” approach?
For example, when I joined the Windows 95 team we had weekly builds, and at least once per week the build had to satisfy the requirements for “self-host” status. Self-host meant that anyone in the company could use that build for their day to day work. Also, many of the self-host builds are released to key strategic industry partners and 3rd party vendors so they could take advantages of new features in their software.
After the PDC release of Windows 95 we made several key changes in the operating system based on feedback from our customers and partners. Also, late in the cycle after beta 2 we had to make a major change in how Windows started because of a quirk in a relatively popular MS DOS based game. Throughout a typical lifecycle features are added, removed, and tweaked based on several factors including customer feedback.
Instead of sprints we generally have milestones. At the end of each milestone many teams have a post-mortem or retrospective to review key objectives, discuss things that went well, things that could have been improved, and “tune and adjust its behavior” to make sure everyone is aligned and find ways to increase effectiveness.
Most developers were also doing unit testing. (TDD is simply another way of restating Dave Gelperin’s and Bill Hetzel’s famous quote from around 1987 “Test then code.”). Testers and developers talked frequently, and on many occasions the developer I worked closely with would come to my office to debug a hard to reproduce issue. And the majority of testers who were hired in the early 90’s were typically required to have an in-depth technical and often coding background in order to be able to engage in all aspects of the software development lifecycle and perform all the various job roles that might be required from a testing professional.
By 1998 we were doing daily builds. We have well established unit test libraries that not only assist developers in refactoring, but also help prevent build breaks and down-stream regressions. We still do a lot of API (component) level testing, as well as integration and system level testing.
Of course some of our products have longer release lifecycles than others. However, as indicated earlier we deliver “working software” at least once a week internally, and even to some premier customers (especially after the third milestone leading up to the final release of that version. But, some of our teams release every month.
Stepping back and looking at the debates, the books, and conference presentations I realized that I can relate well to the Agile principles. We often use models, principles and other abstractions to describe things. And, when all is said and done Agile principles are simply another way to present concepts that are intended to enable a team of highly motivated people to work together to ship a high quality product that satisfies their customers.
We have different models to generalize our processes to help us describe our typical workflow to others. But in truth there is no single way to build software, and models are simply our abstract expression of how we view the process. In fact, each team chooses processes and procedures that work for them and their particular product in their unique context.
(BTW, I am also really tired of Agile pundits always comparing Agile to waterfall models. Why don’t they compare their understanding of Agile to the V-model, W-model, or especially to spiral or other iterative models of software lifecycles? These are models; how your team chooses to implement a development lifecycle may resemble one of these models or you may adopt things from different models to implement your processes and approaches to software development.
Remember, George Box stated, “All models are wrong, some models are useful.” We should implement the concepts embodied in the model; we should not implement the model.)
So, to me, Agile is the ability of a team to interact with each other, to adapt to changes, to periodically reassess its productivity in order to strive to become more effective and efficient in delivering software to its customers. Agile (and every other lifecycle models) is not a process; Agile is a mindset.
4 Comments
“Agile is the ability of a team to interact with each other, to adapt to changes, to periodically reassess its productivity”
This is great, and has been my experience as well. I am relatively new to the industry, and learning to test in an agile has both encouraged me to change my processes, and also to see similarities to other methods.
I am glad you brought up the W- model, because waterfall is not the only thing out there. Great points.
I started my career back in 1998 and was one of those test engineers expected to have deep technical coding and/or system engineering knowledge. I sometimes just shake my head in wonder at the younger crowd coming up who actually argue it makes them better testers to have no idea how a computer actually works. But that’s another blog entry.
Regardless, I was at Microsoft and was in charge of the nightly build process you describe in your post. There are several ways agile differs from what you describe, which you rightly call the v-model.
First, the test cases you describe were in my group almost to a test written after the code was authored as a way to validate the work. TDD dictates writing the code to make the test pass, not writing a test to see if the code works. The distinction was generally “fudged” by only counting it if the code was checked into the source tree.
Second, there was still a lot of energy and effort expended on generating documentation up front. Developers would require detailed requirement specifications, the acceptance of which was the entrance criteria for the design phase. Testers would require detailed design and technical specifications, the acceptance of which was the entrance criteria for the testing phase. Everyone wanted to review the detailed testing specifications, the acceptance of which was the entrance criteria for the actual testing work to commence.
Third, the builds were “stand alone” as you rightly pointed out but they were often amalgamations of half finished feature sets with no way to easily install or uninstall the compiled code. The bar for “stand alone” was frightfully small and usually only meant it could be compiled successfully and somehow place on a machine where testing could be performed. Even later in the product lifecycle when minimum marketable features were available, the “working product” model was usually only enforced later in the milestone. Early milestone builds were often treated as throwaways. I know this from personal experience because a large portion of my time spent managing these builds was spent figuring out ways to completely wipe an entire drive space, install a brand new OS, and then somehow get the required bits onto the machine for the white box tests to run. We had to do this because there were no installers, no way to safely uninstall, and often no GUI to monitor.
You’re correct that agile is a philosophy or process more than a methodology, but like any philosophy there are key principles with which you must at least tacitly adhere or else you really aren’t a follower so much as making the claim.
“And, when all is said and done Agile principles are simply another way to present concepts that are intended to enable a team of highly motivated people to work together to ship a high quality product that satisfies their customers.”
Well said. As such, I wish we could move on, and stop having Agile frame every conversation about software development. It feels like it is holding us back at this point.
This is great. I asked the same question and I got the look as if I am incompetent. Glad somebody post it out there and inform people that agile is a mindset.
One Trackback/Pingback
[...] This post was mentioned on Twitter by Leonid Maslov , Markus Gärtner. Markus Gärtner said: Thought-provoking blog post from BJ Rollison: http://bit.ly/cwP8jy How MS used Agile "practices" back in the 90s. [...]
Post a Comment