Development processes have fundamental problems they address, a philosophy by which they try to solve that problem and methods by which they implement that philosophy.
Problem that Agile solves is ever changing requirements of enterprise applications.
There are those who laugh at Agile for how awfully it would fail in building an air plane (technically speaking, proper agile will not fail, but it’s not at all the correct process to use there) and then go try to make an information system to a galactic government using a formal process and fail even more miserably. (I wanted to say kite, but wanted to emphasize size is not the problem). And this goes vice versa.
Smart project teams chose the right process for the right project. They don’t brand themselves as agile or formal. They are simply good engineers who are good at applying proper solution for the problem at hand right from the process itself.
Thursday, June 16, 2011
Tuesday, June 14, 2011
How’s your agile process working for you?
Are you practicing an agile process in your team? Do you still find your team working through the night? Do you still find your software to be rigid, fragile and immobile? Do you still find changes of requirements to be nightmares to the developers? How do you suppose those situations are possible with an Agile process?
Unfortunately, this is the situation in almost all Agile practicing and Agile preaching companies we have around in Sri Lanka. I’ve crossed my paths with quite a few developers from these companies and they all have the same story to tell; agile for them, is the same old cycle, without the documentation and without a designing phase - which makes their development life worse. Non-technical project managers are still around, being called by other names, and to add to the misery, now the customers bring the pressure directly to the developer - because it’s “Agile”.
Is Agile a bad idea? What’s going wrong? Why can’t we make it work? Have you seen the list of names in the Agile manifesto at http://agilemanifesto.org/? Do you think those are the kind of people who would invest on a failing process? Besides, they’ve been practicing and teaching it for over a decade now. So if there’s anything wrong with Agile, it’s more likely in the way we practice it.
Management elements such as deadlines, budgets and sucking up to customers’ aside, we developers too need to change some fundamental ideologies towards development in order to make Agile, well Agile. It is not to say that the operational model doesn’t matter, indeed, that’s what makes Agile possible. Someone should be available to the team to represent the customer, acceptance tests should be automated and made available to the developers when feature requests / changes are made; team should be responding to changes than follow a plan; team should be able focus on getting a working product out instead of documenting etc. etc. which all agile gurus will tell you; but the part they don’t speak about; the part the folks came up with agile manifesto took for granted; the part that is responsible for more than half the agile failures in Sri Lanka is with the developers.
One misconception most developers in Sri Lanka have about Agile development is, it is coding without design or documentation. The other misconception is to think getting software to “work” means getting the functionality out one way or another. The Agile philosophy has very different interpretations for these and is defined with the implied expectation of strong object oriented concepts and design principles of the developers.
By the term “a working product” what’s meant is a functional, testable and maintainable product. Not just functional. If a piece of code provides the functionality required, but only the developer himself could read and understand how it does that, it is not a working product by Agile definitions. Developers are to get the code to work and then refactor till it’s readable, not duplicating code and as simple as it could be but not simpler.
Refactoring to make code readable, non-duplicative, simple and free of unused design complexities and code is a constant practice that developers are expected to follow whenever they code something.
The design focus of Agile is much more implied than explicit. In each iteration, Agile focus on getting a working product to the customer. The team narrows their focus only on the features that are planned for that iteration making it as simple and expressive as possible; yet not losing the overall picture - or at least what exist of it at the time. This practice makes sure that the design never gets complicated than necessary and serves to the problem at hand than expected (but volatile) problems of the future. One of the problems in designing the whole application at once is that the architect is force to foresee requirements of the future; with requirements ever changing and little understanding of them to begin with; this is not a task someone could get 100% right. That’s why Agile promotes this simplistic approach which could accommodate changes more easily.
Unit Tests for agile developers are a design practice than a verification step. Writing the non-compiling unit test is defining the contract for a component. Developer should do due diligence and consider who are the consumers and think how the consumers would want to use a class. Note that the tests are written for the public interface of the class, the tests care only about the functionality exposed through that. Once the developer get the unit tests to pass, he can then go on refactoring his code to be simple, readable and non-duplicative - one step at a time - without worrying about breaking the functionality unknowingly; because the tests are there to guard against that.
The next aspect of design developers ignore in Agile is how exactly the changes are accommodated. Remember that agile designs are as simple as possible meaning that when code is first written, it is not accommodating flexibility for “potential” change. But when the first change comes, the developers should follow the object oriented design principles and separate the changing elements of code from the non-changing elements of code, evolving the design in that part, so that a second change in the same area would be easier and simpler than the first. This practice prevents the code becoming stale over repeated changes, still keeping the code as simple as possible.
As always, developers should keep themselves up to date not only with the new technologies but of the time proven concepts; and the organizations who wish to harness the benefits of any methodology should invest on getting their developers in par with that methodology.
References
Agile Principles, Patterns, and Practices in C# By Robert C. Martin, Micah Martin
Agile Software Development: The Cooperative Game, Second Edition By Alistair Cockburn
Test-Driven Development By Example By Kent Beck
Unfortunately, this is the situation in almost all Agile practicing and Agile preaching companies we have around in Sri Lanka. I’ve crossed my paths with quite a few developers from these companies and they all have the same story to tell; agile for them, is the same old cycle, without the documentation and without a designing phase - which makes their development life worse. Non-technical project managers are still around, being called by other names, and to add to the misery, now the customers bring the pressure directly to the developer - because it’s “Agile”.
Is Agile a bad idea? What’s going wrong? Why can’t we make it work? Have you seen the list of names in the Agile manifesto at http://agilemanifesto.org/? Do you think those are the kind of people who would invest on a failing process? Besides, they’ve been practicing and teaching it for over a decade now. So if there’s anything wrong with Agile, it’s more likely in the way we practice it.
Management elements such as deadlines, budgets and sucking up to customers’ aside, we developers too need to change some fundamental ideologies towards development in order to make Agile, well Agile. It is not to say that the operational model doesn’t matter, indeed, that’s what makes Agile possible. Someone should be available to the team to represent the customer, acceptance tests should be automated and made available to the developers when feature requests / changes are made; team should be responding to changes than follow a plan; team should be able focus on getting a working product out instead of documenting etc. etc. which all agile gurus will tell you; but the part they don’t speak about; the part the folks came up with agile manifesto took for granted; the part that is responsible for more than half the agile failures in Sri Lanka is with the developers.
One misconception most developers in Sri Lanka have about Agile development is, it is coding without design or documentation. The other misconception is to think getting software to “work” means getting the functionality out one way or another. The Agile philosophy has very different interpretations for these and is defined with the implied expectation of strong object oriented concepts and design principles of the developers.
By the term “a working product” what’s meant is a functional, testable and maintainable product. Not just functional. If a piece of code provides the functionality required, but only the developer himself could read and understand how it does that, it is not a working product by Agile definitions. Developers are to get the code to work and then refactor till it’s readable, not duplicating code and as simple as it could be but not simpler.
Refactoring to make code readable, non-duplicative, simple and free of unused design complexities and code is a constant practice that developers are expected to follow whenever they code something.
The design focus of Agile is much more implied than explicit. In each iteration, Agile focus on getting a working product to the customer. The team narrows their focus only on the features that are planned for that iteration making it as simple and expressive as possible; yet not losing the overall picture - or at least what exist of it at the time. This practice makes sure that the design never gets complicated than necessary and serves to the problem at hand than expected (but volatile) problems of the future. One of the problems in designing the whole application at once is that the architect is force to foresee requirements of the future; with requirements ever changing and little understanding of them to begin with; this is not a task someone could get 100% right. That’s why Agile promotes this simplistic approach which could accommodate changes more easily.
Unit Tests for agile developers are a design practice than a verification step. Writing the non-compiling unit test is defining the contract for a component. Developer should do due diligence and consider who are the consumers and think how the consumers would want to use a class. Note that the tests are written for the public interface of the class, the tests care only about the functionality exposed through that. Once the developer get the unit tests to pass, he can then go on refactoring his code to be simple, readable and non-duplicative - one step at a time - without worrying about breaking the functionality unknowingly; because the tests are there to guard against that.
The next aspect of design developers ignore in Agile is how exactly the changes are accommodated. Remember that agile designs are as simple as possible meaning that when code is first written, it is not accommodating flexibility for “potential” change. But when the first change comes, the developers should follow the object oriented design principles and separate the changing elements of code from the non-changing elements of code, evolving the design in that part, so that a second change in the same area would be easier and simpler than the first. This practice prevents the code becoming stale over repeated changes, still keeping the code as simple as possible.
As always, developers should keep themselves up to date not only with the new technologies but of the time proven concepts; and the organizations who wish to harness the benefits of any methodology should invest on getting their developers in par with that methodology.
References
Agile Principles, Patterns, and Practices in C# By Robert C. Martin, Micah Martin
Agile Software Development: The Cooperative Game, Second Edition By Alistair Cockburn
Test-Driven Development By Example By Kent Beck
Sunday, June 12, 2011
Subscribe to:
Posts (Atom)