1. Agile 1.0 The fundamentals “ Progress is impossible without change; and those who cannot change their minds cannot change anything.” George Bernard Shaw
3. Goal It's not about convince you to adopt Agile. It's about what Agile is , what Agile IS NOT and which are it's principles .
4.
5. Traditional approach Too risky! Software is not a car! Requirements Design Implementation Testing Support
6.
7. The agile approach Development Development... Release Feedback Adjustments Release Iteration Life cycle of an user story. Integrate and test Integrate and test Integrate and test START ITERATION
23. Agile Manifesto: History Kent Beck 1995 Jeff Sutherland Ken Schwaber 1996 2004 Mary Poppendieck David J. Anderson Tom Poppendieck 2003 1997 Alistair Cockburn 2001 Kanban XP Scrum Lean Crystal Clear The Agile Manifesto
24.
25.
26.
27.
28.
29. Next steps Agile Toolkit Podcast: Bob Payne & George Dinwiddie Read the 12 principles WE ARE HERE NEXT PRESENTATION
Notes de l'éditeur
Hi, I'm Greivin López and this is Agile 1.0: The fundamentals. First of all I want to thank you, I really appreciate that you take the time to being here.
My current plan is to create a series of presentations about Agile development starting with this one as an introduction and progressively advance until a point we hopefully understand enough of the subject to take real advantage on our daily work. I plan to start with the fundamentals, then talk about teams and projects and continue with agile techniques.
There is no value in trying to convince you to adopt Agile development. This is not about traditional projects vs. Agile projects. And certainly is not about showing off my knowledge of Agile. This presentation is about me trying to teach you What Agile is , what Agile IS NOT , and which are its principles.
Let's start with these three simple thoughts: Change is the only constant We don't know the future Context is relevant Those are three key points that traditional software methodologies underestimate but are essential.
Let's talk a little bit about the problems with the traditional way of create software. At some point in the past people start thinking that software products can be made in the same way we manufacture cars or other product: by using an assembly line. Then naturally that thought evolve into the traditional waterfall approach. One big problem with this approach is that leaving testing to the end of the project is too risky. And also software is not a car. Then you could not make it in this way.
I'm pretty sure you are familiar with this small list of common problems: Missed deadlines Budget blow-outs Overworked and stressed employees Knowledge silos Strict contracts that not allows you to include new features in an ongoing project
So what is different in Agile? In the agile approach all those steps are done in parallel within short development cycles known as iterations which usually takes from one week up to one month. Also in agile you don't leave testing to the end of the project. And you never stop writing code. Development is continuous and also testing is continuous, so you don't wait for months to find out that something is wrong: you find out quickly while it's still relatively easy to fix. And you fix it immediately.
Lets discuss about why to use agile, which are it's benefits? This is something we are doing well on Possible Worldwide: Customer collaboration. Business people and development team working together to deliver something of value.
That Customer collaboration lets you avoid this common problem: Early assumptions and misunderstandings. Through collaboration with the customer you are constantly receiving advice, feedback and new requirements so you're able to change your action plan accordingly.
Delivering soon gets you real, end-user feedback long before you've invested a lot in a risky feature. Having short cycles allows you to tweak things faster and adapt faster so you minimize the risk.
Feedback from real users keeps you in tune with the changing marketplace. Internally, you continually improve your team always knowing that adaptation is essential in Agile.
By using agile development practices such as Test driven development, constant refactoring, continuous integration and automated tests, you can be proud of the quality of the product you deliver to your customer.
After talking about why people use Agile let me give you this warning: Agile is not for everybody. Do I think one day everyone is going to be working this way?. Absolutely not. Why? For the same reason most people don't eat right and exercise. People are lazy, always have an excuse and resist to change. To adopt agile you need people willing to make things done, someone who is comfortable doing coding, designing and testing. It puts you on the spotlight, so you have to take responsibility of your work every iteration and not at the end of the project. Some people is not proactive enough and have not the discipline needed to work with Agile development.
Let's talk about the concept of being agile. What does it mean to “be agile”? : The answer is more complicated than you might think. Agile development isn’t a specific process you can follow. To “be agile,” you need to put the agile values and principles into practice. Being agile is not an end in itself because the key is not “being agile”, the key is effective communication and collaboration.
No team practices THE AGILE method. There’s no such thing. Agile development is a philosophy. It’s a way of thinking about software development. The more recognized description of this way of thinking is the Agile Manifesto which we are going to discuss later. A method, or process, is a way of working. Agile methods are processes that support the agile philosophy. Examples include Extreme Programming and Scrum. Agile methods consist of individual elements called practices. Practices include using version control, setting coding standards, doing pair programming or giving weekly demos to your stakeholders.
This is precisely what I was talking in the previous slide. Agile is not a methodology, it's a philosophy. Methodologies are only flavors of Agile. They put the agile values into practice.
OK. Let's talk about the Agile Manifesto. In any discipline in order to achieve mastery level you must start with the fundamentals. In agile development we must start with the agile manifesto.
Let's start with a little bit of history. Software development methods evolved in the mid-1990s as a reaction against "heavyweight" methods which were characterized by heavily regulated, micromanaged and full of unnecessary documentation. They were too rigid. It was back then when a new trend emerged and was known by the term “lightweight” development methods. Early implementations of that methods were: Scrum, Crystal Clear or Extreme Programming.
Later, on February 2001, 17 recognized software developers met in Snowbird, Utah to discuss about this new way to create software. These 17 folks created the term “Agile” and they published the Agile Manifesto to describe a refocused approach to software development: an approach that emphasizes people, collaboration, responsiveness, and working software. This is a large group of people who do not easily agreed in something. They're strong individuals with great influence in the software community and like all smart people, they tend to think they're right all the time. So the fact that those people agreed in those values has a deeper meaning to all of us in the software industry.
The first value is: Individuals and interactions over processes and tools. The processes and tools are there to serve the people not the other way around!, in agile people matter! Dave Thomas believes that the heart of a project is not the methodology but the people. Members of the team need to be technically competent, motivated, and aligned. It is extraordinary important that everybody works together. You have to trust your team to get the job done instead of wasting your time using tools to make sure they are. People are not resources, you could not treat them like natural gas or oil. You have to make use of your people's brains because that's what you are paying for. Software creation speed is not limited by typewriting speed but by thinking speed. Give your people authority to figure out what to do to get things done. It's assumed that everyone on the team (and working with the team) are professionals who want a positive outcome from the project. They may not necessarily be experienced professionals yet, but they have a professional attitude. Everyone wants to do their best.
The next value: Working software over comprehensive documentation. Keep an up-to-date documentation it's a distraction more than a benefit. From the customer point of view it is more important to get software out to deliver value early. Reducing the amount of work not done allows the team to start delivering value early. Simplicity is essential. Create documentation only when it is absolutely necessary and where it brings value to the project. Face to face conversation is the most efficient and effective method of conveying information. Architecture diagrams are good, but most of the time it's not translated in the final implementation. The best architectures, requirements, and designs emerge from self-organizing teams. Working software is the primary measure of progress. Software that is 90% done, is of zero value. If it doesn't quite work, then it doesn't work. The keys here are: continuous attention to technical excellence, good design and best practices. And those are underestimate by a lot of people even in the Agile community. Those keys are essential to tight up everything else. Team members of the agile project needs to be involve in testing, designing and writing the code and that really makes a huge difference!.
The next value: Customer collaboration over contract negotiation. When you got the costumer working side-to-side with the team both of then benefit!. Customer collaboration is what allows the team to deliver value on a daily basis. Ask the users what features are essential to make the product usable. Don't be distracted by nice features you might possibly have before project starts. Concentrate first on the really important features from the user point of view.
And the final value: Responding to change over following a plan. Change is the only constant. Responding to change is being able to change course as business require. Welcome changing requirements even late in development. You need to be willing to change your architecture when requirements change. The business environment changes faster and faster each year so your company can't afford to make unchangeable plans months ahead.
Which are the next steps? The next steps in our Agile learning is to read the 12 principles behind the Agile Manifesto and listen to Bob Payne and George Dinwiddie talking about it. I'll be sending to you their discussion by e-mail and then we get together for the next presentation about Agile Teams and Projects.. Thank you.
