Agile Modeling Strategies Lean Startup Agile Process Proverbs
Agile Software Development: A gentle introduction
To move quickly and easily.
The processes we describe as Agile are environments for a team to learn how to be Agile.
The most brilliant programmers alive working competitively in an ego-rich environment canât get as much done as ordinary programmers working cooperatively as a self disciplined and self-organizing team.
You need a process where team empowerment and collaboration thrive to reach your full potential.
The second change is making the customer the one who funds the software development, a valuable and essential team member.
When the deadline gets close, a traditional approach to reducing scope is to let the developers decide what will work properly and what wonât.
Instead let the customer make scope decisions a little at a time throughout the project.
When your customer, or domain expert works directly with the development team everyone learns something new about the problem.
True domain expertise and experience is essential to finding a simple, elegant, correct solution.
A document can have plenty of information, but real knowledge is hard to put on paper.
Left alone programmers must assume they know everything they need.
When asking questions is difficult or slow the knowledge gap grows.
The system will get built, but it wonât solve the problem like one guided by an expert on a daily basis.
Perhaps the biggest problem with software development is changing requirements.
Agile processes accept the reality of change versus the hunt for complete, rigid specifications.
There are domains where requirements canât change, but most projects have changing requirements.
For most projects readily accepting changes can actually cost less than ensuring requirements will never change.
We can produce working software starting with the first week of development so why not show it to the customer?
We can learn so much more about the project requirements in the context of a working system.
The changes we get this way are usually the most important to implement.
Agile also means a fundamental change in how we manage our projects.
If working software is what you will deliver then measure your progress by how much you have right now.
We will change our management style to be based on getting working software done a little at a time.
The documents we used to create as project milestones may still be useful, just not as a measure of progress.
Instead of managing our activities and waiting till the project ends for software, we will manage our requirements and demonstrate each new version to the customer.
It is a hard change to make but it opens up new ways to develop software.
We visualize the activities, our process itself as the constant.
Our process is applied to our user stories in sequence. The activities are on going and the user stories get what ever they need.
Donât panic.
With professional software engineers on our project we can relax knowing that the team will do what is needed to get the job done.
Any activity needed with any combination of people will just get done without any further scheduling or ceremony. This is the spirit and benefit of a self organizing team.
So now when we create our schedule we pencil in the features in order of importance.
This offers us a different kind of efficiency;
we can change our minds about what we want without huge cost over-runs.
We can also stop at any time and have the most important features done.
An Agile process takes the traditional process and turns it 90 degrees on its side.
This allows managers to get an estimated cost per feature instead of per activity.
Customers can make the difficult decisions about what can be left undone in an intelligent way.
If you find yourself running short on money you will not have wasted your money on analysis and design for features that will never be coded and tested.
Costs make more sense this way since customers canât pick and choose which activities should be done.
This gives us a âshopping listâ style of requirements and planning.