Agile software development

Ways Agile beats waterfall development, boosts software quality

“How many of you are agile-ists?” Agile expert and author Damon Poole asked attendees this at the SPIN local user group meeting near Boston this week. Then he said: “Agile-ists look like normal people… but if you don’t believe in agile, let me assure you, there is nothing wrong with you.”

Poole gave various examples and analogies of how agile development methodology works, noting that group involvement was a key of agile success. Agile developers benefit from receiving more frequent feedback from customers and having short-term, reachable deadlines, Poole said.

“Agile versus waterfall or any other methodology can be compared to touchdowns versus yardage,” he said. “Where is the credit given? Clearly you can’t win the game based on ridiculous yardage without scoring.”

This analogy points to the major downfall of waterfall, a process in which the team scrambles in all different directions and gains some ground, but often fails to complete the project on time. Agile, he said, is different; you set reachable goals for short phases, or iterations, of development.

This process of “continuous integration” involves completing one set of functional code, getting feedback and then adding new coding to it and retesting. Doing projects in phases assures a higher quality because of multiple tests and retests carried out during the SDLC (Software Development Life Cycle).

“With agile, there is an absence of confusion,” Poole said. “Do you guys remember the childhood game ‘telephone’?” As nearly every hand in the room went skyward, Poole smiled: “How did that game go?” The audience chuckled, and appeared follow his point. If one person tells a group a direction or a goal and the group collaborates there is less chance for project digression. The project is more likely to be what the customer is looking for which is the equivalent of success.

Agile doesn’t only benefit the industry or a company alone, Poole concluded. It also can benefit the individual. He listed these benefits for the agile team member

1. Less cancelled and or shelved work
2. Less pressure or stress over project duration, especially during crunch time as testing is done throughout SDLC
3. More individual ownership and feeling of involvement in a project
4. Increased project success

Poole frequently repeated the phrase, “the simplest thing that could possibly work.” Agile is the simplification of complex tasks, he said, satisfying the customer today and tomorrow, allowing for full software development team collaboration and good returns on investments.

<
Boston SPIN presenter, Damon Poole (on right) speaking with SearchSoftwareQuality.com contributing writer Matt Heusser

Why waterfall developers still shun Agile

Jon Kern, co-author of the Agile Manifesto, told me recently that many companies won’t adopt the agile development methodology soon. Why? Some companies are doing just fine with waterfall, he said, because it has worked in the past and is still working. Also, they see little chance that their business analysts and leaders will agree to get involved in the development process.

Intrigued by Kern’s assessment, I asked some software development and testing veterans for their views. I asked about their work with and opinions on why companies stick with waterfall development.

It’s true that waterfall methodologies can work quite well, said Mike Kelly, a software testing and development consultant and a fan of the agile methodology.

“I know this will surprise some people, but I’ve worked on several successful waterfall projects,” Kelly said. “It’s crazy, I know. Seriously, I’ve been a member of teams that do roughly the same thing, with minor variation, again and again. The business context is well understood, the requirements are mostly right upfront, and the team kind knows what needs to be done to be successful. If it’s working, it might not make sense to change it.”

Bernard Golden — CEO of IT infrastructure consulting firm, HyperStratus – has worked with development teams that don’t think the agile methodology can be effective in large-scale, enterprise projects. They think that agile is a good micro practice that should live within a good macro project management/planning process. To an extent, he agrees, and thinks agile is “best suited for scoped projects that have small user populations — built on top of robust system infrastructures built as traditional projects.”

Golden is also doubtful that having a “business person be part of the development process ensures that systems will achieve user satisfaction.” Thinking that “one guy can subsume all end user viewpoints and prevent end user political unhappiness strikes me as quite naive about the way organizations works.”

In this short video clip, Golden explains more about why agile may not stack up.

Kelly has also worked on projects where business managers just didn’t want to do more than turn in a list of requirements. “The business [people] didn’t get into business to talk about development methodologies, and to them, it’s often a distraction,” he said.

