Comparing Waterfall and Agile Change

Chris provides a great real world example of how our methods of embracing change correlates to software development.

This is one of the best posts I have seen on understanding changes in software development. I see my self using this analogy in the future. Hopefully he does not mind. :)

When you use this analogy on your customers, be ready for the follow up question. "So how do we do GPS development?" The customer will need to see your confidence and understanding of Agile development before they buy into it.

http://feeds.feedburner.com/~r/ChrisSpagnuolosGeoscrum/~3/428653167/

Technical Managers

Here is an excellent post from Managing Software Development. The article does not distinguish between managing and leading but that is OK because the indirect point is you need to be good at both.

I wonder if the amount of time he had to manage the team impacted his management style while the PM was out on vacation. If he had more time, would he had done more.

Does this mean people manage to the amount of time they have available? More than likely, Yes.

Does this mean that some PMs or technical managers have too much time? No. I think their time is just used in wrong activities.

When leading a development team you have to look at each role and make sure they are focusing on the core duties of the role and remove obstacles from their paths. If your PM can't tell you your budget and forecast at any moment in the project, they are probably doing other things that are not as important.

http://www.noop.nl/2008/05/how-to-select-a-fine-technical-manager.html?cid=135566419#comments

Barry Boehm, "Defects found early in the development cycle are less expensive" does not apply today.

I heard this in a podcast and tracked down the session notes where it was said.

“why it had taken so long for the agile development methodologies to become known and accepted.”

Here were the responses from the panel:

Tom DeMarco responded quickly with the quip, “It’s all Barry ’s fault!” He went on to suggest that we had all been brainwashed by Barry Boehm ’s argument, first published in his Software Engineering Economics book, that the cost of repairing defects rises exponentially the later they’re found in the software life cycle (for a more recent exposition of this point, see the December 19, 2005 Dr. Dobb’s article by Yochi Slonim , “The Software Quality Lifecycle “). He said that as a result, the commandment “get the requirements right!” was drummed into the heads of a generation of software engineers. Tom turned towards Barry , smiled, wagged his finger, and said, “And I have never forgiven you!”

Barry Boehm relieved the tension in the air by agreeing with Tom . He explained that, back in the 1970s, he had linked up with Win Royce at TRW, where the two of them found that the waterfall methodology worked pretty well. But he acknowledged that they were working in an application domain (aerospace systems, military systems), and in a time, when the end-user’s requirements were fairly well-defined; consequently, it made a great deal of sense to capture those requirements early, rather than discovering later on that a great deal of software had been built to implement the wrong requirements. But Boehm acknowledged that by the 1980s, things had begun to change drastically … and obviously this continues to be true today.

http://www.yourdonreport.com/index.php/2007/05/29/icse-peopleware-panel-session/

http://www.google.com/search?hl=en&rls=com.microsoft%3A*&q=tom+demarco+said+it+is+Barry%27s+fault

Branching Should be a Planned Activity

Most teams do not consider branch code until it is too late. Many projects forget about branching because they never plan or plan for branching code. If you delivery process is unstable, it is impossible to plan your branching. At times this will cost your customers money in source control merging, developer down time, defects and setting up complicated branches.

Branching code should be discussed during iteration planning and be an estimated task or story to be completed at the end of an iteration before releasing or as a release activity. Keep in mind the impact of the next iteration’s or release’s development.

This is a good article about Branching Strategies.

http://labs.seapine.com/wiki/index.php/Surround_SCM_Branching_Strategies#Branch_By_Purpose

Book Review - Agile Estimating and Planning

This is a very good book and good read. (I like books that are informative but also keep me entertained ) This book has a lot of great ideas and examples of for an Agile team. If you are new to Agile and want some guidance, start here. If you have been doing Agile, this book will give you new ideas.

I have incorporated some of the reporting and planning practices into my teams already.

The case study at the end is a good to show teams other ways of delivering software. Some people have only worked on one project or at one company and are unaware of other ways of doing software development. Here is a book review too. The book got good reviews so I recommend reading this after reading the book.
http://niwotridge.com/BookReviews/AgileEstimatingandPlanning.pdf

Here is a related video too.
http://www.informit.com/podcasts/episode.aspx?e=F91D5770-B567-494B-8D68-E8053036625C

You can find the authors blog in the blog list.