Tag Archives: agile

Agile Developers Needed, Demand Outpaces Supply: Study

The number of available agile jobs outnumbered qualified candidates by nearly 5 to 1 over the last two years, according to a study by Yoh Services.

As more and more enterprises begin to adopt agile software development methodologies, the need for qualified agile developers has skyrocketed. However, the number of available agile developers cannot keep up with demand, according to a recent study.

Many of the Fortune 500 and leading brands in America are increasingly searching for agile software developers that can help them improve speed of delivery and provide more and better value to their customers. Yet a study conducted by staffing firm Yoh Services based on data from CareerBuilder’s Supply and Demand Portal revealed that the number of advertised agile jobs outnumbered active candidates by 4.59 to 1.

This skills gap has not only made it difficult for companies to quickly source quality talent on demand, but also puts them at risk of hiring technical professionals that have poor agile methodology skills. At the same time, as more companies seek to capitalize on agile practices, many agile professionals struggle to find an established program that fits their abilities.

Agile software development refers to a group of software development methods based on iterative and incremental development, in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change.

Agile methods break tasks into small increments with minimal planning and do not directly involve long-term planning. Iterations are short time frames or "timeboxes" that typically last from one to four weeks. Each iteration involves a cross-functional team working in all functions: planning, requirements analysis, design, coding, unit testing and acceptance testing. At the end of the iteration, a working product is demonstrated to stakeholders. Agile development emphasizes working software as the primary measure of progress.

The Yoh analysis showed that companies advertised a total of 558,918 agile jobs from 2010 to 2012. During the same time period, there were merely 121,876 active candidates, just 17 candidates for every 100 jobs. Inconsistencies in experience and geography compound this "agile gap," the Yoh study showed. Of the available job seekers, more than 50 percent have 10 years of experience or more, while less than 2 percent have one to two years of experience.

The agile gap exists across the U.S., varying only in its degree of severity. For instance, while states like Florida and Texas have a higher average number of active candidates, the ratio of open positions to candidates remains high, at 4 to 1. States with a more severe gap, however, such as Washington and California, have 10 open positions for every candidate, the study revealed.

The adoption of the agile development methodology has accelerated since the latter part of the last decade, while training for frontline developers failed to keep pace. As a result of the high demand for a limited number of agile developers, many industries, such as computer systems design services, custom computer programming services and software publishing, struggle to attract the agile talent they need. Organizations that get available, experienced talent are forced to pay premiums, whereas others are forced to hire and train professionals on agile methodologies.

"These discrepancies can hurt the hiring companies in the form of increased costs, salaries and turnover," Don Hanson, senior vice president of the eastern region at Yoh, said in a statement. "When companies hire the wrong candidate, they jeopardize employee engagement as well as potentially damage their reputation in the agile community, hurting future recruiting efforts. More than ever, a thorough vetting and hiring process is crucial for both agile employers and job seekers."

For this reason, "agile developers hold all the cards," Bob Schatz, chief agile evangelist at Yoh and owner of Agile Infusion, an agile coaching firm, said in a statement. "As demand for agile skills continues to grow, employers must clarify the extent of their agile programs, whether they’re established, new, or still just an idea.

"By erring on the side of transparency about the state of the company’s agile culture, employers will be able to find the best talent for their open positions and avoid turnover costs as well as misunderstandings during the hiring process that could alienate future agile recruits," he said.

Yoh, a Day & Zimmerman company, sought insight into the state of the agile talent pool as demand continues to rise for agile practitioners, who build software and transform business processes through teamwork; customer collaboration; short, iterative cycles; and responses to change. As more companies seek a nimble and entrepreneurial approach to business, the agile development methods of companies like Facebook and Apple are quickly spreading, but a lack of educational resources has left few agile practitioners to fill that need, Yoh officials said.

"Given the gap between available talent and demand, companies seeking to hire an agile team must understand that the adoption of agile development requires a complete change in culture, and they must make that transition or risk high turnover, lower morale, and loss of credibility in the agile community," Schatz said in a statement.

For more information on the agile skills gap, the positions most in demand and the companies most in need of agile talent, check out Yoh’s infographic.

Source:   http://is.gd/2GrocC

Did you like this? Share it:

HP Beefs Up App Testing Tools For Virtual, Mobile Environments

Hewlett-Packard on Tuesday launched Application Lifecycle Intelligence (ALI) version 2.5, a set of software development tools that speeds up the testing process for apps in mobile and virtual environments.

ALI 2.5 now works with a wider range of development environments and software configuration management systems. When software code is changed, there are requirements that need to be validated, and ALI 2.5 takes artifacts and provides traceable information between them.