Requirements analysis expert Robin Goldsmith believes business managers don’t believe that doing systems work is their job.

“Agile is very much driven from a programmer’s perspective, and business folks don’t identify, understand, or agree with it,” said Goldsmith, president of the consultancy, Go Pro Management Inc. “ As an analogy, I have many years of experience working in the most technical of programming roles within IT; but these days I have no interest in fooling around with software internals—I just want stuff to work, and that’s not unreasonable.”

Goldsmith sees the agile-versus-waterfall debate as the subtext behind a larger business-versus-IT cultural issue that causes continual problems for software projects.

Do you agree? I’ll be continuing this discussion with software testing and development experts, and your input would be very valuable. You can share your experiences and views by commenting below or writing to me at  jstafford at techtarget.com.

How app visualization enables picture-perfect requirements

Readers of Mike Kelly’s post on software security uses for data visualization –- the ability to visualize patterns of data –- asked us for info on application visualization, too. Application visualization enables software developers, testers and users to see and interact with a fully functional prototype or simulation of a proposed application before coding. We’ll be covering both visualization topics more in this blog and on SearchSoftwareQuality.com.

In this post, I share excerpts from my interview with application visualization expert, Maurice Martin, president, COO and founder of iRise, a maker – of course – of application visualization products.

Developers and business analysts seeking to get software requirements right will find visualization far more effective than text documentation and diagrams, according to Martin. Planning to visualize applications in high fidelity before coding can ensure that the right requirements are captured early in the process.

Imagine giving stakeholders a fully-functional, working prototype early in the process; development teams can secure the right feedback early in the process, before any expensive coding happens.

“Instead of a stakeholder review meeting where everyone is flipping through giant binders of text requirements and struggling to understand what’s been written, now everyone can ‘test drive’ the application live,” Martin said. “The magic happens when changes are made to the visualization right in the stakeholder review meeting, cutting days, weeks or even months off the requirements cycle time.”

Application visualization is a paradigm-changing technology and approach for software development, in Martin’s opinion. Business analysts are no longer just reviewing text requirements, they’re “now rapidly iterating functional prototypes directly in front of the business stakeholders,” he told me. The result is quicker capture of more accurate requirements for designing and developing code, building test scripts and writing documentation or training content.

Until business analysts, developers and users can see, interact with and fully experience the application, they can really only guess at the requirements, Martin said and then continued, saying:

“Add to this the fact that the tools and processes used by most BAs are antiquated at best, and it’s no wonder project overruns, delays and missing features are all-to-common outcomes. The sad truth is this: the state-of-the-art in requirements definition for many organizations is still a giant text document, maybe annotated with a few static screen shot mock-ups or use case diagrams. Let’s face it, the cycle times to create these documents are long and the business stakeholders don’t understand –or read — these giant binders. This would be analogous to designing a new car, airplane, building or semiconductor today with a drafting board. It simply doesn’t happen in other industries; why are we still designing software this way?”

Visualizations can provide guides for what to build, eliminating confusion and enabling developers to focus on what’s important; architecture, design, coding and delivery, Martin said. He’s found that visualization can cut down on change orders and eliminate about 70% of downstream rework. In short, visualizations forces the business to articulate what they want in a language everyone can understand.

Blu Age at EclipseCon: On agile, an agile project, reverse engineering

On the eve of EclipseCon in Santa Clara, CA, which opened today, I interviewed NetFective Technology Group president Christian Champagne about agile adoption and legacy application reverse engineering, as well as a legacy app makeover that Blu Age Corp., a NetFective offshoot, helped a company do.

Today at EclipseCon, Blu Age introduced new tools — Blu Age Reverse Modeling and Blu Age Modernization –- to its product suite for reverse modeling and re-engineering legacy enterprise applications. These products complement existing modules, Blu Age Build and Deliver, and together they make up a platform for transforming existing code and data into UML 2 models independent from their original technological platform and according to the Object Management Group’s Model Driven Architecture (MDA) standards.

