How People Work At Google

Aside

Forbes.com has an interesting article describing the environment over at Google.

From the article: “Hundreds of projects go on at the same time. Most teams throw out new software in six weeks or less and look at how users respond hours later. With 82 million visitors and 2.3 billion searches in a month, Google can try a new user interface or some other wrinkle on just 0.1% of its users and get massive feedback, letting it decide a project’s fate in weeks”. Now thats agile!

Coté : Make the Iteration Fit the Deliverable, and Other Thoughts on Becoming Agile

Coté from the DrunkandRetired podcast has written a very good article called Make the Iteration Fit the Deliverable, and Other Thoughts on Becoming Agile.

Key points I took away are:

  • Agile development doesn’t mean planning less; as a matter of fact, it takes more planning
  • Planning should happen as part of the team not apart from it.
  • There is no fixed iteration size. You should plan your iteration size based on what you are doing.
  • Two week iterations require a pipeline of planning in order to work effectively. This pipline is normally not present unless your organization has reached a level of maturity
  • Agile development doesn’t mean throwing away design

In my mind, one of the misconceptions that people have when switching to any methodology is that there are a set of rules and procedures you must follow in order to be “doing the methodology”. I don’t think this is the case. The great thing about agile development is being able to adapt to the situation rather than be “stuck” having to follow a set of steps no matter what.

When I think about this idea, the quote from Bruce Lee about Jeet-Kune-Do, his martial art, always comes to mind:

Absorb what is useful, reject what is useless, and add what is specifically your own.

Bruce Lee was annoyed with traditional martial arts because it had “too much form”. The martial artist was unable to adapt to the unexpected. Rather he was limited by the forms he used while learning. (Before any martial artists start posting comments – this was Bruce Lee’s philosophy – not mine). Lee thought that the martial artist, given a set of tools, should be able to react naturally rather than having to think before responding.

I view development “methodologies” in the same way.

Things are going to happen. We have to be able to respond to them in order to be effective, and not get caught up in “how” we get things done. This to me is the power of the “philosophy” of agile development. It has nothing to do with iteration size or any of the other “guidelines” in the methodology.

Shorter iterations, however, do not mean that we do not design or plan during the process. It doesn’t mean working randomly. It means that we should do what is necessary in order to plan, design, and execute – no more and no less.

I think it would be more useful to explain Agile development as a philosophy in this way rather than a set of “methodologies”. People get caught up in “doing the methodology” rather than executing what they have set out to do. I have seen this time and time again as people try to change the way they do things. Agile development methodologies provide a set of tools, like TDD and the idea of iterations. Its up to you and the needs of the project to decide which tools are appropriate to get the work done.

Anyway, I digress. Coté has obviously set off a whole train of thought in my head this morning with this article. Perhaps it will do the same for you.

Ken Schwaber and Scott Ambler on ITConversations

I found two excellent lectures on IT Conversations that I would like to recommend to people looking at how to learn (or justify) agile development methods. The first lecture was given by Ken Schwaber, the creator of the Scrum project management methodology, called You Thought it was Easy: Wrestling Gold from Today’s Software Projects. In this 40 minute discussion, Ken explains what Scrum is and how it works. Its a very informative lecture that has helped a lot in giving me additional ways to try to explain the advantages of Scrum as a project management methodology.

One of the interesting points that Ken brings up is that when you introduce an empirical model like Scrum, all of the things that have been wrong in your environment for such a long time come to the surface and have to be dealt with. We have definitely seen this in our environment and it has caused some discomfort on the team. For me, its very nice to have a lecture like this that I can refer team members to that explains that this is a normal part of the process. It is, however, extremely difficult to explain to some that the problems we are seeing have been around for quite a long time, but that we have been unable to quantify them until implementing Scrum.

The second lecture was given by Scott Ambler and is called Are you Agile or are you Fragile in which Scott tries to explain the advantages of Agile methods and answer some of the arguments one would get in justifying using Agile methods on actual projects. There are a couple of interesting things about this lecture. First, he runs it as an agile project, eliciting “requirements” or topics from the audience and having them prioritize them. Secondly is the passion in which Scott talks about Agile methods and his no nonsense way of explaining the advantages.

This lecture gave me a great quote that stuck with me. “A new requirement is a competitive advantage – if I can act on it”. I found this to be a brilliant reframe of the common objection to changing requirements that happens on teams which have been “raised” on the waterfall type of approach where requirements are finalized and cannot change without having been “wrong” in the first place. This lecture is a long one, weighing in at one hour and 55 minutes.

For those teams out there that are attempting to implement agile methods in an environment that has been historically waterfall and “predictive planning” based, these two lectures are definitely something you should check out.

The Drunk and Retired Podcast

Ed Gibbs, who runs the Musings of a Software Development Manager blog, recommended a podcast called Drunk and Retired, put on by two 10 year veterans of software development, Charles and Cote.

I’ve downloaded a few of the podcasts and spent this morning listening to the first two episodes, The Life Agile Parts One and Two. The podcast is pretty interesting. Charles spent some time over at ThoughtWorks and the first two episodes focus primarily on Agile Programming practices, including Test Driven Development, Scripting Languages, and XP and Scrum.

It’s kind of nice to find a podcast in which two regular guys who seem to know what they are talking about sit down over a couple of drinks, tell war stories and give opinions on different software development concepts and methodologies. I’m finding the podcast, so far, to be really interesting.

I’m currently listening to episode eight, which is titled “Learning From Open Source” in which Cote and Charles discuss the effect that Open Source software processes could have on commercial software development, a subject that I have been interested in for the last few years. This is one that I may create a follow up post about to summarize the points, as right now there seems to be a lot of interesting points here.

Check it out if you have some time to kill during your commute.

Agile and Iterative Development: A Manager’s Guide by Craig Larman

Agile and Iterative Development: A Manager's GuideI just finished reading Agile and Iterative Development: A Manager’s Guide by Craig Larson. I am extremely impressed with the amount of meat in the book on Agile methods and how succinctly this information is expressed.

Normally when you look for books on these kinds of subjects for managers, you find a lot of fluff and no real information. Not true with this one. The book starts out with a chapter talking about how software development over the years has been treated much like a factory production line, where everything can be predictably planned, rather than being treated as it should be — as new product development. New product development differs in that you are creating something brand new and do not quite have all the answers yet, so you plan differently than you do making a widget. The process isn’t predictable, because it hasn’t been done before. Now, this is a no brainer to anyone who has actually played a design or development role on a project, but it is traditionally very hard to explain why you can’t quite tell someone how long a feature will take to code because we haven’t done it before. The first chapter of the book covers this subject very well.

Chapter 2 explains a lot of detail on what iterative and evolutionary development are, in ways that a manager can udnerstand it and see the financial benefits (and the people benefits if he is looking for it!). It talks about the evolutionary requirements gathering, evolutionary and adaptive planning, and gives an overview of the few agile methods explained in the book.

Chapter 2 ends with Craigs opinion of what the most common mistake is in application of agile methods to software development, which is one I’m sure we’ve all seen. Changing the names of the waterfall approach to your favorite “agile” name and doing the same thing we’ve always done, with a full blown project plan that details each iteration and everything. . He talks briefly about it here but covers it quite a bit later in the book. If you have tried to implement the UP in organizations before this will bring a smile to your face, as you will have seen Inception turn into requirements gathering, elaboration turn into design, construction turn into, well, constructions (development), and transition turn into deployment to a production environment. Its something most people who try to implement agile methodologies have seen at least once in an organization.

Chapter 3 explains the values built into most agile processes and gives an overview of the methods he will be covering through the rest of the book. The methods covered include:

  • Scrum
  • Extreme Programming
  • The Unified Process
  • Evo

Chapters 4, 5 and 6 cover the motivations and evidence for why agile methods exist and why they work better than the traditional waterfall method. Some of the most interesting things in these chapters are the references to government standards that originally started out supporting the waterfall method that later were revised to agile type methods. There is also some history in this section on the waterfall method and it’s “accidental” endorsement as the “right way to do things”. The interesting part about this one is that the definitive paper that describes the waterfall method was actually written to describe an iterative method that had only one iteration. From one misphrasing, the whole software development industry was thrown on it’s ear for decades!

The evidence chapter is also quite interesting, using project failures as the main driving measurement for why agile methods work and predictive methods do not. The chapter goes into a lot of detail here from a measurement perspective and when you are done reading it you never want to plan a 15 month project in detail in the first two weeks again.

Chapters 7-10 cover, in detail, the four agile methods listed above. These chapters are really good explanations of each method, the values that each methods hold, how they mesh with other methods, and the history of their development. These chapters are really interesting reading. For each method, the author goes through value differences with other methods and how each method may clash or be merged with others.

Finally, we get to Chapter 11, Practice Tips. The book goes through some implementation tips in the area of Project Management, Environment, Requirements Gathering, and Testing. The chapter takes common misconceptions and tries to give advice as to how to deael with them.

This book is an invaluable resource for those who need to explain why a move to an agile method of development is needed in an organization. The Evidence chapter in and of itself is worth the price of the book. The added benefit of having the definitions and practices of the individual methods in one book is also great. I highly recommend grabbing this book if you are trying to move your organization to agile development.

Along with being a great resource for helping you explain your position, there are things that are just funny. A lot of us have dealt with many of the arguments outlined in this book, and I know that I have thought that some of the conversations I’ve had could never happen anywhere else. It’s really affirming to know that they do and that the conversations you have about agile development are the same ones had all over the development world. The same goofy mistakes are made and the same misconceptions about what the process should or shouldn’t be are common across this industry.

If you get nothing else out of the book, you will get a sense of comfort knowing that you are not alone. All of the problems you are experiencing right now explaining why agile development is valid, and all of the problems you are having in the way it is applied happens everywhere.

Now you have a reference to help with those conversations that put it in terms even your manager can understand.