"This is valuable in virtual environments, where testing and development need to be built and torn down when validating bunch of changes," Matthew Morgan, senior director of product and solution marketing for HP Software, said in an interview.

Change-based testing is common in Agile software development environments, and ALI 2.5 will be available through all HP software resellers, said Morgan. "Partners can wrap in their own value-added expertise on how to be successful in an Agile environment," he said. "There is also a change based testing component."

HP is also integrating its functionality for testing mobile apps using real devices in the cloud. While HP’s existing LoadRunner in the Cloud product is for testing apps, the new HP Testing for Mobility Services handles the other side of the equation: functionally validating apps to ensure that they work as intended.

Source: http://www.crn.com/news/applications-os/232700030/hp-beefs-up-app-testing-tools-for-virtual-mobile-environments.htm;jsessionid=hGhoYfEm8D+fRHV9Y+C73Q**.ecappj01

Did you like this? Share it:

Apply QA Testing in an Agile Development Methodology

The growing popularity of utilizing the Agile Development methodology to develop systems has changed the way software is tested. Certainly, high quality is still a requirement but the approaches, techniques and artifacts have changed. In Agile development, there is a common “principle” that for a specific period called a Sprint (usually 30 days), all software will be fully developed, tested and documented and “releasable ready” for production use. The speaker will educate on the appropriate approaches, artifacts, and metrics to successfully deliver high quality products on time in an Agile methodology. This will include customer experiences to show real life examples and techniques for successful “Agile” Testing.

  • Customer Agile Experiences
  • QA Processes and Artifacts
  • Automation Testing Approaches
  • Performance Testing Approaches

Please note that all webinar times are displayed in US Eastern Time.

Source: http://www.vietnamesetestingboard.org/zbxe/?document_srl=425387

Did you like this? Share it:

A Set of Unit Testing Rules

Teams that adopt agile practices often adopt Test Driven Development (TDD), which means, of course, that they end up writing a lot of tests. In general, thats great but there is a failure case for teams that attempt to get test infected; you can end up writing very slow tests that take so long to run that they essentially start to feel like baggage even though they help you catch errors.

This issue with unit tests isnt a new issue, its been around for a while, and there are a couple of ways of handling it. In Extreme Programming, the typical way of handling it is to periodically go back and optimize your tests as they get too slow. In many cases this works well, but the amount of optimization that you have to do can be rather large if you havent been conscious of how long your tests run during development. In one case that stands out in my memory, I visited a team on the east coast about four years ago that wrote oodles of tests against their EJB environment. The tests hit a server and went through session beans, entity beans, down to the bowels of the database and then up again. Their refrain? We dont like writing unit tests any more; they take too long to run. I didnt blame them for feeling that way, but I also didnt agree that they had written any unit tests.

The problem is rather common. Ive spoken to other XPers about it over the years and I sort of figured that the way that I handled it was common, but I was surprised to discover (on the XP yahoo group this week) that it was also a bit contentious. Heres what I typically say when I run into teams that have this problem.

A test is not a unit test if:
# It talks to the database
# It communicates across the network
# It touches the file system
# It can’t run at the same time as any of your other unit tests
# You have to do special things to your environment (such as editing config files) to run it.

Tests that do these things aren’t bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes.

Source: http://www.vietnamesetestingboard.org/zbxe/?mid=download&category=12646&document_srl=459161&listStyle=&cpage=

Did you like this? Share it:

Apply QA Testing in an Agile Development Methodology

The growing popularity of utilizing the Agile Development methodology to develop systems has changed the way software is tested. Certainly, high quality is still a requirement but the approaches, techniques and artifacts have changed. In Agile development, there is a common “principle” that for a specific period called a Sprint (usually 30 days), all software will be fully developed, tested and documented and “releasable ready” for production use. The speaker will educate on the appropriate approaches, artifacts, and metrics to successfully deliver high quality products on time in an Agile methodology. This will include customer experiences to show real life examples and techniques for successful “Agile” Testing.

  1. Customer Agile Experiences
  2. QA Processes and Artifacts
  3. Automation Testing Approaches
  4. Performance Testing Approaches

Source: http://www.vietnamesetestingboard.org/zbxe/?document_srl=425387

Did you like this? Share it:

The Distributed Agile Model

Since proponents of Agile processes prefer face-to-face conversation as the means for communication within a development team, in the “distributed Agile model” – in which members of an Agile team are situated in more than one workplace — this may seem unlikely.

But Agile processes are not rule-bound; rather, they optimize for methods and dynamics by which organizations are able to build, maintain, and apply systems of knowledge within changeful, context-dependent, collaborative work situations.

So when we evaluate the viability of distributed Agile (DA), our concern is not whether it complies with a particular definition of Agile, but whether it can support iterative, incremental, and sustainable development; promote teamwork; promote self-management; adapt readily to emergent changed requirements; and increase customer participation in the development process. Based on my experience I would say DA is, in this sense, viable. But special measures must be taken, especially in the area of communication. I will briefly describe those measures in this paper.

First, though, it may be helpful to state some background. We worked with organizations who, following their companies’ recommendation or mandate, had adopted Agile project management, but also wanted to outsource their testing.

Some varieties of testing are a very good fit for DA, such as running full regression suites on the most recent known-good build, performance testing, automation development, and end-to-end testing.

One of the best fits for DA has been a sort of cluster of remote Scrums, where the home group drives development of the core engine, while a remote group is spawned whenever an adapter or significant new feature is required — each remote group communicating closely with one member of the home group who attends daily standups etc.

Source: http://www.vietnamesetestingboard.org/zbxe/?document_srl=459513

Did you like this? Share it:

Pros and cons of agile software development

Agile software development or Agile programming supports the evolution of the transformation process in the life cycles of software development projects. Agile also have a unique number of pros and cons.

Flexibility

Most of Agile methodology are aimed to minimize the risks by keeping the software development process to a really short time; a process called the redundancy step. The redundancy step is similar to a small software development project. It includes all of the necessary tasks for the software upgrading process.

Based on the theory of traditional software developing methods (especially the water-fall model) the standard requirements rarely change in the overall development process and usage. However, in practice, especially on the internet working based environment, those requirements need to be changed much more rapidly. Therefore, the time factors can have strong impacts to the quality and usage. Moreover, in some cases, they need to redesign the whole structure of software development process to be suitable with the new requirement.

Another sector with a huge potential for this appllication in software management is the software testing industry. Testing projects are usually designed for many different levels or many different periods. The structure of the project is combined with the design structure of software testing.

Wasting of resources

There is no methodology that can always be 100% effective. One of the critical requirements of Agile projects is that all team members must have the same high skill level in their abilities. They must have a high working aptitude and self disciplined to satisfy the requirements for personal creativeness and continuous development. Moreover, the offshore model will cause a variety of problems because of the differences in geographic locations between the project owner, customer representative, and the development teams.

Difficult to apply in large projects

The experts in the software field agree that Agile is usually difficult to apply in large scale projects. Agile is not suitable for large software projects which contain a large number of team members. These large projects are usually get divided into many smaller scale projects that has a concrete structure and does not have place for a lot of mistakes.

Source: http://www.vietnamesetestingboard.org/zbxe/?mid=download&category=195957&document_srl=448255&listStyle=&cpage=

Did you like this? Share it:

When is testing in Agile complete?

In Agile development, testing isn’t a separate phase, it’s tightly integrated with coding. In fact, we start development on each user story by writing business-facing tests that will tell us what to code and help us know when we’re done. Testers, business analysts and developers work with the business stakeholders to elicit examples of desired and undesired behavior for each user story and feature, and turn these into executable tests. This is called Acceptance Test-Driven Development (ATDD) or Specification by Example. The development team collaborates with the customers to decide which tests will prove a particular user story delivers what the customer expects. This will include automated functional tests, manual exploratory tests and non-functional testing such as performance or security testing. When those tests are all passing, you’re done with that user story.

User story estimates must include time for all testing activities, including test automation and manual exploratory testing. When we plan our iteration, we only plan the user stories which can be completed, including all testing activities. New Scrum teams often over-commit, planning more work than they can possibly finish. They end up in a mini-waterfall, with testing pushed to the end, and their features are not done just because the last day of the sprint arrived. This leads to a death spiral of stories dragging from one iteration to the next, with the testers unable to ever catch up.

Agile teams have an advantage – they include all the roles necessary to understand the customer needs and deliver high quality software. Diversity of skills and experiences allows Agile teams to find ways to help business stakeholders define their needs with concrete examples, and translate those examples into the tests which define “done” for each user story and each feature.

Source: http://searchsoftwarequality.techtarget.com/answer/The-end-of-an-iteration-When-is-testing-in-Agile-complete

Did you like this? Share it:

Software quality attributes and their rankings

“The rankings come from observations in about 600 companies and 13,000 projects,” answered Capers Jones and Olivier Bonsignour when questioned about the table in their book, The Economics of Software Quality. The table lists 121 software quality attributes and their rankings on a scale from +10 (extremely valuable) to -10 (extremely harmful). In part one of this series, we learn that use of Agile methodologies and hybrid methodologies are both ranked as 9.00, while use of the waterfall methodology is ranked as 1.00. In this second part of the three-part series, we explore more of the attributes and their rankings.

SSQ: Though “Use of Agile methods” ranked a “9.00,” I didn’t see line items for many techniques that some Agile teams practice such as test-driven development, pair programming and continuous integration. Have there been studies to demonstrate which Agile methods are the most beneficial in achieving higher quality?