In our interview, Champagne said that there is about an even split between waterfall and agile model users today, but he sees more and more waterfall users evaluating agile. Just as the economic downturn spurred IT managers to use virtualization to consolidate servers, he said, development groups are turning to agile “to become far more efficient, not only for a better return, but to keep their job or survive as a company.”

Champagne sees agile’s iterative development model as the cornerstone to implementing more effective software testing and quality assurance (QA) processes. At each iteration, testing and QA ensures that expected business needs are properly covered, and the next step or iteration of development isn’t started without full acceptance of the current one.

“What is important is that users directly approved the application during the development phase and not when development is almost finished and the budget already consumed,” Champagne said.

Champagne described a recent project in which a Blu Age team helped a company move a legacy application’s existing code and data into UML 2 models. The primary project goal was modernizing the application and enabling use of the agile process for reverse modeling. The company didn’t have an out-of-box software package able to modernize the application to meet all functional and architectural requests. After evaluating several options, the company chose to do PIM extraction with Blu Age’s MDA workbench.

The project’s biggest challenge was changing the mindset of IT and business people.

IT people have to admit that techniques and standards can automate 90% of their traditional activities except the value added ones, like enterprise architecture. Business people must admit that they have to be responsible for the application they ask to be developed. Automated and instantaneous model transformations with agile put business people direct in front of their needs, and they could not anymore claim against IT for bad delivery. Both must admit that they have to work together but both must manage acceleration of application development deliveries.

Once everyone was on board, the project moved forward quickly. The result, said Champagne, is “simplified project deployment, mainly due to the fact that agile and iterative AD facilitate end-user acceptance and increase functional accuracy of business-oriented applications.” Project delivery time was cut 50%.

This project spurred the company to move from waterfall to agile development overall. “At this stage, 60% of their new devs are agile, whatever the size — 300 Man/days up to 3000 Man/days,” Champagne said.

Looking ahead at trends in development in general, Champagne foresees growing usage of powerful but simple-to-use languages like PHP5, as well as automated software packages that can handled complex business needs with SOA (service-oriented architecture), Web services or RIA (rich Internet applications). Overall, he sees developers changing their ways of working and their roles in projects as iterative development is widely adopted.

Agile, management tools help small team boost software quality

Scheduling, documentation, tracking bugs and –- most critically -– producing great products with a small development staff are the headaches Dan McRae, Comet Solutions Inc.’s software engineering manager, faces every day. I talked with McRae recently about how he’s combined best practices and lifecycle management products to get the upper hand on quality assurance (QA) and deliver strong products on deadline. Indeed, Comet estimates that these tactics have improved software quality by 25% and time-to-market by 10 to 20%.

McRae oversees a team of about 10 developers, two of which are dedicated to QA, although all do some QA work. They produce about four major and four point releases each year for Albuquerque, N.M.-based Comet, which provides design engineering workgroup software primarily aimed at enabling early simulation.

“Our biggest challenge is that we only have two full-time QA people,” McRae said. “The rest of us generate more features than they can thoroughly test. As manager, I direct what QA’s focus is. Some of those directions are based on word of mouth from our developers; but I also get direction from our chief technical officer, who points to things that are high-risk and need to be addressed. There are always challenges because there are always the latest defects that have the highest priority, and several of those pop before you can fully QA the previous ones.”

Comet’s development team uses agile development and automated tools to reduce the development and QA burden and improve quality overall.

Using waterfall methods for product development became very difficult as software and users’ needs became more complex. Under waterfall, it took too long to handle customer requirements and changes. Today, McRae’s team uses such agile techniques as daily standups to discuss current relevant issues, working on a two-week iteration and having release planning meetings based on Scrum practices.

While moving to agile processes, the development team found that its homegrown tools couldn’t evolve to improve the team’s ability to track defects, feature releases and scheduling.

