Articles
Many software engineering teams have adopted Agile. However, teams delivering process change tend to use traditional ‘lifecycle' approaches and have yet to embrace Agile. Why is that? Can the Agile approach be used to implement or facilitate process change?
As Borland evolved over the last 25 years, acquiring companies and shifting business strategies, the delivery organization had become a collection of teams with different cultures, processes, release cycles and levels of performance. The cost structure of the organization wasn't aligned with the strategic objectives of the company, and the teams were struggling to consistently meet delivery goals.
While doing some research for an upcoming article, some thoughts gelled about where Agile Software Development lies on its evolutionary path. I was procrastinating somewhat, and while poking around some aviation-related sites I saw an image of a jet engine used on the current crop of regional jets.
Based on the work of Edward de Bono, the six thinking hats for software testers have helped Julian Harty and numerous others work more effectively as testers and managers. Watch and learn how to apply the six testing hats and other "thinking skills" on your test projects.
Software licensing--licensing is a major part of what open source and free software are all about, and it's one of the most complicated areas of law. This concise guide focuses on offering an in-depth explanation of Open Source functional testing tools, how they compare and interoperate. If you're an open source/free software tester, this book is an absolute necessity, bridging the gap between the open source tool and licensed tool.
This is the first of many letters from Screwdisk to his protégé Virus[1]. I make no claims to the authenticity or accuracy of these letters, other than they ring true with what I have seen in the field over the last 10 years. Some of what you will read may sound a bit too familiar. It has me wondering if I have ever unknowingly been on a team with Screwdisk or Virus. I have never been able to find out who Virus and Screwdisk really are, but from what I've seen they could have been at many different organizations around the world - maybe even yours.
In our continuing search for Hyper-Productivity, we have observed that a strong and highly adaptable shared sense of Common Purpose can increase the group's ability to execute on the project vision or enterprise strategy.
Agile teams apply several methods that support this. They self-organize around a common goal agreed with the customer. This goal is most often embodied in the set of stories or tasks to be included in the next iteration. A shared definition of "done," a "living" and dynamic backlog and an involved customer all help to remove ambiguity around the goal and keep each iteration adaptable to inevitable changes.
Midway through 2006, members of a small software development group at an engineering center for an oil field services company began having informal conversations about the nature of their work. Among other things, they pondered whether software development is an engineering discipline or a craft; and where to focus improvement efforts. These discussions sparked the interest of many on the team. They searched and came across the Agile Manifesto, which was posted in their work area. The values outlined in the manifesto appealed to the team.
One of the main attractions of agile methods over traditional heavyweight approaches to software engineering is their ability to accelerate the software development process. By minimizing superfluous activities and artefacts such as models and documentation and focusing developers' efforts on coding, agile methods increase productivity and reduce overall development time. However, this focus on coding also has a down side - it means that new applications are typically written entirely from scratch. Software reuse, as envisaged by McIlroy back in 1969 [1] at the conference that coined the terms "software engineering" and "software crisis" is not explicitly addressed in the current generation of agile methods. If it takes place at all, reuse tends to be done in an ad hoc, unsystematic way.
Do you ever get the feeling that some conflict just can't be solved? The team members in conflict address the issue, it seems to go away but then it comes back. Maybe all dressed up in a new situation or with a different level of intensity, but the conflict is somehow familiar and you know that it has undoubtedly returned. If the team uses humor as a stress-reliever, you may even hear the conflict turned into a sarcastic half-joke, "OK team, just to put you on notice. Julie hates me again." Sounds almost like a marriage, doesn't it?
Pages
Upcoming Events
Recommended Web Seminars
Featured Resources
Agile Connection is one of the growing communities of the TechWell network.
 Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery. Join the conversation now! |