As agile software development techniques and concepts cross the 'technology adoption chasm' we find that the concerns on the right-hand side of the chasm are much different than those on the left.
We are now facing critical issues which until now many within the agile community have preferred to avoid talking about. Activities such as modeling, documentation, exploratory testing, and database development must become more explicit within our methodologies. We need to find ways to fit into IT governance frameworks, process maturity frameworks, and regulatory guidelines.
Other issues such as certification, enterprise architecture, enterprise business modeling, and outsourcing must also be addressed. Finally, we must help the business take a more active role in development, reform IT financing, and in general manage their IT portfolio effectively.
Scott W. Ambler is the Practice Leader Agile Development in IBM's Methods Group. He is the founder of the Agile Modeling (AM), Agile Data (AD), Agile Unified Process (AUP), and Enterprise Unified Process (EUP) methodologies.
Scott is the (co-)author of 19 books, including Refactoring Databases, Agile Modeling, Agile Database Techniques, The Object Primer 3rd Edition, and The Enterprise Unified Process. He is a senior contributing editor with Dr. Dobb's Journal.
Inside the Agility Cube (Part 2)— There are many sides to agile development, but it is all too common to focus on only one or two, depending on personal interests, job role, background, etc. A manager may focus on organizational and process aspects to the exclusion of technical ones, whereas a developer may have a complementary view. Different developers may focus on different details to the exclusion of others: one developer may value emphasis on a loosely coupled architecture but be less concerned by testing, whereas another may view agility solely in terms of unit tests and task automation. Each perspective is valid, but missing the other perspectives means missing the whole picture.
Inside the Agility Cube (Part 1)— There are many sides to agile development, but it is all too common to focus on only one or two, depending on personal interests, job role, background, etc. A manager may focus on organizational and process aspects to the exclusion of technical ones, whereas a developer may have a complementary view. Different developers may focus on different details to the exclusion of others: one developer may value emphasis on a loosely coupled architecture but be less concerned by testing, whereas another may view agility solely in terms of unit tests and task automation. Each perspective is valid, but missing the other perspectives means missing the whole picture.
Scrum (Part 2)— In this presentation I will give an in-depth introduction to this methodology and of some of the problems that may happen during its implementation, along with some hints and tips for their solution. I'll also give some references for the ones willing to know more. The goal is to give the attendees enough knowledge to get started without getting burned.
Scrum (Part 1)— In this presentation I will give an in-depth introduction to this methodology and of some of the problems that may happen during its implementation, along with some hints and tips for their solution. I'll also give some references for the ones willing to know more. The goal is to give the attendees enough knowledge to get started without getting burned.
Typical pitfalls in Agile Software Development— Many teams, projects and even organizations are following meanwhile an agile process. However, not always successfully. If you're looking behind the scenery, you will find out that although the agile practices like pair programming or test-driven development are used properly, the agile value system is not implemented. This is due to the fact that the practices can support agility but they can not establish agility. This leads to an expectation mismatch regarding acceptance and success of agile development.