“We had been using a home-concocted system for tracking defects and feature requests internally ourselves, and it wasn’t able to help us keep up with changes in customer requirements or QA,” said McRae. “That system didn’t have scheduling abilities, so planning was done on a kind of ad hoc basis.”

After scouting around for better tools, Comet’s team did a trial run on Rally Software’s Agile lifecycle management solutions. The trial led to adoption.

“Rally gave us a more robust system for defect tracking and feature request tracking. It also added scheduling, so we can schedule our development efforts, give a structured process to the collection, evaluation and implementation of feature requests as well as defects,” said McRae. “That gave us the opportunity to look ahead and plan our time out, knowing what features could be done in what time. Rally provided us with flexibility to swap and replace as needed.”

Today, when a new business need arises while development is in progress, McRae can look at the project plan in Rally and “see that we need to add certain features that require certain resources and determine what we can take out that was equivalent. Rally gave us the platform for making that judgment call without the guesswork that was part of the process before.”

Though the team has made great productivity gains, there are always improvements needed. Documentation is one area “that’s always a challenge,” McRae said.

“Any released software needs documentation, but if you don’t have a functioning product then documentation isn’t worth anything. There’s always the balancing act between building features and working on the product and trying to find time and the appropriate resources for the right level of documentation to be done. It’s something we don’t have a specific process to handle yet.”

McRae plans to look at Rally’s features to get some documentation metrics, such as finding which user stories and defects were completed. But he’d love to get his hands on an automated documentation tool. Any suggestions?

Using EVM in waterfall, agile software projects: Hows, pros and cons

In my work as a project manager, test manager and consultant, I’ve often used the earned value management (EVM) technique to provide status reports during project execution cycle, among other things. In this post, I share some of the things I’ve learned about it, hoping to help people who have found it difficult to use EVM on software development/testing projects.

I’ve found that EVM can a very useful technique for software development and testing projects. EVM shows how the budget, resources and time is being spent on the project and if the project is going in the right direction. It also shows what correction could be needed to bring the project on the right track. Without EVM; project tracking, monitoring, control and reporting is done on an ad hoc basis. Nobody, including the project stakeholders and the project team itself, knows exactly where the project is or where it is heading to; at any given time during execution of the project.

In EVM, the stress is on project baseline. Before the start of the project; a baseline project plan is developed. At this stage all steps, tasks, resources, time duration for execution of each task and budgets are determined. From this baseline, values for budget, time and resources utilized for each project task is compared when the project execution progresses. This comparison provides information as to whether any task is consuming more or less budget, time or resources compared to the corresponding planned baseline values. These values are also compared for the entire project as well. This information helps in tracking and controlling projects.

One challenge with EVM is that it doesn’t work when requirements are not clear or well defined at initial stage of the project. When requirements keep changing during the software development/testing project, you can’t set realistic baseline values. If the baseline values are not realistic, then EVM method can not work.

EVM can be successfully implemented on software development/testing projects. Suppose we are following the waterfall model for the project. In this case, most of the things for the project are fixed in the beginning of the project. That means we have good baseline figures for the project which will not change. In such a case, EVM can be implemented.

Now, let’s talk about EVM and the agile model. Suppose we have realized that a lot of changes will take place in requirements through out the project. Due to changes in requirements, the project plan will also keep changing to incorporate changes required in different phases of the project due to changes in requirements. So we have no option but to follow an agile method for our project; but how can we have a realistic baseline defined for our project? There are two approaches:

• In one, you have a project where requirements keep coming and are integrated into the base application model; in other words, an incremental integration model.
• The other model is the incremental iterative model, in which requirements are grouped into separate small sets. Branches in the main application are made, and a new build is made in each of these branches to fulfill these sets of requirements.

In case of incremental iterative model, we can divide all requirements into manageable groups. Then for a set of requirements, we can make a branch of the base application model and develop this branch as per requirements. We can have several branches of the base application model, and each branch will be further developed using a set of requirements. This way, each branch will have a set of requirements for which all phases of the projects will be well defined. No changes in requirements are allowed in this branch until the iteration is complete.

