Why so Agile?

Change is hard.  The largest obstacle to any organization looking to adopt more agile development practices is that transition - we are creatures of habit and now we are being asked to do something else.  One of my favorite 'Agile Dudes', David Hussman (www.devjam.com) talks about Dude's Law - Value equals 'Why' divided by 'How' (V = W / H).  The point here being that the more we can focus on why we are doing something rather than how to do something, the more value we will get from it.  When we look at agile adoption, keeping Dude's Law in mind will help with the pain of change - explaining to our co-workers why we are looking to do something, instead of telling them the new way to work will be better accepted and ideally lead to an environment that promotes continual improvement.  With that being said, I wanted to put together a quick list of some items you might be interested in trying, and why you would want to do such practices.

Short, focused, development cycles
Why would you want to have short, focused development cycles (called sprints or iterations)?  For a few reasons.  If you are struggling with late discovery of defects or need your product development to be more open to change, you may want to consider shorter development cycles.  The later a defect is caught, the more costly it is to fix it. When we find a defect before much code is built on top of it, it can be fast to fix.  If we find the issue after it is in production, there might be a ripple affect as well as impact to our customers.  Additionally, the more frequently we can ask our customer 'Is this what you were thinking?' the easier it is to course-correct our product and end up with what the customer wants.  Finally, having product-focused development cycles allows us to take cross-cutting rips into the software to get real, deliverable progress happening.

• As a developer, short, focused cycles help me know if my code is delivering to expectations.
• As a tester, short, focused cycles help make sure I don't get overrun with testing 2 weeks prior to a product launch.
• As a product owner, short, focused cycles help me see the product emerge and course-correct with lower cost and impact.

Quick daily meetings to check the pulse of the team
You have enough meetings, why would you want to have an additional meeting every day to see how the team is doing (called daily standups)?  If your development teams spend more time 'waiting for help', whether it be answering a question or assistance from a peer, a daily check-in might help.  This daily meeting allows agile teams to get together to see if they have anything (questions, environment issues, etc) that is affecting their availability to complete the work they committed to delivering for this development cycle.  It also allows the team to see if anyone needs help, even if they aren't openly asking for it.  It is not meant to be micro-management, its intent is to focus on whether or not the team is going to be able to deliver on what they committed to.

• As a developer and a tester, daily meetings help me raise any issues I have and get them resolved as quickly as possible.
• As a product owner, daily meetings help make me aware of any questions holding up the team, and answer them immediately and in context.

Project an understanding of when something is 'done'
During the software development process, why would you want to talk about functionality, with examples that show intent and create an understanding of when something is done?  This approach gives us a very binary way of looking at work.  When work is either 'done' or 'not done', it's very easy to measure progress.  With this approach, a piece of functionality isn't 85% complete after 1 week and 86% complete after a month. Instead it is either done and accepted as working by a customer, or not working with examples of how to get it accepted.

• As a developer and a tester, a common understanding of done with examples helps provide me with context and helps me focus on the work to be delivered, instead of the possible permutations I can come up with.
• As a product owner, a common understanding of done with examples gives me confidence that what I am looking for is what I will receive. Combining this with short, focused development cycles lets me verify that the team is all on the same page.

Automated Testing
Why would you want to automate your testing?  Testers are far better at finding new and interesting ways to test your application beyond repeating common functionality repeatedly. If you find that your agile testing team is spending more time than they would like redoing the same work, you might want to consider automation.  But lets be honest - some testing cannot be automated, or is simply far too costly to automate for it to make financial sense.  For the rest of testing, we would want to have automated testing in place to tell us as soon as possible when something has either been completed successfully or has been broken by a change.  Automated testing is not 'automate everything and run it all the time' - it is automate what makes sense, and run it as frequently as it makes sense.  This might mean that some tests run with all builds, some run every night, and some run with every formal build and deploy.

• As a developer and a tester, automated testing helps me focus on quality, and notifies me as soon as possible if problems are arising.
• As a product owner, automated testing helps me visualize work complexity and effort.

Continuous Integration
Why would you want to have your code compiled and any automated tests that can be run against it executed, every time a piece of code is committed?  Similar to the reason for short development cycles, look at continuous integration as providing feedback into your short coding cycles.  The goal with continuous integration is to find out as soon as possible if our code is breaking anything else.

• As a developer and a tester, continuous integration helps me know how well the team is delivering code dependent upon each other.

Relative Estimation
Why would you want to estimate all of the work needed to complete a project relative to other work in the same project, instead of just committing to milestones?  Estimating software development projects is hard, and the further we go out in time and duration, the closer to impossible it becomes.  If we are having problems with the timeliness of our deliverable, we may want to look at estimating work relatively. This way, after some portion of the work is completed, we can extrapolate how much longer it might take to complete the whole project.  This allows our team to have more meaningful and real dialogue.  It should also lead to more realistic expectations.

• As a developer and a tester, relative estimating helps me provide visibility into the effort required to complete a project that actually takes into account work distractions - other projects, context switching, organizational meetings, support, etc.  As a developer and a tester, relative estimating can be my voice of reason.
• As a product owner, relative estimating helps me understand what pieces of functionality are most difficult and helps me balance the cost of functionality versus the benefit of having it in the product.

With the exception of automated testing and continuous integration, notice that these other items are valuable in the context of any work that needs to be delivered - whether it be creating a marketing campaign, recruiting, or doing housework.

Do any of the above items sound like a problem you would like to solve?  Then you might be interested in looking into some of the 'how' (practices) that assist with these 'whys'.