Agile Development Myth

Another presentation on agile process, another set of misconceptions.  The agile process is not just for software development, although it works very well there.  You could plan a birthday party using agile development.  The agile process is a project management tool, not just a software development tool.  When we hear that agile development is just for software development, we need to look deeper.  Agile development focuses on the delivery of specific products in a 3-6 week period.  Software is a specific product.  Many times the system life cycle is so full of huge work products in the form of documents that no wonder someone thinks that it's just good for software.  If a system design is a huge document, then of course we can't come up with a copy in less than 6 weeks.  But if we see the work product a server design, a network design, etc, then these can become chunks that can be delivered in that timeframe.  Identifying the chunk of work is hard, but the reward in productivity can be worth it.

Another problem is that classic waterfall processes created a lot of work that wasn't really used.  Agile came along and said, 'lets focus on just what we need'.  So agile projects start popping up.  The folks who define the waterfall processes then say that they need to add stuff to the agile process - basically bogging down the agile process with everything that made the waterfall process ineffective.  Ugh.  But we do need to be careful: there are things that agile projects have overlooked in the name of getting systems out quickly that make the operations and maintenance of the system difficult.  So we can't just throw out the waterfall process.

Twitter and $25B

All I can say is: you've got to be kidding.  I like twitter.  I love twitter.  Twitter does some things very, very well.  But $25??  It's not a cure for cancer, doesn't reduce poverty, provide healthcare to poor, etc.  I think we're looking at another dot com bubble?

Assumptions

Anyone ever get mad at you because they had an assumption that they didn't communicate with you?  This is a problem in personal life as well as professional.  Never goes over very well.  This is why the use of Log Frames in projects can be very useful.  What are the assumptions that get us from the project inputs to the outputs?  What are those things outside your control that could impact your delivery?  Also, when creating a project schedule in MS Project, add assumptions to the Notes section of a task.  Always be aware of what your assumptions may be.  The odd thing is that when we have assumptions about someone else, we think that they're obvious - 'hey, don't you think it's reasonable...', 'isn't it obvious that you should have...'.  Funny how that works...