In case of incremental integration model, the additional design is made based on new requirements. Thus the new design and the new code developed in the next release of the software go directly to the main build.

Using these methods, we are freezing the requirements and thus we can make a good baseline for each of these small iterative projects. We can now easily set budget, timelines and resources for each of these smaller projects and each of the tasks associated with these projects. When the project execution for these iterations starts; we can easily track and monitor these projects.

Finally, there’s another situation in which EVM EVM is relatively simple to implement: software projects using commercial-off-the-shelf (COTS) software. Here if customization of the software package is not required or very minimal, then the project team mostly has to deal with tasks like installing different modules of the package, configuring different modules of the package as per requirements, creating data and finally testing the entire implemented system. In such a scenario, software development is minimal and most requirements are not prone to change. This makes EVM implementation on such projects viable.

Summing up, I advise project leaders to check out EVM. In my experience, software projects often fail because of requirement creep. Using EVM will make software projects manageable and reduce the chances of project failure.

Best practices for requirements in agile: Forget about agile

Yesterday I got together with Robin F. Goldsmith, president of consultancy Go Pro Management Inc. and our resident requirements expert, and asked him, “What are the best practices for gathering requirements in an agile environment?”

His advice? Don’t worry about how agile methodologies change the requirements gathering process. “The best practices for gathering requirements are the same regardless of the methodology you use,” Goldsmith said.

Goldsmith went on to explain that agile isn’t necessarily a totally new way of doing things. “The premise of agile development is to focus on very small pieces and get them done. To my thinking that has always been the approach people have used when they’ve gotten things done,” he said.

The hard part is figuring out which pieces to work on, and for that you need “a structured and systematic way of understanding the big picture,” he said. “So the starting point for meaningful requirements discovery is to start at the top, to get the big picture. Then you analyze and prioritize and select those pieces that you want to drive down to more detail.”

According to Goldsmith, one of the common traps that IT pros fall into when discussing requirements is wanting to provide a solution — a product or system — before determining at a high level what the business really needs. Agile can actually exacerbate this issue.

“The problem with agile development is that it’s driven by a programmer, and the programmer doesn’t know to find out about business requirements. The programmer wants to find out what program they should write,” he said. “The context that they’re in, especially driven from the programming perspective, pushes them into saying, ‘What do you want me to build?’ not ‘What should what I build accomplish?’”

To complete any software project successfully, you need to work closely with your users and help them “understand what they need to accomplish before they try to settle on a solution,” Goldsmith said. “That’s true whether it’s agile or any other methodology.”

Got a question about requirements? Submit your question and Robin Goldsmith will answer it in his Ask the Expert section on SearchSoftwareQuality.com.

How to maintain software quality, complete projects in a recession

Software consultants, vendors and project managers are already seeing software project failures and slowdowns resulting from the new recession.

That finding and the advice for software developers and project managers offered in this post comes from interviews I’ve recently conducted with 13 software industry experts and the blogosphere.

“Companies are panicking due to the economy. They’re compressing projects and schedules. As a result, key projects are failing,” Lawrence Oliva — senior consultant/program manager with CH2M HILL, an Englewood, Colo.-based engineering and program management firm –- told me in a recent conversation. “In part, this is the result of trying to get things done faster with less resources.”

Consultants are seeing reductions in software testing being used to cut costs. That tactic is a recipe for project failure, said consultant Karen Johnson in my recent post about why software project fail.)

My sources also spoke of seeing several large, current software projects in crisis mode because senior developers were laid off and the remaining, less-experienced developers didn’t have the know-how needed. Unfortunately, many development groups have been running lean for a long time and running leaner pretty much means stopping development.

“Lean computing is nothing new,” Oliva said. “Companies have been operating at skeletal levels since the economic downturn of 2000, when that downturn caused intense development staffing cuts. It really is sad to think about having to be even leaner.”

