Teams in organized sports experience scenarios not unlike those that a software development team see on a day-to-day basis: overcoming obstacles, working together as a team, training, strategizing, keeping score, resourcing, among others. As a highly-unskilled goaltender and defenceman, I have been able to experience both sides of this equation, and have been wondering what I can take from my recreational experiences to enhance my professional ones. What can the great hockey players of our time teach us about how to do our job?
I’ve been using TFS 2010 and 2012 as an ALM tool for the last year and a half, and this blog post summarizes my thoughts on the good parts of the platform perfectly!
I will note that I don’t think TFS is a “perfect tool”. Any tool has ways in which it can improve, and you can just look at the competitors in the ALM space to see where they are trying to differentiate themselves in order to see where TFS might fall short, or be missing some polish. However, I haven’t seen any other ALM tool that covers as many aspects of the application lifecycle. TFS may not be best-in-breed at any one task (bug reporting, source control, build management, etc.) but it can do it all in one product, which is what I like best about it. Having a “single truth” to what is happening, instead of having it spread across multiple disparate tools.
This year I was invited again to present at Microsoft TechDays. This event is held every year in the World Forum in The Hague. This year I spoke about why TFS is the perfect tool for Scrum.
My session was about how to use TFS as tool for Scrum. I talked about the different stages of Scrum, and what TFS can do in these stages. For example, Where to put the Sprint Goal, How to Split up PBI’s etc.
For all people who do not speak Dutch or who do not want to see slides or video alone this blog will be the answer. In the upcoming weeks, I will blog about this session. I will talk about how TFS can support the implementation of Scrum and…
View original post 1,647 more words
For all of my projects, there comes a point in time where we start winding down towards launch and the team begins watching the calendar very closely. This can be both a stressful and exciting time, but I feel that having a little bit of celebration around this is something that is worth doing.
For my current project, I decided I wanted to setup a countdown page that I could install on any computer and just launch and let it run. My acceptance criteria:
- Must display a countdown to the date of launch.
- Must be able to display the current live site.
- Must be able to display an example of the upcoming site.
- Must toggle between current live site and upcoming site views
- Must refresh view automatically so that when the live site changes it is displayed.
- Refresh rate must be configurable.
- Launch date must be configurable.
There are a few shops like Etsy that use continuous deployment/delivery to have code go straight into production, but otherwise the rest of us have some sort of environment between the developer’s machine and the live production environment. Some call this Staging or QA, or there may actually be MANY of these environments that a build needs to be promoted through before it is pushed to production. We’ve all seen this, we’ve all had to go through “deployment day”, and we’ve all hated it.
Whether you run agile/lean or waterfall, this idea of acceptance environments is the same. However, for some reason, these environments only seem to get updated at “critical milestones” on projects. In a waterfall pattern, this makes sense. You finish your work, you pass it to the next environment and let it continue its path. However, why do so many agile teams not push through these environments every iteration? Why are we pushing to acceptance environments so late in our projects?
Perhaps it is because we have embedded QA on our teams during the iteration and believe that everything is ready for production by the end of the iteration so we don’t need to worry about testing in all the various environments. We’ve already done our testing, so why do it again? Doesn’t that seem more like a waterfall testing approach? Absolutely not, and here’s why: