Posts Tagged ‘agile’

« Older Entries

Indian outsourcing companies forced into price cuts

Tuesday, July 12th, 2011

Indian’s back office and software work is hardest hit, as the potential clients want to see prices knocked down by around 15 percent. The Indian outsourcing market has also been hit by companies moving their operations back to their own countries.

Now the price of India outsourcing is rising with the fowllow reasons. First, it is to combat the rising costs of staff salaries. Moreover, compared to the pre-recession 2008 levels, the salaries of engineers with three to six months experience had risen by 40 – 50 percent.

Source: http://www.techeye.net/business/indian-outsourcing-companies-forced-into-price-cuts

Did you like this? Share it:

Tags: , , , , , ,
Posted in Software Outsourcing | Comments Off

Agile Software Development

Wednesday, June 15th, 2011

07 Jun, 2010
Written by Effie Sha
Beijing RayooTech Co., Ltd.

What is Agile Software Development
Agile Software Development (ASD) is a methodology in software application development for the creative process that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product. Agile software development can keep code simple, testing often, and delivering functional bits of the application as soon as they’re ready. ASD focuses on building upon small client-approved parts as the project progresses, as opposed to delivering one large application at the end of the project.

Key Features of Agile Software Development
- Iterative: Iteration is an entire application distributed in incremental units. Development time of each iteration is small (for example couple of weeks) fixed and strictly adhered to. Every iteration is a mini increment of the functionality and is build on top of previous iteration.

- Active Customer Involvement: Clients can participate in face-to-face interaction of agile software development. All Iteration needed to test and approved by clients. The feedback from clients will be collected and implemented in the next iterations, and doing this can reduce risks and ensure higher client satisfaction.

- Feature Driven: More emphasis is on providing the required features in the application. 80/20 principle is applied to decide the 20% features which would be used 80% of the time.

- Fixed Time: Each iteration has a fixed time range in delivery.

- Priority based delivery: According to client need prioritization of features and development risks etc, high priority features will be developed firstly. The project priorities will be re-evaluated after every iteration process.

- Adaptive: The application can cater to inflow of new requirements throughout its development because the methodology in general is very adaptive. Goal is not to remove the uncertainty in the very beginning, but instead, it is to adapt to the changing needs.

- Empowered Teams: Usually, the project teams are small and have frequent interaction and communication. No separated team to manage project due to entire team is actively involved and empowered to make decisions.

- People Centric: Using the appropriate experts to do the development more than just following the development processes. Then there will be more time to develop and test software, minimized the documentation and other non-development activities.

- Rapid Development: Light weight development technologies make the development be done quickly.

- More Disciplined: The whole development process involves lots of team and self discipline which requires highly skilled and organized team members in order to deliver each part of software correctly in time.

- Simplicity: Keeping things as simple as possible and ready to open for any changes.

Agile vs. Waterfall: Practical Differences in Methodology
As the industry learned more about software development, development technologies for managing and predicting the cost of projects came into use. The methodology that has dominated software development projects for decades is called ‘waterfall’. In 1970, Winston Royce described a serial method for managing software projects through the five stages shown in the following figure:

One of the most important differences between the agile and waterfall approaches is that waterfall features distinct phases with checkpoints and deliverables at each phase, while agile methods have iterations rather than phases. The output of each iteration is working code that can be used to evaluate and respond to changing and evolving user requirements.

Waterfall supposes to have well understanding of the requirements at the beginning. However, in software development, usually, stakeholder have no idea what they want and their exact requirements. With waterfall, project development team rarely delivers what the client wants even it is what the clients asked for.

Agile methodologies introduce iterations. Software project development team works with stakeholders closely to define prototypes, concepts or other visual elements to solve problems. The project development team defines the user requirements for the iteration, develops the code and test application, finally, clients verify the results.

Benefits to the Client
- Clients are more actively involved in software development than ever and get higher priority.

- Regular and frequent application status and situation will be sent to clients immediately.

- Requirements are accepted after each iteration

- The key functionalities can be available to use as soon as possible since the methodology emphasizes rapid delivery.

- Delivery is defined by fixed timescale. Clients will receive functionality by a fixed time period.

- More testing is done, higher software quality is delivered.

Benefits to the Software Development Teams
- Software Development teams are involved more actively in all stages. The teams collaboratively take the decisions and are more empowered.

- Teams can focus on the specific requirements at any given point of time since the software development is incremental.

- Software development team would spend more attention on project development, not on documentation.

- The teams will receive feedback frequently to promote software project efficiently.

- Spending less time to collect requirements as these requirements are not gathered upfront and are implemented as and when they arise.

- Spending less time to make plans.

- Other non-development work related cost will be reduced.

[ All rights reserved, reprint, please specify source and the author. Thank You. ]

China Software Outsourcing CompanyDownload ‘ Agile Software Development ‘ Article

Did you like this? Share it:

Tags: , , , ,
Posted in Agile Development | Comments Off

The development of Agile & Scrum Tolls

Wednesday, April 6th, 2011

Currently, an agile training and scrum certification company has released five free agile and scrum tools ScrumMasters which can help Agile teams planning and prioritizing software development projects.

The five tools: a velocity range calculator, relative weighting worksheet, theme scoring tool, theme screening tool and project success sliders, have all been developed to help Agile and Scrum teams stay on time, on top of projects and build better plans with confidence.

“Software development plans created with a 90% confidence interval, are more likely to be accurate than plans created with a point estimate of velocity.” The creator of these Agile tools said. Who has rich experience in the development of Agile & Scrum.

Source: http://refcardz.dzone.com/?oid=bming728_3_blue

Did you like this? Share it:

Tags: , , , , , , , , ,
Posted in Agile Development | 1 Comment »

Agile Outsourcing: 10 Tips for Successfully Outsourcing Software Development

Monday, February 21st, 2011

Software Development conducted a survey of subscribers in 2004 on their experiences with offshore software development. Fifty-six percent of the responses indicated that the software that came back was either unusable or worse than in-house software development results. If the same survey was done for outsourced software development efforts (not offshore but near shore), I don’t think the results would be that different. Problems arise more with the nature of the outsourcing itself. Offshoring may only make it that much more difficult to manage because of distance, time-zone differences and cultural differences that may become amplified.

In this month’s column, I outline 10 factors that can ensure the success of outsourced software development. Some of these factors are related to agile methodologies and some are not. Assuming that the goal of software development (whether done in-house, outsourced or performed offshore) is solving a business problem, some of this advice may sound counter-intuitive or may seem to go against commonly accepted software development wisdom. However, we practice these every day in our software development efforts and they seem to work well for us.

Success Tip #1. Match Software Development Methodology to the Project

Waterfall model, rapid prototyping or the more recent software development methodologies like pair programming, test-driven software development or Scrum are all useful in different contexts for different software projects. We should remember that software development methodologies are all milestones in the continuing evolution of software engineering. This evolution is still continuing and there will be more variants in the future. And, depending upon the nature of the software development project, the choice needs to be different. If the software project is a re-implementation of a well understood business problem such as accounting, a waterfall model may be the best choice. If precise requirements aren’t available today and the time available for the project is short, an agile methodology may be the best choice. Just remembering that there is no single silver bullet for all projects will save a lot of heartache on all sides.

Success Tip #2. Have the Right Expectations

The service provider usually is a separate company with its own goals, motivations and agendas. The onus for the success of the software project still rests with the buyer of the outsourcing services. It is still your responsibility to make sure that the requirements are well defined and that appropriate course corrections are made early on in the project’s lifespan. Blaming the service provider is easy, but making the whole exercise successful can only happen if the right expectations are in place from the beginning of the project. Legal documents, agreements, contracts and lawsuits can bring monetary redress. In the meanwhile, if companies lose valuable time, the opportunity costs may be a lot higher than what the service provider can compensate for legally.

Success Tip #3. Base Sourcing Decisions on More than Just Cost

Cost is a major factor in many outsourcing decisions, especially offshoring. Selecting the least expensive vendor often backfires and ends up costing the client much more than initially thought. Offshore vendors are all facing cost pressures from wage inflation. Choosing the least expensive vendor just means you have chosen a company with very little leeway in its profit margins. This will affect everything adversely: hiring the right people, retaining the people who are working on your projects and providing the right resources for people to do the work on your development effort. Successful vendors may be better bets even if they’re bit more expensive, given the realities in outsourcing and offshoring.

Success Tip #4. Build an Effective Communication Pyramid

The figure below shows different communication methodologies that may need to be used in any outsourcing or offshoring project. Periodic and systematic communication among all stakeholders in the project, including the service provider, is absolutely essential at every stage of the development effort. The project manager on the buyer side is eventually responsible for the success of the effort and may need to use every communication mechanism available to communicate freely and often with every member of the development team. Using only any one method exclusively may not work as effectively as using all of them on a schedule. From being available as needed on chat or instant messaging (IM) to visiting with the development team and having face-to-face meetings periodically and systematically is the only way to make the effort succeed. As I’ve outlined in other columns, agile methodologies are more realistic when it comes to making sure communication is facilitated properly and often with real code sent back for verification, reflection and fine-tuning.

Communication mechanisms.

Communication mechanisms

Success Tip #5. Trust but Verify

Recently I saw an anecdotal story from an outsourcing customer who thought everything with the outsourced project was going fine only to discover that the project was way off-track after about six months’ time. Vendors can be trusted but it’s still the responsibility of the buyer to verify that the progress is real!

Success Tip #6. Use Independent Testing and Quality Assurance

Testing and quality assurance should be done either by the client’s in-house team or by outsourcing it to another vendor. This isn’t just a question of trusting the vendor, but it’s simply good software engineering to separate the development and testing functions. Agile methodologies help this process much better since more testing/quality assurance can be done and course corrections can be made earlier, getting the project back on track if it gets off.

Success Tip #7. Involve End Users Early on

There’s no better way of ensuring the success of outsourced software development efforts than involving end users early on — even at the requirements and design stages if a waterfall methodology is used. In cases where software is deemed unusable, it’s likely that the vendor is guessing about what the end user really needed to solve their business problem and may have made some bad guesses! Agile methodologies help in this regard by actually getting earlier versions of the software in the users’ hands. Any guesses that are way off the mark may have a good chance of being corrected earlier in the project lifespan.

Success Tip #8. Understand Cultural Differences and Adjust Project Plans

From a practical point of view, cultural holidays may just be as important. Understanding local holidays and festivals on both ends of the outsourcing effort always helps in proper planning. If the client is in the United States, the last two weeks of December and the first week of January are bad for planning any major activities in the project, given holiday and vacation schedules around Christmas. The second week of November is time for Diwali festival in India, which, if your vendor is located there, is just as big and equally as important as Christmas.

Success Tip #9. Achieve On-site Coordination

Given the expense, having an onsite coordinator from service provider all the time may not be possible in all outsourcing efforts. However, if it is feasible, it’s the best way to enable excellent communication between users and the development team.

Success Tip #10. Learn and Fine-Tune Approaches

Project methodologies should be subject to periodic review and adjustment, especially in the earlier stages of the project. In practice, a lot of time is whiled away during the requirements and design stages of a development effort. Learning what is working and what is not as early as possible helps fine-tune the approach that will be followed for the rest of the project’s lifespan. Agile methodologies excel in enabling this fine tuning since working software is delivered earlier on and often in the cycle.

Many software development deals fall apart because proper attention isn’t paid to the many dimensions of project management that need to be in place for success. By understanding that successful outsourcing of software development is much more than just picking a vendor and writing an iron-clad contract, you’ll go a long way in addressing every ingredient that makes it successful.

source: http://www.sourcingmag.com/content/c070101a.asp

Did you like this? Share it:

Tags: , , , , , ,
Posted in IT outsourcing | Comments Off

How to Plan for Integration Change

Friday, February 18th, 2011

They say the only constant is change. But as Paige Roberts of Pervasive Software’s Integration Division Product Marketing points out, businesses claim they want to be agile and prepared for change, but when it comes to their integration strategy, many are still pretending the applications, systems and data sources will remain constant.

Talk about planning to fail. If there’s one guarantee in integration, it’s that at some point, an integration point will break. As programmer Alberto Gutierrez recently wrote on his blog, Making Good Software:

The problem with any integration point is that you don’t have any control over them, which means that they are not reliable; this requires the developer to have in mind additional considerations to successfully develop robust integration points.

Gutierrez addresses the problem from a programmer’s point of view, but after reading Roberts’ post, I think there are reasons to consider this issue further up the management chain. First, you need to make sure your programmers are, in fact, doing what they can to prepare for the inevitable integration breaks – Gutierrez’s post offers four tips on what they should be doing. Second, in this interconnected world, it can pose a bigger business problem when integration fails, which means you need to have a plan in place for when these problems do occur.