That’s the situation, but it isn’t hopeless. Gleaned from my interviews, here are some tips for maintaining software quality and project success during this recession:

Analysts and others advise development teams that lean computing and the agile model can help them do more with less.

Some companies have already made this move and feel ready for tough times. For example, Des Moines, Iowa-based Principal Financial Group –- which provides software products for the financial industry — uses the agile model and has standardized project management, testing and quality assurance processes and tools used by all its development groups.

“Standardizing has reduced redundancies in tools, processes, documentation and more, running as lean as possible,” Principal’s senior IT system analyst Mark Ford told me. Principal uses HP Quality Center to manage development.

Project managers whose companies have not already made cuts to development staffing or budgets need to advise decision-making executives about the business benefits of their projects, industry insiders advised. Also, when cutbacks have taken place or are proposed, PMs need to explain the business impact and guide where the cuts will be made. IBM’s director of Rational offerings, David Locke, offers this advice:

“Always talk in the context of how the project will help the business. If I take this 10% off, I will have the least impact on the business. Give real information, not data. Remind managers that the company creates software to make our businesses more streamlined, more competitive and to deliver better ROI. Your company may need immediate cost savings, but eliminating software that could give the business the most cost-effective competitive edge is probably not the way to go. Talk about business impact, always.”

This is certainly an appropriate time for PMs to push for investments in software testing automation tools, like automated code checkers, experts told me. However, Oliva added:

“Don’t trust in those automated systems absolutely. You could get the wrong results from the use of automated systems.At some point human beings have to be involved. Delivering quality software is not a machine-to-machine process. Not having quality monitored and managed by humans is dangerous.”

Another suggested labor- and cost-saving move is adopting streamlined models of programming, like Extreme Programming or Structured Programming.

The most important strategy for weathering the recession is becoming more realistic about software needs and reducing complexity of software. “If companies do this, it could be the one good thing that comes from the recession,” Oliva said.

Continue the conversation: Please tell me what adjustments you and your development team are making to deal with the tight economy. You can respond by commenting below or writing to me at editor@searchsoftwarequality.com.

Here are some resources for more advice and information:

• Find out what this software developer did when his project’s staffing went south in Survivor’s lessons in test management.
• There are many links to articles on the recession’s impact on software projects in this blog post which offers advice on succeeding during a recession or anytime.
• Ryan Martens writes about how to make good staff reduction decisions.
• In this article on project management, Lawrence Oliva discusses
  the economy’s impact on software projects and strategies for PMs.

Security flaws and Agile boom top software quality news in 2008

Security vulnerabilities and the boom in Agile development adoption topped the SearchSoftwareQuality.com news charts in 2008. Here’s a rundown of the five most-read news articles and their significance.

Three of the top five articles focus on Agile development. In the #1 story, Predicting software quality trends for 2008, software quality experts predicted that Agile adoption will increase. Two other articles in the top five were about Agile. In fact about one-third of the top 20 news stories were about Agile.

