Scrum is one of the most well known agile methodologies. It has several characteristics which make it very attractive; some of them are:
1. Simplicity. Its basics can be learned in less than a day
2. Flexibility. It can be customized to fit the needs of the project
3. Scalability. It has been used in projects with up to hundreds of developers
4. Visibility. All the issues that may arise during the project lifetime become immediately visible. This makes their solution easier.
However, its implementation can sometimes be difficult. Scrum, like all other agile methodologies, is heavily based on teamwork, communication, trust, and on delegating responsibility and authority. All these things together represent a major cultural shift especially for companies used to more traditional methods which, usually, requires time and hard work to be fully accepted.
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.
Giovanni Asproni is a freelance consultant with more than ten years of professional experience in which he had the opportunity to work in several different roles, from Programmer to Senior Architect and Technical Project Leader, in a variety of application domains including CASE tools, telecommunications, bioinformatics, and banking.
He is an expert in Object Oriented Design and Development, Agile Software Development, and a Certified Scrum Master. He is a member of the conference committees for the London XPDay and the ACCU spring conference and also member of the ACCU, the AgileAlliance, the ACM, and the IEEE Computer Society.
Evolving Agile— 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.
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 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.