Fortunately, as Roberts – a former software engineer – explains, there are design strategies you can use to plan for change. And, you can ensure that whatever data integration solution or platform you choose supports those change strategies.

Sometimes, change can be worthwhile. The key is knowing what’s worth pursuing and what’s not.

In other words, you need an enterprise-wide plan for managing integration change, whether you’re focused on internal or external data integration.

What do you need to do at a top level to prepare for change? Here are some of the strategies Roberts and Gutierrez say you and your development team should put into place:

Plan for failure. “Every single integration point may fail; keep always this [in] mind when developing,” warns Gutierrez. So, isolate the volatile bits, warns Roberts. “For integration projects, the volatile bits include paths, business rules, and data transformations among other things. Those things change with the weather.”

How you do it: “Don’t ever get caught with a proprietary system that won’t let you modify those yourself, or where you have to pay an expensive consultant to come in and do it each time, when he can get around to it. Good integration design puts these in a location where the business user can get to them fast, and change them easily,” advises Roberts.

Plan for modifying integration. You don’t want an ERP upgrade to mean you have to redo your integration framework, warns Roberts. Likewise, Gutierrez cautions you don’t want one integration failure to affect an entire application.

How you do it: Go modular, advises Roberts. “If a chunk of a solution is no longer wanted, you need to be able to pull it out, and plug in a new one, without breaking everything,” she writes. Another option would be to use a service-based approach to data. Gutierrez suggests you minimize the amount of interactions with integration points, wrap the interaction logic in transactions, allow for retries and separate the business logic from the logic handling the integration.

Plan to find problems before they’re business problems. “Every integration ever built will break, no matter how elegantly and flexibly designed,” writes Roberts. “No matter how solid you build that puppy, some trading partner will switch formats without telling you, some server will crash, or some nasty, messed up data will sneak past your data quality watchdogs and wreak havoc.” Therefore, you’ve got to monitor for broken points before they become major pain points.

How you do it: Roberts advises you opt for a solution with automated monitoring that will alert you if something changes.

On the development front, Gutierrez suggests you thoroughly test any integration and use robust logs that will answer three questions:

  1. What message initiated the interaction?
  2. Was there any unexpected error?
  3. What was result of the interaction with the integration point?

source: http://www.itbusinessedge.com/cm/blogs/lawson/how-to-plan-for-integration-change/?cs=45221

Did you like this? Share it:

Tags: , , , , ,
Posted in IT NEWS | 5 Comments »

Getting Started with Agile Software Development

Thursday, January 6th, 2011

 

Agile development practices can greatly benefit any software development effort. By its very definition, an agile practice allows teams to switch gears with relative ease compared to earlier methods such as the waterfall design process. However, for a team — or even an individual — making the change to agile practices can be quite intimidating. Here’s some tools and tips to get you started.

Continuous Integration
One of the cornerstones of any successful project is ensuring changes don’t break the build. Incorporating a continuous integration system automates the build and testing process so that developers can make their changes to a project and find out fairly quickly (usually within minutes) whether or not they broke other parts of the application.

The Hudson Continuous Integration System is an open source Java-based build server. It includes a large core feature set capable of handling most projects, and also has a large set of community developed plug-ins to extend the system in ways that make it virtually indispensable.

Other good build systems to check out are Cruise Control (also Java-based) and it’s related .NET project, CruiseControl.NET.

There’s several other decent continuous integrations servers available; be sure to test out a few before committing to one, as they all have different strengths and weaknesses.

Project/Feature Tracking
One of the core requirements of a good agile environment is keeping track of what’s requested, what’s planned, and what’s being worked on. There are countless ways of tracking different project features, ranging from simple Word documents and Excel Spreadsheets to full-fledged, high-end commercial management systems.

A good application to start with for a new agile team is the ScrumWorks system. It’s available in both a paid professional version and a limited free version, both of which offer a good feature set to
get your agile process off the ground. It allows keeping track of iterations and releases, a backlog of items planned for future development, and individual tasks required for each feature implementation.

Again, there’s a lot of great software available for project management, and even though ScrumWorks is a good starting point, you would be well served to look around for other systems. Every team is different, with different strengths and weaknesses; find one that plays well to your needs.

Regular Meetings
A lot of developers hate meetings, mainly because it takes away from what they love to do: write code. Unfortunately, regularly scheduled meetings are necessary to keep development teams on task. Certain agile practices, such as Scrum, recommend short meetings every day to cover what each developer has worked on previously, what they’re planning on working on that day, and what (if anything) is holding them up.

In most agile practices, development is normally broken up into sprints or iterations. These are normally 2-3 weeks, though they can be any reasonable length of time. At the beginning of each sprint, the team holds a fairly lengthy set of meetings. These cover what was accomplished in the previous sprint — normally involving non-developers who have an interest in the work — and what the teams are planning on accomplishing in the next sprint.

These regular meetings will definitely seem to be a waste initially, as most developers who aren’t used to an agile environment will see little point in them. After some time, however, the benefits will be noticed as developers begin to get better understandings of what the features are supposed to accomplish, and the rhythm of the iterations will keep the team focused in delivering usable functionality on a regular basis.

Patience

This is by far the most important requirement in converting to an agile development method. In the initial stages, it will be hard to keep to the schedules, as most of those involved are used to delivering functionality on a mostly random basis (generally "as soon as humanly possible, if not sooner"). It’ll take time for everyone to get used to having to wait. It’ll also take time to get used to the procedures involved, and to using different management tools — especially if the primary management tools had always been email and notepads.

Depending on the size of the development team and those involved in the development process, getting used to the agile procedures can take months or even years. But it will pay off, and the development process can start to see noticeable improvements in even a couple of sprints if the development team is committed to converting to the new process.

Get Going!
A lot of managers and companies have a hard time bringing themselves to start the conversion. There’s always a "better time" in the future — after this project is finished, or we’ll do it for this other project coming up. The best time to start with agile development is now. It won’t be any easier in the future — there will always be another project that needs to get finished, or another project that might be a "better" candidate for agile processes. If you keep waiting for the "right" time, you’ll never get started, and you’ll never get to reap the benefits that agile development can bring for you.

Source: http://www.associatedcontent.com/article/5552128/getting_started

_with_agile_software.html?cat=15

Did you like this? Share it:

Tags: , , , , ,
Posted in Agile Development | 13 Comments »

What agile software development can do for government – Part 1

Tuesday, October 26th, 2010

 

By Larry Albert, GCN.com

One of the few areas of agreement in Washington is concern about the state of IT project management.

As the White House Forum on Modernizing Government recently concluded :

“. . . Most Federal Government IT projects are too large and not sufficiently integrated into business unit operations. Multi-year Federal IT efforts are typically driven by technology managers — who often turn over during the life of the project — rather than agency business leaders. Agency business leaders are not held accountable for project success, and in turn do not adequately invest in IT project management. As a result, in comparison to industry best practices, Federal IT projects are too often marked by milestones spaced too far apart and deliverables that fail to deliver tangible end-user value. Further, Federal IT change efforts are typically managed in isolation from business operations, so those working on long-term solutions are too often not concerned with, or even aware of, the evolution of day-to-day business considerations. “

Having led major government IT programs, I can add that many of these challenges stem from an over-reliance on traditional software development models. These legacy approaches lock users into fixed and lengthy development processes that don’t readily accommodate change. This is despite the fact that requirements often evolve.

Fortunately, a framework – agile software development – exists for addressing many of these concerns. And agile has already been shown to deliver significant benefits for major government programs in terms of time-to-value, overall quality and their responsiveness to changing requirements.

Tradition doesn’t accommodate change

By definition, the traditional “waterfall” model for software development used throughout government is sequential and highly regimented. By locking down requirements at the onset of development and limiting subsequent stakeholder involvement, it often fails to:

    *
      Identify and correct problems early in the process when it is less costly and disruptive to do so.
    *
      Respond effectively to subsequent changing requirements that always exist.
    *
      Incorporate lessons learned and other improvements into the final product.

Did you like this? Share it:

Tags: , , , , ,
Posted in IT NEWS | 3 Comments »

Agile Manifesto

Monday, August 9th, 2010

Source: http://agilemanifesto.org/

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Did you like this? Share it:

Tags: , ,
Posted in Agile Development | 30 Comments »

Agile software development is now mainstream

Friday, July 30th, 2010

by Paul Krill, InfoWorld

A new Forrester report finds widespread use of the iterative software development processes