Capers Jones/Olivier Bonsignour: One caveat is that Agile is not the only method that is effective: both the Team Software Process (TSP) and the Rational Unified Process (RUP) are also successful. While we’ve been able to get some measurement regarding Agile methods overall, the industry around Agile is not very data-rich. We have not seen much activity in the Agile community towards quality measurement programs, especially at a level of refinement that would provide insights into such questions as variation between Agile methods. When we had our research paper on technical debt measurement accepted at this year’s 10th anniversary Agile conference, the organizers struggled to figure out where to feature the talk, since there was no measurement track.

SSQ: There also aren’t line items for specific Agile methodologies such as Scrum and XP or mention of Lean or Kanban. What are your thoughts on the different Agile methodologies?

Jones/Bonsignour: It’s probably too early to derive any conclusion. Most of the Agile methodologies are less than 10 years old, and moreover, most of them have been built on the ground defined by the previous ones. There are interesting points in all the different approaches, and most of the time it’s quite difficult to fully embrace one and only one methodology. Most of the companies we’ve been talking with are in fact using a sort of mix of different methodologies picking the appropriate points/parts in each of them. For sure, with Scrum currently being so popular as to often be synonymous with Agile, you will hear most companies say that they are using/implementing Scrum. But XP includes more technical practices and Kanban/Lean are nicely complementing the good ideas/common sense behavior promoted by the above. Lean is not so much a method as an approach to focus on eliminating waste from the process. Lean tends to be a broader management initiative to introduce measurements to identify areas where cycle time is being degraded, identify root causes, and then measure again in a cycle of continuous improvement. As such, Structural Quality is an important component of Lean application management.

But again, we are not aware of any definitive studies of their relative effectiveness. The question here is whether we should even look for one. Aren’t the principal characteristics of Agile the agility and flexibility? So shouldn’t the Agile practitioners be Agile enough to not stick to a single approach and instead continue to do what the community has been doing for 10 years: quickly adopt the new improvements?

Source: http://searchsoftwarequality.techtarget.com/news/2240106482/Quality-metrics-Software-quality-attributes-and-their-rankings-Part-two

Did you like this? Share it:

Agile is a culture, not a process

“We think the biggest takeaway is an emphasis on Agile as a culture, not a process,” say Ken Howard and Barry Rogers about their new book, Individuals and Interactions – An Agile Guide. In this second part of a two-part interview with Howard and Rogers, we look more at Agile values and leadership. Howard and Rogers continue to emphasize the importance of communication, collaboration and teamwork in Agile environments.

SSQ: In the book we read that Agile is a set of values rather than a process. However, aren’t the underlying values really trust and respect rather than adherence to prescriptive frameworks? There are some very high-performing military teams who lead by command-and-control, yet maintain a high degree of mutual respect with their subordinates. There are also Scrum teams in which Scrum Masters demand adherence to Scrum process rules with embarrassing penalties for those who don’t follow them. Which team is more Agile?

Ken Howard/Barry Rogers: Interesting question. I would say that neither team is Agile. It would be like asking which shape is rounder, a door or concrete? While a military team might have mutual respect between superiors and subordinates, I do not believe that makes them an Agile team. Respect is only one characteristic of an Agile team. And command-and-control style leadership is only one way to potentially and questionably earn this respect. Similarly, a dogmatic Agile Scrum Master with embarrassing penalties is not fostering a team or trusting environment. So, I would argue that neither is truly Agile. Having said that, I have seen teams adopt a subset of the components of Agile and/or Scrum. They are still much better off than they have been prior to adopting these components. However, they have not truly reached all the benefits of a high performing team and may not be close to what one would deem an Agile team.

A common misapplication of self-organizing teams is that team members should only do what they want to do. In a perfect world, this may yield optimal results. In reality, though, not all team members are motivated and productive. Therefore, strong leadership is still a necessary component of Agile projects. Self-organizing and self-managing are important, but strong leadership is necessary to facilitate optimization.

In the book we discuss Maslow’s Hierarchy of Needs and how oversight of an individual’s essential needs can easily be overlooked by other team members. For example, when selecting the best time for the daily standup meeting, it’s possible to alienate a valued team member who does not want the standup meeting to be at 8:00 a.m. because it’s the only time she is able to spend quality time with her kids before work. If she is a high “C”, she is unlikely to push for a later meeting time, and therefore this distraction could negatively affect her productivity. A strong leader could recognize this and “facilitate” the team to a more generally agreeable meeting time.

Source: http://searchsoftwarequality.techtarget.com/news/2240110843/Agile-is-a-culture-not-a-process

Did you like this? Share it: