In about 5 minutes I’m going to play the role of being a “doctor” at the Scrum Clinic which is part of the Orlando Scrum Gathering.  It’s an interesting concept.  A doctor and a patient meet to discuss a topic important to the patient.  In my case the patient wants to talk about the Scrum Alliance Certified Scrum Coach (CSC) program.  Since I am a CSC and all of my CSC brethren wimped out I’ll be the one acting as doctor.  I’m looking forward to it so I’m only kidding about the rest of them wimping out!

More on the Scrum Gathering later this week.  It’s bee great so far!

Related posts:

1. I’m a Certified Scrum Coach (CSC) – so what? I’ve asked myself that question more than once in the 5 or...
2. New to agile? Watch an Intro to Scrum video in about 8 minutes My friend, Arif Gangji, and I created this video to help his...
3. Agile antipattern: Waiting for all the requirements before starting Time for a short blog entry (I tend to be way too...

Most everything in writing software is about finding balance and making the right tradeoffs. We must understand the impact of our decisions on our work and seek to minimize cost while maximizing value. Sometimes we have to write a crappy implementation to get it to our customers but let’s acknowledge that we are doing it and give ourselves permission to go back later and clean it up.

One thing that I have discovered about software development is that it is not pay now or pay later. I used to believe that doing things right would pay off in the long run but cost more in the short run. Having worked with outstanding developers who write clean code and do it faster than 99% of the developers I’ve met, I realize it is really about our habits and what we do under stress.

If we make quality our habit then it will always be faster for us to write quality code then to write crappy code. How do we do this? First we need exposure to the right development practices that promote quality without undue burden. The development practices that I promote in my Agile Software Development Essentials class are easy to learn and require no extra time to do yet they have a huge impact on the quality of the code we produce. Then we must keep these principles and practices top of mind so they become our habits.

They say it takes 21 days to form a new habit. In my experience it takes at least a few months to really get good at using these practices. It’s not learning new practices that are the hard part; it is unlearning our old way of doing things. If you are an old guy like me then this may take some time but it is worth it.

My friend, Arif Gangji, and I created this video to help his customers understand why his company uses Scrum as their software development framework. I decided I really liked the video, so I’m posting it here as well. It isn’t perfect, but it is plenty good enough to get across the basic ideas of Scrum. Over time it will probably show up in a few more places on the main website, but for now, enjoy!

Click here to view the embedded video.

I’d love to make our next video even better so if you have suggestions please put them in the comments below.  Thanks!

Until next time I’ll be Making Agile a Reality^® by pointing people to this video for some introductory information about Scrum.

Related posts:

1. I’m a Certified Scrum Coach (CSC) – so what? I’ve asked myself that question more than once in the 5 or...
2. Orlando Scrum Gathering – I’m going to be a doctor soon! In about 5 minutes I’m going to play the role of being...
3. New to agile? Work at a sustainable pace Question:  Which is better: a) Working nights and weekends to meet iteration...

The Agile Software Development Essentials class is coming back to San Diego on May 5-7, 2010. For more information, click here.

Have you ever had a computer meltdown?  OK, so myIT infrastructure meltdown wasn’t as total as the picture to the left, but it still was pretty bad.  In the span of a couple of days I had my main desktop and my main laptop both die.  This happened just before I had several straight weeks of travel and as a result I was left working off of my MSI Wind U100 netbook for a few weeks.  Let me tell you a bit about it and what I learned from it because anyone making a living on the road needs to know this stuff!

First off, let me just say super-redundant backup is a good thing.  In fact, it is a VERY good thing.  Because I had backups available in several different ways the outage didn’t cause me to lose any work.  Groove had always worked in the background to sync my files so the netbook was ready to go.  I use an Exchange server so again the netbook was fine since it could sync just as easily as the other computers.  In fact, most of what I mention in my blog post about a highly mobile team of 1 turned out to be necessary!

The big wins for me were:

1. Having all of the files already sync’d from Groove.
2. Having everything in Exchange so I just pointed the netbook to it and let everything stream onto the netbook.
3. Having a netbook which is very capable of running all the Office applications and still be usable.
4. Having enough computer savvy to recognize things were failing and stopping them before they damaged other parts of my IT infrastructure.
5. As usual, Dell came through and delivered my new kick-butt Dell Precision M6500 laptop very quickly.
6. Bringing up the new laptop worked just as my emergency plan said it should!  Install Office, sync w/Groove, sync to Exchange, copy Favorites, etc.  After all the headaches I had, this part of the process was rather nice.

Things that didn’t go so well:

1. The desktop computer was (and is) completely dead.  It powers on and then nothing happens at all.  This really stunk because it had all my personal and family stuff on it.  All of that was backed up, but it still was a pain because I had been very good about separating personal and business items.
2. The laptop would mostly boot, but not quite.  I spent a long time (30+ hours) trying to fix the problem.  Microsoft Windows let me get so close to fixing it, then would make it impossible at the last second.  I wanted to upgrade the Windows on the machine to Windows 7 – no luck because you have to boot from the hard drive for an upgrade to work.  I finally got around that by booting from a USB thumb drive and Windows 7 decided it didn’t know how to talk to the regular hard drive.  Frustrating!
3. My netbook had several Windows Updates, a Java update and an Adobe update to install, but I couldn’t take the chance of installing them.  If the machine crashed I was going to be in big trouble for my upcoming courses.
4. The HP printer drivers once again proved incredibly frustrating for me.  I have NEVER been able to install HP printer drivers and have them work first time.  In this case I installed, uninstalled and reinstalled several times and finally gave up on getting it all working.  I still can’t scan through the network like I could before.  I don’t know why, but the printer is near the laptop so I just plugged in a USB cable and called it good enough.

Things that surprised me:

1. Because I made the decision to just have one main machine (the M6500 laptop) instead of two, I had to put all of my personal information on the laptop as well.  I expected this to be straightforward – copy over old data files, install software and you are up and running.  Wrong.  Quickbooks only allowed a certain number of activations and my backup machines had used those up.  I ended up having to upgrade, which was good, but unexpected.
2. I used Laplink PC Mover to copy data from a semi-working laptop to the new laptop.  I had high hopes for this software, but as it turned out I had to reinstall several items anyway.  If I had known that would be the case I would have just started that way instead of being led astray by the high hopes I had for an easy transition.
3. Windows 7 is really very easy to use and quite nice.  I thought all the advertising was going to turn out to be just hype, but I definitely like Windows 7 - a lot!  Microsoft has made some nice changes.
4. I got a fingerprint scanner on the laptop because it wasn’t expensive and seemed cool.  It is actually very cool.  I can use it to log into the computer but it also came with a program which can store security data for websites.  This can include login information, credit card info, etc.  The difference between this and doing it in a browser is the security involved.  I login using my fingerprint.  It can take a password, but I deliberately made that something even I don’t remember and just stored it in my safe deposit box if I ever need it.
5. I had to put passwords on all of my financial files (Quicken and Quickbooks).  I decided to share these through Groove with the netbook.  I did this because I’m spending more time on the road than I thought I would and I need to keep these things up to date.  Once I did this I realized I needed to protect the data or someone stealing my laptop or netbook would have keys to my financial kingdom.

So in the end I’ve recovered nicely.  I upgraded my laptop and refurbed the old one (a Dell Vostro 1700 I really liked) and gave it to my wife to use.  I now have access to ALL of my vital information on both of my computers.  I still have redundant backup and now I know it works!

I did miss a month of blogging and keeping up with the world though.  For that I’m sorry.  As of today I’m back on the bandwagon and I should start generating more blog entries fairly soon.

Until next time I’ll be Making Agile a Reality^® by continuously improving my IT infrastructure and the processes I use to support it.

Related posts:

1. Agile hip surgery? I’m always looking for uses of agile in areas outside of software...
2. Merry Christmas! This blog entry is being posted on Wednesday, December 23 at noon...

Why do some teams adopt an agile methodology and become wildly successful while other teams adopt agile and fail miserably? What is the difference?

In order for software development to be successful we must “build the right thing” and “build the thing right”. Agile strives for both but without understanding the goals and how agile aims to achieve them some teams misapply agile and end up getting little value from it.

Agile supports building the right thing by keeping the customer in the room with the development team all the time to answer questions and provide guidance. Some companies say that it is too expensive to give developers access to the customer but how expensive is it to keep developers waiting to get an answer or to end up building the wrong thing? I’d say it is a lot cheaper to have direct access to the customer.

Sometimes management feels that agility usurps their control because they cannot say they will be finished with X features by Y date. Of course, in waterfall you can say it but it often ends up not being true. Isn’t it better to have certainty around one of theses; features or date? For example, with agility you can guarantee that you will deliver working software by Y date but perhaps with a subset of X features. However, this subset will be the most important features to the customer and maybe ones the customer thinks of mid-stream; isn’t that better?

Of course, you can’t build inflexible software incrementally; you have to know how to write code that can easily change. Not following programming standards while building software iteratively will result in an un-maintainable mess. This is where I see a lot of organizations fail with agile and it is easily solved with some essential training for developers.

Agile projects can also fail because of culture. Some corporate cultures require everyone to commit to specific deliverables up front. This does not always work on an agile project. Some cultures see a lack of commitment to long term deliverables as being wishy-washy.

Agility is not just a buzzword. To truly be successful with agile takes understanding and internalizing the agile principles at all levels of an organization. It’s not about reading a book and following the “agile recipe”. Each organization must figure out how to make it work for them.

Building software is non-trivial. Each situation is different and whenever you find yourself in uncharted territory it is good to have a guide. This is why we agile coaches and trainers are in such demand. We have seen how organizations have successfully adopted agile and can help you apply that knowledge to your specific situation. This can make a big difference in how successful you are with agile.

I don’t believe in silver bullets for software development. Building software is very creative and I don’t think we can do it by just following a prescribed set of steps without thinking about what we are doing. And thank goodness. I don’t want to be in a field where I can go on automatic. I like the constant learning and challenge of discovering new ways of doing things.

I do, however, believe in and seek out things that help us be better at what we do. I think agility works because it creates a structure that encourages doing the right things more often.

For example, breaking down big problems into smaller problems is very useful for managing complexity and this is exactly what iterative development does. At the same time it also helps us group and build features in an organized way that makes integrating features easier.

We cannot successfully develop iteratively or employ continuous integration without following certain development practices and paying attention to code quality. Because we welcome customer feedback and changing requirements we must write code that is changeable. This forces us to establish engineering practices that promote higher quality software that can change.

Agility also addresses the cultural aspects of software development. Trusting the whole team to work together and do the right thing empowers us to collaborate more effectively. Favoring face-to-face conversations and working software over artifacts and ceremony keeps us focused on what we are there for in the first place—to create value for our customers. Supporting sustainable development and an environment that encourages improvement helps create teams that get better over time instead of burning out.

By following the few principles stated in the Agile Manifesto we are forced to adopt better engineering practices and a more effective development culture. I believe this is one of the main reasons that agility works for many organizations.

Agile methodologies seem to be taking root in recent years as more and more organizations realize that iterative development done correctly is a highly efficient way to build software. As I see agility gaining popularity I can’t help wondering what the next ten years will hold for agile development.

I just returned from Agile Open Northwest 2010 (http://www.agileopennorthwest.org) and I became very excited. The people there “get it” and are successfully applying agile in a range of environments. I am so wary of fads, which seem to abound in software development. The brief history of creating software is littered with methodologies, languages and tools that have gone nowhere.

Agile is certainly not a fad. The basic principles will probably be in integral part of software development for a very long time. But even in the fast changing world of software it takes time for good ideas to become part of the mainstream.

I talk with a lot of software developers and managers who have never even heard of agile. I also meet lots of teams who say they are doing agile but don’t understand it and are not using it in a way that would maximize the benefits for them. Agility is such a different way of thinking about building software that it is easy to misunderstand at first and the cultures of organizations can be so strong that agility becomes cooped into something far less effective.

I see the next ten years as a consolidation of many of the practices successful agile teams use today. I believe that many of the agile practices we embrace today will become common knowledge in software development in the future. Test driven development, for example, will become more widely practiced for new development and lots of legacy code will be retrofitted with tests. I am looking forward to the day that teams look at writing code without tests the way we look at writing code without compilers today. Sure, you could do it but it is so painful why would you want to?

This is a bright and exciting future but I also see some challenges with agile adoption. As with adopting anything, it takes people time to figure out what works and what doesn’t and to integrate what is new into the old way of doing things.

I was very excited about object oriented programming back in the late 1980’s. I thought it would revolutionize our industry and it did, to some degree, but far less than I had expected. I’ve met very few development teams that use the object oriented paradigm to its fullest. Most teams I see realize some of benefit of object oriented languages but miss using the best features of objects. I hope this will not true with agility but it is almost inevitable. However, this is just part of the adoption process. In 10 years I expect most development organizations will find ways to make agile work for them.

I think the main benefit of agility and object oriented programming is to shift the way we think about problems which, in turn, helps us shift the culture of how organizations approach problems. These things don’t happen overnight and real change does not happen without some struggle but it is also very exciting because we are figuring it out and improving over time.

The Agile Software Development Essentials class is coming back to Seattle on April 28-30, 2010. For more information, click here.

The Agile Software Development Essentials class is returning to Seattle on April 28-30, 2010. For more information, click here.