Agile Introduction
April 22 2009, 1:20 AM
Spent a day in training yesterday getting an overview to agile
development. I came away with the concept that it is another way to
manage projects. You start with a fixed time and resource and then you
have to make the interested parties decide which functions are the most
important and to agree that other functions may not get done. As seems
to be a common theme in project management it is very focused on
communications, both internally within the teams that are doing the work
and also with the stakeholders ( Oh yes, it would be a great course for
playing buzzword bingo). There are various sets of guidelines for agile development but they all
follow the same set of guiding principles. There is more details found
on the Agile Alliance website http://agilealliance.org/ There are some fundamental differences from standard projects that
Agile requires. The project has to be broken down into small chunks of
30 days or less and these are fixed times. Within that time you have a
set of features that you must complete, a set that you should complete,
and some that you could complete. You only guarantee to the business
that the musts will be done but you plan that all the shoulds will be
done. That way everybody knows what is going on. Each of the features, or requirements in agile terms, is defined in terms
of a business process or non-literal process. Each of these should be
small, at most a couple of days work. Then in your daily meeting you
deal with what has been done and what is still to do. No percentages. Planning your time is done using the planning game. Take all your
requirements and find the one that will take the shortest time to
complete. This will be one work unit. Now define all the other tasks in
terms of the number of units they will take. If a task takes more than
three units of work then call it "big". Review all the "big" tasks and
break them down to be smaller tasks that are less than three. Simple.
Again this reflects a lot of project management systems, always break it
down. Then over time you get a better idea for how long each unit takes
and you can estimate. I am assured that you can get to within 10% of the
correct time and that that is very good. Welcome change. As you only work in 30 day chunks and review at the end
of each stage with users and stakeholders, there is that word again, you
can tackle the change that happens in a project in a simpler form. If
the uses get a look at the first revision and decide that some bits are
more important or that the requirements have changed then you can agree
to those changes but they have to accept that some of the other
requirements will not get done. Again keeping you fixed on time and
budget while allowing you to refine the project to be what the user
wants. This again is about communication as much as anything. Allowing
users to see prototypes and provide feedback as the project progresses
means that they can start to think about how they will acctually use the
system and provide feedback that is useful now rather than a large "It's
no good" at the end of the project. Overall it made a lot of sense to me but as with all the concepts it
something that everybody has to agree on and work at. There are concepts
like having the project manager be just that and not just somebody
working on the project or the small time limited working sections that
may take some time for people to accept. Time for some more reading...
development. I came away with the concept that it is another way to
manage projects. You start with a fixed time and resource and then you
have to make the interested parties decide which functions are the most
important and to agree that other functions may not get done. As seems
to be a common theme in project management it is very focused on
communications, both internally within the teams that are doing the work
and also with the stakeholders ( Oh yes, it would be a great course for
playing buzzword bingo). There are various sets of guidelines for agile development but they all
follow the same set of guiding principles. There is more details found
on the Agile Alliance website http://agilealliance.org/ There are some fundamental differences from standard projects that
Agile requires. The project has to be broken down into small chunks of
30 days or less and these are fixed times. Within that time you have a
set of features that you must complete, a set that you should complete,
and some that you could complete. You only guarantee to the business
that the musts will be done but you plan that all the shoulds will be
done. That way everybody knows what is going on. Each of the features, or requirements in agile terms, is defined in terms
of a business process or non-literal process. Each of these should be
small, at most a couple of days work. Then in your daily meeting you
deal with what has been done and what is still to do. No percentages. Planning your time is done using the planning game. Take all your
requirements and find the one that will take the shortest time to
complete. This will be one work unit. Now define all the other tasks in
terms of the number of units they will take. If a task takes more than
three units of work then call it "big". Review all the "big" tasks and
break them down to be smaller tasks that are less than three. Simple.
Again this reflects a lot of project management systems, always break it
down. Then over time you get a better idea for how long each unit takes
and you can estimate. I am assured that you can get to within 10% of the
correct time and that that is very good. Welcome change. As you only work in 30 day chunks and review at the end
of each stage with users and stakeholders, there is that word again, you
can tackle the change that happens in a project in a simpler form. If
the uses get a look at the first revision and decide that some bits are
more important or that the requirements have changed then you can agree
to those changes but they have to accept that some of the other
requirements will not get done. Again keeping you fixed on time and
budget while allowing you to refine the project to be what the user
wants. This again is about communication as much as anything. Allowing
users to see prototypes and provide feedback as the project progresses
means that they can start to think about how they will acctually use the
system and provide feedback that is useful now rather than a large "It's
no good" at the end of the project. Overall it made a lot of sense to me but as with all the concepts it
something that everybody has to agree on and work at. There are concepts
like having the project manager be just that and not just somebody
working on the project or the small time limited working sections that
may take some time for people to accept. Time for some more reading...