Agile software development  processes, in which software is built in short iterations rather than mapped out fully in advance, have joined the mainstream of development approaches, according to a Forrester Research report released this week.

Forrester surveyed nearly 1,300 IT professionals and found that 35 percent of respondents stated that agile most closely reflects their development process, with the number increasing to 46 percent if the definition of agile is expanded to include practices such as rational unified process or spiral.

[ InfoWorld reported last year that while agile programming is beneficial, it will nonetheless ruffle feathers. ]

“Perhaps the clearest sign of the mainstreaming of agile is the abandonment of orthodoxy: Teams are puzzling out the mix of methodologies and combining them to fit within their organizational realities, blending agile and non-agile techniques and practices to create a hybrid methodology that fits larger organizations,” according to the executive summary of the report, which is entitled “Agile Development: Mainstream Adoption has changed Agility.”

“It’s time for software development professionals to stop sitting on the fence where agile is concerned. According to those who have successfully adopted agile, the benefits are well worth the effort, and with the recent dramatic increase in agile adoption, the probability of working in or with an agile team has increased for everyone,” Forrester said.

The favored agile methodology, scrum, was used by nearly 11 percent of respondents. “Scrum focuses on how people work instead of on the work that they do, and it relies on the principles laid out in the Manifesto for Agile Software Development,” Forrester said.

However, teams are choosing parts of different process models.

“Most teams are not adopting scrum, extreme programming, or another specific Agile approach, but are embracing agile as an ethos or philosophy and cherry-picking the best bits from many different process models to develop a formula unique to their own situation,” according to the report.

Did you like this? Share it:

Tags: , , , ,
Posted in Agile Development | 82 Comments »

Agile programming: Beneficial, but it’ll ruffle feathers

Friday, July 30th, 2010

[InfoWorld reported last year that while agile programming is beneficial, it will nonetheless ruffle feathers.]

By Paul Krill | InfoWorld

Workshop attendees say that the iterative software development methodology provides enormous flexibility, however it will displease some developers.

In Agile programming teams build software in short iterations instead of mapping everything out in advance from beginning to end, and it offers benefits like flexibility while also poses organizational challenges, stressed by speakers at a workshop Thursday.

During an event at IBM offices in San Mateo, Calif., viewpoints on benefits and issues confronted when moving to an agile paradigm were posted by speakers from the agile development space.

“I think the challenge, whenever we try to encapsulate a short definition of agile, is that it expands in a lot of directions. Really, it’s a set of umbrella terms for a set of approaches that are going to be iterative, incremental and collaborative,” said Rich Mironov, chief marketing officer at agile consulting firm Enthiosys.

In accordance with Mironov’s presentation, the features of agile technologies focus on the frequent delivery of smaller, valuable increments and build quality in instead of adding it in at the end. Part of the process is user’s active involvement, and teams must be empowered and self-motivating. Benefits include strategic flexibility, improved team morale, deeper connection, and alignment with markets and greater profitability.

Through more direct involvement with customers can better market alignment be achieved, while profits can be increased since agile enables more software to be shipped at a higher quality and more products to be built with fewer resources, explained Mironov.

Though agile also enables early identification of project failures, it will not please everyone on the development team, Mironov said. “I haven’t seen [anybody] go through a transformation where everybody came out the other side happy. You’ll lose some folks because it’s not a style fit or they weren’t very good and you may not fit with agile. Expect some fallout or some people who need to move to the part of the organization that’s not going this way,” he added. .

At the same time, collaborative software tools will be necessary when involving remote development teams in agile projects

An audience member emphasized how agile can face opposition.

“My experience with agile is there’s a lot of resistance to it because it’s not the way we’ve done things before,” said Ryan Grisso, software engineering manager at NetSuite, which uses an agile approach and makes a hosted business application.

Johnny Scarborough, vice president of product engineering at GlobalLogic which provides software development services, touted Scrum, one of the more popular agile methods.

Among the features of scrum, there are an agile software development framework and a “ScrumMaster,” that directs the team how to use scrum as well as to serve and protect the team. No specific engineering practices are regulated. Teams are self-organizing and cross-functional when in scrum, Scarborough said. “This is a cultural change in a lot of organizations,” said he.

“Scrum is about being adaptable,” Scarborough said.

Did you like this? Share it:

Tags: , , ,
Posted in Agile Development | 235 Comments »

« Older Entries