-
-
David Anderson talks about Agile Estimating. I agree with all of this 100%. However, how do you estimate a guess to begin with? What exactly are we estimating? My experience has shown that we do a poor job estimating from the start (techniques that David describes in his book and in his blog will help this make us do a better job) – however, what I’ve found is that we do an even worse job discovering, specifying and validating the requirements for which we place our estimates. It’s like building a building on quicksand. Yes, yes, yes – agile (I don’t use the term as a noun) techniques allow for changing requirements as you go through your lifecycle, however we still do a poor job with even our root requirements.
Then there are issues around traceability and change control. What happens when a requirement changes? How does it affect what we’ve done? Here is where Team System is going to play a role. We need absolute transparency on our projects. And to gain transparency, we need a foundation of traceability, clear accountability, and control.
There are many ways we can fix this problem; however, I won’t get into them today. I would recommend that you all go and read David’s book “Agile Management for Software Engineering”. Later, I’ll spend a bit more time equating how Team System will specifically address the common constraints in Software Engineering (again, all in David’s book).
-
-
I haven’t been blogging much lately, my apologies. I’ve been crazy busy. With what? Team System of course. It seems that I’ve been doing nothing but for ages. First off, I’ve been helping to deliver Ascend training in the UK, Amsterdam, and this week Redmond on the Microsoft Campus. I'm heading off to Hong Kong in a couple of weeks as well - then back to the UK for some very specialized SDLC Process Adoption consulting along with more Team System workshops (a week long set of workshops that I've put together that focuses on making the product do what we need to do in our environments).
This is extremely rewarding in many ways. First, Ascend training is typically the first time many customers have seen Team System. In general I get mixed responses with regards to the toolset. Some rejoice in the fact they will have tools to work with that are integrated with the rest of their development environment. Others, those organizations who already have an investment in other sets of tools over the years are skeptical. One thing is for sure in every case - when people realize that Team System is just as much a platform for tool integration as it is a set of tools they all realize the importance the product will have on our development processes – no question.
So, Team System is a bunch of new tools for the entire team – and it’s also a power platform for the integration of other tools. It’s also extremely extensible. I’m doing a huge amount of work on the extensibility aspects of the product for one reason – effective Team System adoption.
Adoption of Team System will not be a trivial exercise and should be coupled with a holistic approach to process and team improvements. I’ve been working on a very comprehensive set of adoption strategies for different types of companies (ISV’s, Governments, Large Orgs, etc) that will address end to end adoption into an organization in a way that provides the most value for the particular organization. I like to compare Team System to a PDA – does a PDA make you more organized or do organized people use PDA’s. Probably a little of both.
Anyway, I promise more to come on a regular basis on Team System.