A Quick Introduction to Agile Development:

What Agile is not:

Agile is no one thing. It is not a single methodology or set of practices, nor does not hold hard and fast to one rule. Agile does not claim to be the only solution.

What Agile is:

Agile is a way of thinking about software development. It is about being open to change in software requirements. Agile is about being ready for inevitable hurdles and being able to easily adapt.

But you ask: "Doesn't COSGC have a set of practices that they attribute to agile development? Don't we do a whole lot of things in order to practice Agile ideals, for which you say there are no set of practices?!" Fair enough, let me see if I can explain... First, go ahead and read the Agile Manifesto.  

The Agile Manifesto:

http://agilemanifesto.org/

This outlines the principles upon which Agile development methodologies are built. Agile methodologies are sets of practices that help teams become more agile. These practices allow teams to move, change, and develop in a way that's optimal for them, their teams, their corporations, and ultimately, and most importantly, their customers. The customers' needs must be met for software developers to succeed.

Now, if Agile is about adapting to change, this is how we set ourselves up to do that:

1. Set deadlines.... and meet them.

     This sounds simple enough. Doing this builds a trusting relationship between you and your customer, management and builds confidence as a team---- but, anyone that's worked on a software team for any length of time can tell you: THIS IS HARD! It's hard for a lot of reasons. Deadlines shift, requirements change, you've just finished a feature and now its obsolete and the new one needs to be done by next week. We've all been there. So how do we fix this? For one, there has to be a way to gauge how much work a software team can do.We do this by using metrics. Firstly, we see how much time everyone is allotted over a sprint's duration. For example, if a team member is assigned to work 10 hours a week and it's a four week sprint, that person has 40 hours.

The next thing to factor in, is how much time that person can spend writing new code. This is probably between 40% and 60% of their time. The rest of their time they'll spend going to meetings,  fixing existing bugs, wrestling with tools, researching, etc. This is time that must be accounted for when giving someone from management a reasonable estimate of what can be accomplished. Promising to accomplish things that can't technically be accomplished in the time frame, well, that pretty much guarantees failure. Let's not do that.  

2. Make sure we don't get stuck!

      Communication is key! When you're having a problem that prevents you from getting work done, it's not just your problem; It's the team's problem. All team members must be willing and available to help motivate the productivity of the team as a whole.

3. Own your work.

      If you're assigned to complete a piece of code, look at it from every angle. Make sure that that piece of code is the best that you can deliver to the team. If that means working with someones else, or asking for help, the end product is still what you make it!

4. Keep improving!

      Learning Agile development takes a lot of time. It's prone to failures as teams and team members learn how to most effectively adjust their working styles towards Agile values. We can get good at it, but we've got to keep practicing, learning, and improving!

Sprint Planning and Backlog:

Silver Catalyst - (must be on campus or connect via VPN) Silver Catalyst is an Agile Planning tool. We use it to plan iterations of software development. An iteration generally lasts 2-6 weeks, and at the end of it, some software product is released. These releases are not feature complete in and of themselves, but each iteration strives to focus on a certain set of tasks and features that are agreed upon by the software team and project managers. This tool allows us to plan out how much time each programmer has, and theoretically how much they can accomplish. This helps the software team give realistic estimates on the time it will take to deliver to their team. The metrics are not perfect, and the only way to make them better is to work together as a team, and live up to our method, and adjust as we need to in order to best accommodate our software engineers and our satellite teams!