David Anderson - Writing Agile Software

Now That is a pretty frickin cool video -

Agile at Microsoft?  Sweet.

Sorry, is the Agile Management Blog link supposed to link to the blog? Seems to link to the video.

It's great to have scientific evidence to back up what I dislike about "traditional management." I simply cannot stand that "randomizing" question, when the manager walks in the cube and asks "What are you working on?" He---and I do mean he---should already know what I am working on! He needs to consult his metrics at his desk and then approach me more informed instead of with shock and awe. Of course the last sentence can be misinterpreted as an egocentric statement. Science to the rescue!

Good to see a Software Engineer in one of these videos, rather than the usual Computer Scientists!

I think many people do not understand what Software Engineering really is, and many developers adopt the title Software Engineer because it sounds cool. David is a true Software Engineer!

AWESOME VIDEO!!!!!!!!!!!!!!!!!

I could spend hours listening to Dave Anderson. He is great at speaking about software engineering.

He didn't mention SCRUM but I'd love to hear his thoughts on SCRUM's approach to Agile software at Microsoft.

Would he argue that there is a huge difference between SCRUM and function driven design?

Also, would he recommend SCRUM? If not, what would he say are SCRUM's weaknesses?

Thanks, Scoble!!!!

Excellent video.  I think my company read his book upside-down.

Excellent! I would definately like to hear more from David Anderson.

The URL has been fixed.Now it is good and fast.Is it like wallop?

Very good video. I am interested to hear his comments about other Agile methodologies such as Scrum or XP. I could relate to what he is saying to some of the common principles of these other methodologies.

How different or better what he is doing or practicing at MS from XP or Scrum?

Good video!

Excellent stuff. Before relocating to Redmond, I used many agile processes while working with large companies on their software development projects. Overall, I found these processes to be a big improvement over more traditional methods, and I'm glad to see that we're beginning to adopt them as a company.

Here are a couple of articles that relate to some Agile practices that we found to be very useful:

Automated Continuous Integration and the Ambient Orb™

Code Review and Complexity

David, Please visit me in the Philippines... I will introduce you to Post-IT notes.. and your walls will become more colorful...  

Also, how does this high-level manufacturing approach to software development translate into dynamaticity in design iterations? You touched briefly on how Corona will assist in dynamically translating the QA/Development project management path, but I'd like to see how:
 
A) We can rapidly identify through QA and customer feedback areas we can add value to a product (software) using a TeamSystem approach.. maybe things that are at the opposite end of the bottleneck spectrum?

B) Identify the scope of our development more readily. I may be developing the best virtual mapping siftware, but if I only have the U.S. mapped for the first few years, what's the point?... (Read This MapPoint Team

C) How can we integrate managerial tactics quickly with the Team System approach. For example, I might want to hype my developers with a video peek at Monad so they will start thinking about ways to do things with my software product better at a shell level or an IIS7 video so they can grasp integration of managed code at a modular level... How can these be employed quickly (and dynamically) using MSF and Corona as a true slab of concrete..

D) What happens when we clear the walls of a dev team member? Is there a way to recycle that paper?

Scobs..  Great video.. lets press David some more By the way, next time, how does David attach all that stuff to the walls.. is it Scotch, Glue, tacky putty, magnets.. come on..get in there..

I get asked this Scrum question often.

My general view of Scrum is that it is very positive. It is very easy to adopt. It has a low barrier to entry and it will give you instant improvement if you're in a chaotic situation.

However, I think Scrum does have it's limitations and it is also becoming a brand name and hyped beyond reality. It's more important to understand why elements of Scrum work. I strongly encourage daily scrum meetings and short iterations of 4 to 8 weeks. I like the idea of a single product backlog. I like the issue tracking and general project management aspects of scrum. However, it isn't the answer to everything.

FDD (Feature Driven Development) is very different from Scrum. FDD is a software engineering method rather than a project management method. FDD actually says stuff about how you analyze, design and code. Scrum doesn't!

What we are doing with MSF and with the adoption of Deming's quality assurance methods and Goldratt's constraints management methods, is really enhancing the literature and the knowledge in the field.

We have taken aspects of Scrum and XP that make good generic sense - unit testing, time-boxed iterations, daily meetings, single product backlog, and incorporated them in to our methods. We've then added conformance to process metrics and feedback and learning mechanism based on the use of cumulative flow diagrams and velocity graphs.

Also MSF is full life cycle and covers the full range of IT development activities. It isn't just for programmers or for the development stage of a project.

We are also trying to build user experience and usability engineering into it from the ground up. We see good user experience as critical to delivering value. It isn't an afterthought.

OK, I'm converted.

I went off and read 'The Goal', then 'It's not Luck' and 'Critical Chain'.  They put me on the right path to start tackling David's book.

Now I'm hooked.

I work in a very small company (5 devs) so I think I can get the chance to experiment with these techniques soon.

Loved the ROI equation:  ROI = (Unknown - Pretty hard to guess)/Didn't bother to measure. 

Herbie