Agile development: Not just for ‘agilists’ anymore (#4) discussed Agile’s move outside of its early adopter niche and the impact of its wider usage. Next came Software development groups take many routes to Agile (#5) which revealed results of SearchSoftwareQuality.com’s 2008 Agile Trends Survey. Most Agile technique users, according to that survey, use Scrum (41%). Next in popularity was Extreme Programming (XP) at 15%. Others use hybrid Agile methodologies, while about three percent use Crystal and Dynamic Systems Development Method (DSMD) each.

The SSQ 2008 Agile Trends Survey showed that 45% of software pros follow Agile methodologies, while 44% use waterfall. Other development methodologies cited were test-driven development (19%) and RUP (15%).

Security flaws in leading open source software platforms drew a lot of attention, and articles on security issues in the Spring Framework and open source Java projects ranked in second and third place, respectively.

While open source development projects typically fix flaws quickly, as happened in these cases, the emergence of serious vulnerabilities may have taken some IT pros by surprise. People expect problems with Microsoft products, but not with open source products, said Kevin Beaver, CISSP and Principle Logic LLC consultant, commenting on the fact that these two stories got so many clicks.

“We’re seeing more and more that open source has its own security woes,” Beaver said.

Don’t blame the open source community and its developers, Beaver advised.

“The fact is that as long as human beings are developing applications on the complex and extensible OS (operating system) architectures we have, there will be security problems.”

Most importantly, he said, the emergence of vulnerabilities should not scare anyone away from using open source software like open source Java or the Spring Application Framework.

It is important to point out that just because a static analysis tool vendor finds flaws in open source code, that doesn’t mean the vulnerabilities can/will ever be exploited.

Keep using open source software, Beaver concluded, and “take this marketing tactic with a grain of salt.”

Now that you’ve checked out these stories, please let me know your choices for the top software quality news stories of 2008. You can write to me at  jstafford at techtarget.com.

Open source, agile help move to lean software development

Bloated applications, platforms and architectures slow application development and make quality control and everyday usage time-consuming and nonproductive, said Forrester Research principal analyst John R. Rymer in a phone conversation yesterday. In this post, I’ll share Rymer’s thoughts on why software pros should join the lean software movement and his advice on how to create appropriately sized and efficient software. 

Forrester’s newly-published report, Lean Software is Agile, Fit-to-Purpose, and Efficient, lays out how software got so fat, costly and inefficient; the evidence that IT organizations are moving to lean software; the challenges involved in lightweight software development; and strategies for joining the movement. Rymer told me that the demand for lean or lightweight software is coming from conventional business application users, the ones who first signed up for mainstream — and now bloated — apps from IBM, Microsoft, Oracle and other major software vendors. Many took the path of least resistance, as in following the safe IT path that spawned the saying: “Nobody ever gets fired for choosing IBM.”  

While major software vendors piled on features that add complexity and can foster customer lock-in, in came the lean software approach of Linux and open source developers. 

“Open source is the driving factor for lean computing,” said Rymer. “Now people can replace conventional application servers, for example, with open source application servers and get lower cost and more innovative features. People are comfortable with open source software, which is now in its second wave of adoption.”  

Agile development is another popular path away from traditional “big-bang” software development.  

“Agile development is independent of any technical platform or development approach,” said Rymer. “It’s a method. What’s neat about this is that people are delivering application features sometimes every two weeks or each month. Rather than deliver the big-bang project after years of work, they’re delivering applications in increments. They’re working in an incremental fashion to deliver features over time, providing value quickly and continue to add value. That’s a way to modulate your costs, to spread your costs and investment over a period of time.” 

This Forrester report’s recommendations advise software pros to update their application platform and tools strategies. How do your tools and platforms fit with the lean software approach? Right now, many organizations are working with platforms that are too bloated and nonproductive, Rymer said. 

“A lot of shops adopted J2EE, and they’re really struggling now to keep up with the demand for new applications. It’s not a real productive environment. Just coding things up in Java takes a lot of time.” 

The era of one-development-platform shops should be over, Rymer said. 

“If you have a variety of application scenarios, don’t assume you have to adopt one platform to do all of them. There are a variety of tools now. People who choose to use Spring (Application Framework), for example, are oftentimes using it alongside their J2EE. They can run the Spring on an extra app server. So, it’s not like there are these hairy choices that force you to throw away what you’ve got. Pick the right tool for the job, and if you’re smart about it you can integrate these things.”  

Rymer suggested that the PHP framework is built for speedy development. It’s now “a real framework and not a collection of modules,” he said. “You can build certain Web applications very quickly, much more quickly than you can with either conventional .NET or Java development.”  

Don’t think that lean computing is a movement to oust established vendors, Rymer noted before we signed off. Remember that even Microsoft is involved in the second wave of open source development tools adoption. “If you want to use Ruby or Python in the .NET world, you can,” he said. When change is driven by developer and business IT pros, big vendors like IBM, Microsoft and Oracle will join in.