The Agile manifesto has been around for over a decade, and Agile remains one of the biggest buzzwords in the software development industry.

Despite this longevity (a decade is a long time in the IT world), few people really understand what Agile is. Some see it as a form of rapid software development, others see it as simply an excuse not to produce documentation.

So what exactly is Agile? In this great collection of posts, Kelly Waters explains how (put simply) agile development is a different way of managing software development teams and projects.

Read the 10 Key Principles of Agile over at AllAboutAgile.com.

As with all leadership roles, one of the most often overlooked aspects of being a good test manager is the need for pursuit. Pursuit of excellence, of elegance, of truth, of what’s next, of what if, of change, of value, of results, of service, of knowledge. Great test managers are never satisfied with traditional practice, static thinking, conventional wisdom, or common performance.

While this article isn’t written specifically with test managers in mind, we can all learn something about the value of being a ‘pursuer’, and how we should question ourselves before automatically embracing the status quo or adopting ‘cargo cult’ practises.

Read this excellent article about leadership over at Forbes.com.

Depending on the context, a little stereotyping can be fun: we can all recognise how we fit one or more groups based on our class, beliefs, earnings, or other demographic factors. However, stereotyping can also be damaging, particularly when it comes to careers.

Have you ever stopped to consider how stereotypical you may be as a software tester? This blog post touches on a few common testing stereotypes, and links to a couple of interesting articles about how you can avoid stereotypical behaviour in your testing career.

(Don’t miss the link to the TestingGeek’s ‘Wrong Reasons’ article!)

Read the post in full over at the uTest blog.

Typical duties of a test manager include defining and clarifying project objectives, planning and estimating, assigning people to tasks, monitoring progress, and providing feedback and reporting to people who want it.

On an Agile project, while many of these activities are still required, the parties involved are often radically different. For example, defining and clarifying test objectives will probably involve a more direct involvement with end-user stakeholders instead of the design/business analysis team in a traditional waterfall project.

In this interesting article over at Sticky Minds, Johanna Rothman argues that despite the fact many functional managers are no longer needed in an Agile organisation, test managers are still very much required – they simply have to fulfill a slightly different role.

Read the article in full at Sticky Minds.

Traditional testing practices typically follow the Waterfall or V-model, where requirements are defined, designs are agreed, and software is developed, tested and implemented in a series of phases that follow an often lengthy path. Agile is different, with a stronger focus on iterative development and frequent implementations, often doing away with much of the up-front design and documentation.

This is something of a paradigm shift for testers experienced in traditional techniques. Within Agile projects, end-users and developers work much more closely together, and testers need to work closely with both in order to understand and test the software in terms of the high-level business scenarios.

In this excellent article for TEST Magazine, Peter Varhol explains how independent testing is still a vital ingredient in Agile software development, and shows how testers are perfectly positioned to codify and clarify user stories, and verify and validate that they have been implemented as expected.

Read the article in full over at TEST Magazine.