The other day I had the opportunity to interview Scott W. Ambler, one of the premier thought leaders of the agile methodology and its implementation. In addition, Ambler is IBM’s leader in agile development practices and has held this title for upwards of a decade.
Ambler has been working with the agile methodology since the early 2000s, when the Agile Manifesto was written, defining the meaning of agile in detailed documentation. “I started working with agile almost immediately right after the original snowbird meeting. Specifically I began modeling and examining the ability to scale agile to fit organizational needs — I wanted to see if the methodology was transparent and would be applicable for larger organizations to use.”
Since the introduction of agile to the software community, Ambler has taken part in, as well as organized, several annual surveys on agile success in business. While a large portion of his findings suggest that agile is a key component in revitalized software success – mainly in deployment time frames – it can be difficult for those using traditional methodologies to transition to an agile environment.
“One of the major problems with agile development that I’ve noticed are ‘self-inflicted’ cultural issues,” said Ambler. Organizations that have become all too comfortable in waterfall-type development have a difficult time finding the groove in agile development — and then staying in it.
“Often the biggest agile failures I see are in data groups and QA teams. These are the groups that have become accustomed to being ‘out of control.’ They are used to being micromanaged and aren’t ready or able to begin thinking for themselves. I look at them and wonder ‘how can any organization could tolerate this kind of behavior?,’ but many do, unfortunately. One of the biggest abusers of power that I’ve seen is in IT governance, but they’ve always been a bit of a challenge for organizations looking to run lean,” said Ambler.
Ambler believes that with a willingness and readiness to transition — any team or organization should be capable of adopting some agile techniques — even in the most unlikely of places.
“I have gathered overwhelming evidence in my surveys supporting agile adoption across the board. It is being used everywhere, even outside of software development and finding success. This economy, without a doubt, is a major contributor to this agile momentum — everyone is trying to lean down the expense of their project and roll out working products in smaller intervals. What is so surprising are the areas outside of IT walls that are using agile without reproach.”
Some of the areas Ambler pointed to were in the defense and regulation sectors, places where agile seemed like a long shot if not completely out of the question. “I’ve heard of airplane and missile manufacturers using agile techniques to engineer fuselages, highway construction – the list is endless. But just because agile worked for them, doesn’t necessarily mean it will work for you.”
Ambler recommends organizations in the manufacturing space interested in agile to check out Real-Time Agility as a reference. But the title is also helpful to strict software developers looking to make their production practice run smoother. The book explains how system engineers and plane manufacturers have been able to bring agile to the physical development industry.
But even with the “across the board” success agile is claiming, Ambler warns “keep in mind, your mileage may vary.”
Just because agile worked in situation “X”, is no indication that it will transcend into other industries, including yours – even if it is a related one. “Many have said to me ‘we can’t do agile development’ and I agree, they probably can’t, but only because there is a self-constructed boundary between their way of working and the way agile works. Agile was never intended to be an overnight fix. And those who believe it is a ‘silver bullet’ often end up shooting themselves in the foot. Agile needs both acceptance and time to work successfully, willingness of teammates and close quarters collaboration,” said Ambler.
So, once again the age old saying fits in patience is a virtue.
Fortify software, a security test and assessment service provider, now offers security testing and assessment for cloud-destined applications. Fortify 360 and Fortify on Demand services are available for cloud applications as of May 18.
“There are two promises the cloud makes to application developers and their consumers; access to a wider range of software resources and utilities, and having them available at a huge reduction in cost,” said Brian Chess, founder and chief scientist at Fortify. Security has been a primary concern in software from the get go. Chess feels that the cloud, though seemingly more secure on paper, will amplify latent vulnerabilities in applications. There are also concerns in the lack of standardization and measurement within the cloud. “Standardization – the standard of computation in [and out of] the cloud is a limiting factor. So far, we haven’t seen a lot published on how security will be provided and ensured. This may force many application developers to hide behind private clouds, or call for a double-scooping of firewall onto their code.”
In the cloud, pre-existing flaws will be easier to exploit and undermine. Problems will become obvious faster and accessible to much a vaster audience. In risk-prone applications, the possibility for eavesdropping on code lacking fortitude, could become a major issue in the future of cloud computing.
“DNS security has always been a security focal point in the Data Center, it is a known weak spot. But because the weakness is well known, with careful monitoring, organizations have made DNS issues manageable. The cloud however, poses some new challenges — not only do you need to be positive that your DNS security is top notch, now you need to be active and aware of who your computer is communicating with on a much larger scale,” said Chess, who borrowed examples from Apple and Microsoft to illustrate his point.
“Apple and Microsoft have been using automatic updates and automatic patches to fix flaws they’ve uncovered. These are prescheduled and normally occur at times users are not in front of their computer. Many of these updates do not require you to click ‘OK’ or accept that an update is being made. Imagine how similar ‘falsified’ automatic updates would work in a public cloud. They could open some rather large doors for your computer to become part of a Bot network or worse.”
Fortify will address these application security issues via two vehicles, 360 and on Demand. Fortify 360 is the full-scale version of the security testing and assessment provision from Fortify. It includes an assessment service, and a round of penetration, static, runtime and real-time testing. On Demand primarily allows just the penetration and static testing. Add-ons available to customize and add depth to your security testing requirements, but these come at a cost increase.
Fortify will use whichever service the customer chooses to test their application for security in the cloud. Upon purchase, Fortify enters into the application and subjects it to monitoring while they attempt to break into it. Through a partnership with White Hat, Fortify does not require that applications be brought in-house, they perform their tests online on their private network.
In the world of software, it’s always interesting to me to find out how closely the real world matches the text books. Many of the people I speak with are authors, educators or vendors and their point of view can often be quite idealistic. But does agile really work the way it’s described in the classroom?
Chris York, a 10-year testing veteran and four-year software developer before that, has his doubts. “I haven’t seen agile work like it’s supposed to; and after working with it for 18 months, I’m wondering if it does really work.” York knows that it’s been successful for others. We chatted in a Denver coffee shop trying to figure out why the agile project he worked on had such trouble. “We never got close to getting everything done in an iteration. There was no plan for what to do when something went wrong. There was no time allocated for fixing defects.”
York gives me more details of the first software project he worked on that was adopting an agile methodology. The team was co-located with about 20 team members, six of them testers. Other than a one-day training, the team members were not experienced in Scrum, except for the ScrumMaster who was brought into the company to lead the project.
York felt that, although the ScrumMaster knew the lingo, he wasn’t effective in leading the team. “I felt like I was in Kindergarten,” York said, explaining that there were one dollar penalties for all kinds of trivial transgressions including such things as being even two seconds late for a meeting, talking out of turn, having a cup of coffee, a cell-phone ringing, sitting during a stand-up meeting or deviating at all from the stand-up script. He said that team members were encouraged to express disapproval if someone didn’t meet their commitments from the day before too often. “It was also encouraged to try and find a way to get someone else to meet your own commitments for you. This happened on one occasion and it was applauded. Then the person who did the other work was chastised a bit for not meeting his own commitments. It just seemed very inappropriate.”
York describes a project that used a methodology that he helped create: a traditional-agile hybrid -and it worked quite well. “The company had a bad reputation with its clients and something had to change. Releases would take an entire weekend working around the clock. And even after that the product would be two to four weeks getting the bugs that the clients found worked out. We developed this iterative way creating a long term project (four to six months). Each iteration would be four or five weeks and it was highly planned out. After a couple of years of tweaking it, our reputation was good, the releases were smooth (only taking four or five hours) and very few bugs were found by the clients. We didn’t know we had created an agile-like development strategy. We just kept working at it until we found something that worked. The best thing we did was to write complete detailed requirements and then to spend time planning everything, even allowing time to fix the defects and retest them.”
York points out that he knows that agile can work, with the right project and with an experienced team. In this video he compares transitioning to Scrum to a developer making a switch from C to C++. Object oriented programming is a completely different mindset. If we aren’t used to it, we’ll fall back into our old structured programming habits. Similarly, those that find themselves thrown suddenly into an agile environment, may have trouble getting the full value of the methodology.
The lesson learned here seems to be the importance of flexibilty. Agile is not meant to be prescriptive, but adaptive. Each project, team and organization is unique. There doesn’t seem to be one right answer for a universal “best” methodology, but one thing seems to be clear: It’s important to consider the needs of the project and not try and force rules that don’t make sense because they are “agile.” That, in fact, would NOT be agile.
Robert “BJ” Reff is the director of Quality Control at Liquent, an organization that creates applications for pharmaceutical companies which enables them to track, research and submit information on FDA approved medications. On Lisa Crispin’s recommendation, I tracked Reff down at STAREast to pick his brain proceeding a session he had just delivered on Theoretical agile practices vs. real-world agile applications. For many organizations, finding new and creative ways to implement agile is welcomed and they are finding unique and intelligent ways to adapt the methodology to fit their needs — even in places where one wouldn’t think agile would be the methodology of choice.
According to Reff, agile can be applied to organizations that are regulated by agencies, such as his. The idea that the agile methodology won’t work in this kind of an organization is a common misconception within the software industry. Regulated industries and similar organizations are usually forced to adhere to restrictions, limitations and intense examination. As a result, these companies often exclusively reside in waterfall territory, but Reff feels there’s a place for agile within them.
Reff describes his session in this video clip from STAREast 2010
“In my experience, one of the major problems with the agile methodology is that people look at the process in line with what they need to accomplish and then they proceed to write it off, they brand it as too drastic a deviation from their organization’s accepted practices.” Management looks at the layout and examines the theory behind agile and decides that the principles are not applicable to what their corporate aim is.
“A lot of times agile is misrepresented as a lean way to create applications. Many believe this sort of construction isn’t suitable for regulated agencies such as the financial sector, government, airlines or medicine. These are all industries that exist in a world built around compliance and strict requirements. What I rarely hear is an organization considering modifications to agile so it can fit into their development.”
Despite often occurring in close quarters, agile and lean are very different. Lean in many cases, is the by-product of well-done agile. Through agile, waste, bottlenecks and other unnecessary hold ups become more obvious and easier to assess and repair. But there is more to agile than meets the eye and regardless of its surrounding hype, agile is not without flaws. There are problems with the methodology and with the people using it.
Reff identifies some of these problems as residing in unrealistic beliefs that many agilists harbor. They believe that agile will solve all of their problems. Others choose to believe that if they can’t facilitate the promise of fulfilled requirements, so the end result (agile or not) will be undeliverable iterations resulting in failure.
Many new agilists get stuck on the underlying principles and frustrate themselves in trying to fit agile into their traditional development process. A process they do everything to avoid branching away from; but that’s just it, agile is adaptive and should be treated as such. However, you shouldn’t just take anyone’s word for it. Qualify it, try it out.
Anticipated success or failure should not be based on what others have experienced, there is no proof without context. Comparisons need to be drawn. Two completed projects, one yielded in waterfall and the other in agile. Examined them side by side, then you can make an educated decision on whether agile is a fix for your organization or just another fad.
Our new open source software special report serves up articles on the latest open source tool trends, problems and successes in application testing, service-oriented architecture (SOA) and Windows environments. We created the special report in tandem with our sister sites, SearchSOA and SearchWinDevelopment.
We thought it would be interesting to find out what the users and experts are saying. Watch the following videos to find out.
Did you know that methodologies like Extreme Programming and Scrum were around before they were labeled as “agile”? At the SQE Agile Conference I attended in Colorado Springs, technical evangelist Jeffrey Fredrick gave a presentation titled: “The Co-Evolution of Agile and Continuous Integration.” He took us through agile development’s historical changes in methodologies, noting that, likewise, organizations go through an evolution, too, as they move into agile adoption.
Listen in while Fredrick summarizes why the evolution of continuous integration and agile over time and as conference attendee Geri Carolan gives her reaction.
If you test web applications across many platforms and don’t use Selenium, a suite of open source tools, you’re missing the boat, says software test expert and author Adam Goucher. In this post, Selenium expert Chris McMahon shares his recent conversation with Goucher about Selenium’s benefits and uses. They also discuss the benefits of using Selenium, the “Selenium value chain,” and Goucher’s projects: an upcoming Pragmatic Press book about Selenium and company that builds custom plugins to IDE.
The conversation is a meaty one, because both Goucher and McMahon are deeply involved in testing and Selenium. Goucher is co-editor of the book, Beautiful Testing. In February, 2010, McMahon and Marisa Seal released their open source creation, Selenesse, a toolset that bridges FitNesse and Selenium.
Let’s listen in on their interview:
McMahon: Adam, what is Selenium, and what makes it so special that you’ve decided to write an entire book about it?
Goucher: Selenium is, at its core, a set of tools which let you control a browser. What you do with that control is completely up to you. Some frequent fliers use it to reserve aisle seats on their flights, but the majority use it as part of their testing process. After all, the end user of your product is not going to be experiencing the product through their browser as well, not via some wire-line unit testing framework.
What appealed to me originally with Selenium was its ability to control different browsers on different platforms. This was important as I was working at HP at the time and needed to support browsers on Linux and three different variations of Windows. Being open source meant that the price was certainly right and having the source available meant that it could be tailored to any environment.
McMahon: Why did you see a need for a book about Selenium?
Goucher: I’ve been a professional tester for 12 years now and have started to reach the point where I enjoy the teaching and knowledge transfer more than the actual bug discovery. (Shh! Don’t tell anyone that.) What I see in the Selenium community is that people don’t use the suite to its fullest. I’ve been using Selenium for almost four years now and have figured out how to succeed with it. While I tend to blog (http://adam.goucher.ca) about these discoveries, the reach of my blog is limited whereas the reach of a book from Pragmatic Press is far greater.
McMahon: The Selenium Integrated Development Environment (IDE) is the tool most people start with when they want to use Selenium, and you’ve been making improvements to the IDE. What is so attractive about Selenium IDE that you’ve devoted so much effort to it?
Goucher: One of the “Eureka!” moments I had about Selenium is that the sum truly is greater than the individual parts. I’ve started calling this the “Selenium Value Chain.” It starts with IDE, moves along to Remote Control (RC) and then ends with Grid. As you pointed out, a lot of users get their start with Selenium through IDE so that part of the project needs to be active to keep up with dependencies such as new browser versions.
But the emerging commercial and open source ventures starting to use Selenium as their core product offering rarely include IDE. I realized that this was because IDE was not very business friendly in its current state, and it occurred to me that the solution was to emulate the Firebug experience. Firebug is powerful in its own right, but it gets insanely powerful when you start to add Firebug plugins (like YSlow) into it.
This is the future of IDE; a powerful plugin architecture that lets others add even more power onto it. Jason Huggins and Patrick Lightbody both agreed with this vision but were unable to commit time to do it themselves, so in true open source fashion, I had to do it myself. Jason’s company, Sauce Labs did, however, fund it.
McMahon: How did you get involved as a contributor on the Selenium project?
Goucher: The irony of my involvement with IDE is that I spent a large portion of 2009 campaigning to have it neutered to force people into using RC faster. The dirty secret with IDE is that it can’t reach into the database, do if/else logic or loops — well, not elegantly at any rate. Meanwhile, RC lets you use a number of full fledged programming languages to make your scripts more useful and effective. And now, less than a year later, I have started my own Selenium-based company, called http://element34.ca Element 34, that will build custom plugins to IDE, among other things.
McMahon: Will your Selenium book be aimed at beginners or at experienced practitioners? Will it be a straightforward technical manual, or will it also treat the history of Selenium and the place Selenium occupies in the ranks of other similar tools?
Goucher: The book is very much in the initial stages of work; but the plan is to have it be very tutorial in nature and follow a project from the start of the Selenium Value Chain to the end. Pragmatic Press models the voice of their books around the ‘hero’s journey,’ where the reader is the hero. I’m not going to write it with a single type of user in mind, but instead so that anyone can read it and be a better user of Selenium.
Woven in will be my experiences in how a script evolves — Basic -> Data Driven -> Model Driven — and how to solve common, but difficult, scripting problems. Right now, I’m planning on sections dealing with things like Flash/Flex, HTTPS and parallelism, for instance.
But Selenium is so large in the problems it can solve that I recognize that I won’t be able to cover everything. And some things, like writing IDE add-ons, are too narrow in audience that it would have to be a very specific hero, rather than a common one participating in the journey. A commentary on the open source browser drivers and the intertwined relationships between them all is also out of place for this type of book. The plan is to be in the tools and creating stuff right from page one to the very end. Someone else will have to pick up that part of the story.
Adam Goucher explains his role when it comes to using Selenium
Most people who are in the Software Test and QA industry know who James Bach is. He’s an outspoken rapscallion and makes no apologies about it. In fact, he’s proud of it. In this morning’s keynote, Bach told us about what it means to be a “buccaneer tester.”
“Challenge the system,” says Bach. His motto, whether he’s talking about rigor in exploratory testing or teaching what is meant to be a buccaneer tester, is to think. Don’t just mindlessly follow authority and do something because it’s the way it’s always been done.
Listening to Bach is very entertaining. He’s funny, dynamic and energetic in his descriptions of his experiences and his advice to go against the norm. I especially like it when he goes into his “authority figure” voice, showing how an authority figure might demand that we follow rules in a way which would makes us obsolete.
“You might think there’s a council of elders who gets to decide who’s an expert,” Bach said. He reminded us continually that we set our own path. Find what makes us unique and valuable, he said. If we only follow checklists or best practices without questioning the norms, we are no better than computers or robots. We need to use our brains, our experience, our knowledge to bring unique value to our jobs.
Bach advised: “Find the mix of interests and talents that makes you have what no one else has. Take stock of this and find a story that makes you important and special.”
Bach described three resumes he’d received. Two of them were full of buzzwords. When asked about them, the candidates clearly did not know much about the meaning of those words. The third resume was simple in language; but when interviewed, the candidate showed an energy and understanding that was impressive. He was the one, of course, who was hired.
Bach talked about the difference he sees in people that demonstrate passion and question themselves and others — people who don’t just blindly accept what others say, but who go out of their way to dig deeper than the surface and earn a reputation for a person who is continually learning and growing. He specifically called out Lanette Creamer as an example of a person who was making a name for herself by living by these values of questioning the norm. You can read more about Lanette Creamer’s work in two SearchSoftwareQuality.com article, Test-driven testing face-off: Waterfall vs. Agile and Testers debate differences between Agile and waterfall test automation.
Check out what James Bach had to say about STAREast and being a buccaneer tester in this video.
For more STAREast coverage, check out these links:
James Bach – The buccaneer tester
STAREast keynotes: Continuous integration and documentation in Agile
STAREast: Is your software development organization agile?
Agile practices, including continuous integration and documentation in agile environments, were the kick-off topics at STAREast in Orlando, Fla., today.
I’ve been sitting here in the second row of a ballroom at the STAREast conference with the Rebel Alliance. We’ve been listening to two keynote speakers, Jeff Payne and Elisabeth Hendrickson.
Payne started his presentation — “You Can’t Test Quality into Your Systems” — talking about some of the changes we’re seeing in development, asking if they were fads or trends. Fads come and go, but trends “change the way we work,” he said. Obviously, agile development is one of the trends that he mentioned and we are hearing about a lot in the industry.
“Continuous integration is HOT,” said Payne as he spoke about SecureCI, which is an open source tool which integrates several other opensource tools. Continuous integration is the “hub” that ties together development, test, release engineering and management.
Payne quipped that developers originally made up agile as “retaliation of quality people” to get auditors out of their hair. Then the developers found out that, indeed, they’re not off the hook for unit testing and documentation! There’s actually a lot of “rigor” in agile done right. Payne said that people often think that agile means “no documentation.” A common misconception is that you can’t use an agile approach when documentation is required due to regulation. However, if documentation is a requirement, then that documentation is included as a high-priority story in agile. Payne gave an example of a project in which the documentation was stellar, impressing the ranks. When they asked about the methodology, they were told “agile!”
Hendrickson spoke next on “Agile Testing: Uncertainty, Risk, and Why It All Works.”
When describing documentation, Hendrickson hopped all over the stage imitating all the various documentation that needs to be updated in traditional environments. As she described her frustrations, she joked about a product she once tested using Excel as the documentation tool: “I found more bugs in Excel than in the product I was actually testing.” She described the documentation process as “exhausting.”
One of the concepts used to boost documentation efficiency, Hendrickson said, is Acceptance Test Driven Development (ATDD). With ATDD we get the shared understanding of what we’re building and can automate expectations. Hendrickson talked of an “executable specification” saying: “We finally can actually do it. We have real evidence, executed running testing features.” ATDD provides leveraged documentation resulting in executable requirements.
Hendrickson described how much more quickly feedback is received with continuous integration and automated regression. “The automated system level documentation reduces the feedback latency to the time the developer checks in code until there is evidence that the code works.”
Both keynote speakers seem to agree that they’re seeing usage of agile development growing rapidly. Learning how to take advantage of continuous integration and using documentation efficiently are two practices that they see adding to the success of agile projects.
For more STAREast coverage, check out these links:
James Bach – The buccaneer tester
STAREast keynotes: Continuous integration and documentation in Agile
STAREast: Is your software development organization agile?
Survey results from a study on modernization strategies from IT leaders were released April 26th, 2010, in a special report, “Clearing Your Path to Modern Applications and Business Agility.” The survey and report were put out by Forrester Consulting and commissioned by Hewlett Packard in January, 2010. Targeted organizations included over 200 companies in North America, Western Europe and Asia Pacific. The targeted companies were noted as “significant IT shops” with 61% having budgets of over $50 million, spanning a wide range of industries, stated Phil Murphy of Forrester in a pre-announcement press release on April 23, 2010.
The report was aimed at finding out what was driving folks to modernization and exploring the barriers they were encountering.
Barriers to application modernization
Primary challenges impacting application development productivity were complexity, cumbersome end-to-end application development processes and difficulty in changing legacy applications.
The three top reasons applications were being considered for retirement or replacement were obsolete technology, the application no longer met business needs and the application was difficult to maintain.
However, the biggest barriers against modernization were the business user’s insistence that they needed the legacy applications and that the development teams were too busy doing other work.
A significant 91% of respondents agreed that they would benefit from an application consolidation/rationalization effort.
How are firms approaching modernization?
Initiatives to improve application productivity included improved SDLC processes, reducing reliance on legacy applications and platforms, formal application portfolio rationalization and improved SDLC Tools including software testing tools.
Primary drivers behind modernization were increased agility, innovation and cost reduction.
Regarding methodology adoption, iterative methodologies such as RUP and agile methodologies such as Scrum showed primary adoption. The survey also showed a 26% adoption of waterfall, which Murphy explained was due to “some of the smaller firms that had zero methodology are adopting a methodology and waterfall is the one that they’re choosing.”
What results have been achieved?
For those firms that have adopted an agile approach, the most significant improvements noted were in productivity, quality and time to market. “Clearly the adoption of agile has had an effect on success rates and ways we normally measure success,” said Murphy.
When asked about the effectiveness of initiatives to improve development productivity, 74% responded improved SDLC tools, including testing tools as contributors. Improved SDLC processes, including software testing processes were also listed by 70% of respondents as contributing to the improvements.
Murphy compared the barriers of modernization to a three-headed beast, listing bloated portfolios, obsolete tools and practices and excessive “lights-on” costs as the three heads that all needed to be conquered. Fighting one head leaves you vulnerable to the other two. Though 91% of respondents agreed that they would benefit from a formal retirement program, business users are reluctant to let go of legacy applications. However, modernization efforts that have taken place are showing productivity gains from SDLC tooling, SDLC processes and application rationalization.
Murphy concluded, “You have to clean out that portfolio so the overall lights-on IT costs come down.”