Why so Agile?

I’ve said it before, and here I am saying it again – 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’.

For more on Dude’s Law and David Hussman, check out his website at www.devjam.com or follow him on twitter @davidhussman.

David has posted his thoughts on Dude’s Law and other things here – http://devjam.com/dudesblog/dudes-law/

This entry was posted in Agile Adoption, Agile Development, Agile Testing, Continuous Integration, Scrum Development. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>