Please believe that I am not a stalker - but I am addicted to getting my Xobni information all set up. And I know I am not alone out there that when I get a new email and see the generic no-picture graphic show up in the right-hand corner of my Outlook inbox it begs me to put something more interesting in its spot.
So if you catch me snapping your picture next time I walk by you, or searching through Google images for a likeness of you, please don't worry. It isn't that I have an unhealthy attachment to you personally - it is that I cannot stop until Xobni is fully populated. And if you do have a picture out there on the internet somewhere - I will find it.
Wednesday, January 30, 2008
Monday, January 28, 2008
Stabilization with Agile Development
One of the hardest things for our sales team, our project managers, our development team, and our customers to agree upon in agile development is what constitutes an acceptable stabilization period.
Let me expand. I have been in software consulting for almost 10 years now, and the hardest part of any project is gaining final customer acceptance that the project is "done." With custom software, there always seems to be another bug to fix. The customer is afraid of giving up their rights to have the undiscovered bugs fixed if they sign off too soon.
With agile development, the idea we have implemented is that there is a set amount of time after new development for the team to focus on changes or fixes from any prior iteration. We set aside one iteration for software stabilization. We set this expectation with our customers up front, and they agree.
When it comes time for the stabilization period, however, it seems that as new development tasks from prior iterations take more time than anticipated the new development tasks bleed into our stabilization. While agile touts that our customers should be able to prioritize all outstanding work - be they new development tasks or bug resolution - based on their needs, it seems that the customer always chooses to add the new development tasks and never choose bug resolution. Then, when stabilization is over and there is a list of bug fixes, the argument comes up that we did not deliver a quality product.
While I understand that this problem is all about setting the appropriate customer expectations and about working with the customer to convince them that new development tasks should not be planned in the stabilization phase, it seems that we repeatedly get ourselves into this same situation. I love the agile approach. I love the idea of working closely with our customers, and getting immediate and real feedback as we deliver working software on a regularly scheduled basis. I also think it makes sense to weigh the tough decisions with the client sponsors in order to prioritize remaing new development tasks against the agreed upon schedule - excluding the stabilization period.
However, just like I found with the waterfall process, as soon as the schedules start to slip or estimates go over, the first thing to get the ax is testing. In this case, stabilization gets the ax. And when that happens, how can we confidently deliver quality to our customer and agree that at least the first phase of the project is in fact "done?"
Let me expand. I have been in software consulting for almost 10 years now, and the hardest part of any project is gaining final customer acceptance that the project is "done." With custom software, there always seems to be another bug to fix. The customer is afraid of giving up their rights to have the undiscovered bugs fixed if they sign off too soon.
With agile development, the idea we have implemented is that there is a set amount of time after new development for the team to focus on changes or fixes from any prior iteration. We set aside one iteration for software stabilization. We set this expectation with our customers up front, and they agree.
When it comes time for the stabilization period, however, it seems that as new development tasks from prior iterations take more time than anticipated the new development tasks bleed into our stabilization. While agile touts that our customers should be able to prioritize all outstanding work - be they new development tasks or bug resolution - based on their needs, it seems that the customer always chooses to add the new development tasks and never choose bug resolution. Then, when stabilization is over and there is a list of bug fixes, the argument comes up that we did not deliver a quality product.
While I understand that this problem is all about setting the appropriate customer expectations and about working with the customer to convince them that new development tasks should not be planned in the stabilization phase, it seems that we repeatedly get ourselves into this same situation. I love the agile approach. I love the idea of working closely with our customers, and getting immediate and real feedback as we deliver working software on a regularly scheduled basis. I also think it makes sense to weigh the tough decisions with the client sponsors in order to prioritize remaing new development tasks against the agreed upon schedule - excluding the stabilization period.
However, just like I found with the waterfall process, as soon as the schedules start to slip or estimates go over, the first thing to get the ax is testing. In this case, stabilization gets the ax. And when that happens, how can we confidently deliver quality to our customer and agree that at least the first phase of the project is in fact "done?"
Thursday, January 24, 2008
Xobni is Cool
Okay - I have been getting requests to write again. The problem is, most of what I would post about is no longer directly related to C# or development tasks. I focus on IT strategy now.
However, I do have something cool to post about. One of our infrastructure consultants noticed me digging around in Outlook yesterday looking for a response to an email. He excitedly ran back to his desk so he could send me a link to a beta-release of an Outlook add-in called Xobni (or Inbox backwards).
This add-in is super cool. When I click on an email in my inbox, I now have a left-hand pane that shows me a picture of the person who emailed me (I uploaded these) along with an extrapolation of the person's contact information, a rating assigned to that person depending on how much we email back and forth, stats on what time of day I am most likely to receive an email from this person, a list of related contacts with links to their info, recent conversation strings (showing what I said, the response, what I said back, etc), and recent file attachements sent to me.
So far, I am a huge fan. Although when I ran the Xobni stats it did make me wonder what the heck I was doing in August to spike my average response time to emails to an all-time high of 35 minutes. I guess I was quite the slacker that month - oh wait...that is when I was on vacation :)
However, I do have something cool to post about. One of our infrastructure consultants noticed me digging around in Outlook yesterday looking for a response to an email. He excitedly ran back to his desk so he could send me a link to a beta-release of an Outlook add-in called Xobni (or Inbox backwards).
This add-in is super cool. When I click on an email in my inbox, I now have a left-hand pane that shows me a picture of the person who emailed me (I uploaded these) along with an extrapolation of the person's contact information, a rating assigned to that person depending on how much we email back and forth, stats on what time of day I am most likely to receive an email from this person, a list of related contacts with links to their info, recent conversation strings (showing what I said, the response, what I said back, etc), and recent file attachements sent to me.
So far, I am a huge fan. Although when I ran the Xobni stats it did make me wonder what the heck I was doing in August to spike my average response time to emails to an all-time high of 35 minutes. I guess I was quite the slacker that month - oh wait...that is when I was on vacation :)
Friday, August 11, 2006
humanstuff...
I am sitting at my kitchen table, wrapping up some work before I close up shop for the weekend, and I hear some rustling outside in the garden. I look out the window, and I see two strapping men sneaking around with laptops and they are stealing my wireless!!! What do I do about this? I decide to bring them some chairs and offer up a few beers, but they must pay me rent for my wireless - a trick off the diving board each.
Check out John Howes and Dan Mork's new blog and company site. They call themselves humanstuff, and that they are. They are driving around town, so lock up your wireless access and keep an eye out - but if you do see them, at least offer them a beer. I am not exactly sure what their company will sell, but they have already provided me with inspiration to bust out my keyboard and blog again :)
Good luck, Dan and John. Don't forget about us little guys when you go international and are stealing wireless in places like Bora Bora and Cairo.
Check out John Howes and Dan Mork's new blog and company site. They call themselves humanstuff, and that they are. They are driving around town, so lock up your wireless access and keep an eye out - but if you do see them, at least offer them a beer. I am not exactly sure what their company will sell, but they have already provided me with inspiration to bust out my keyboard and blog again :)
Good luck, Dan and John. Don't forget about us little guys when you go international and are stealing wireless in places like Bora Bora and Cairo.
Monday, May 01, 2006
Gemini Version 2.0
A while ago, I downloaded a free version of Gemini. Gemini is an issue tracking tool by Countersoft. I have been using Gemini locally for over a year, and I really dig it. In order to use Gemini in conjunction with a project team, you need to put it on an external facing web server, which requires a license. I had not used the tool in this capacity due to my company's use of SharePoint. However, as our project is in it's second year and our issue list was approaching 300 items (including all tasks, enhancements, and bugs), SharePoint just wasn't giving me the reporting options I needed to communicate our enhancement actual versus estimated time to my project sponsor. Finally, I decided to make the switch to a licensed version of Gemini. It was a bit of a pain to convert old Gemini issues over the the new version. I had to turn off some constraints in the database as the SQL schema between version 1.0 and 2.0 changed. The time investment was well worth it, though. Now I can quickly report on the changes made with each new release by using Gemini's Road Map and I have the ability to use SRS to report on time.
I couldn't receommend Gemini high enough. I do wonder how Team Systems may replace my need to use Gemini in upcoming projects, however. Have any of you used Team Systems in conjunction with web parts or web services for giving your clients a view into project status and issues, and allowing your project sponsors the ability to upload new issues or tasks?
I couldn't receommend Gemini high enough. I do wonder how Team Systems may replace my need to use Gemini in upcoming projects, however. Have any of you used Team Systems in conjunction with web parts or web services for giving your clients a view into project status and issues, and allowing your project sponsors the ability to upload new issues or tasks?
Monday, April 24, 2006
The Coolest .Net User Group Around
I was very impressed with the WI .Net User Group and the event they hosted on Saturday. Besides being my first trip to Milwaukee, this was also my first time hearing each of the speakers present. I have been to many events, but this event is by far the best I have attended.
The biggest highlight for me on the speaker side was Scott Hanselman. Scott presented about the general coolness of open source software, and how we should all aspire to have great solutions rather than “accidental” code. In this context, Scott visited the subject of dasBlog. I have to admit that at the beginning of his presentation, I couldn’t care less about dasBlog, and by the end of his presentation I was formulating my data migration plan. He had me laughing and enjoying the command prompt – who would have thought?
Besides the slew of entertaining and informative out-of-town speakers, the guys running the whole show were friendly, welcoming, and a fun group of people. I was surprisingly invited to a pre-event party and an after-event dinner. I was showered with cool new software – including Office 2003 Professional and Resharper. The WI .Net User Group networks like crazy, and I got to meet a new set of technical peers who now feel like friends. I even considered throwing caution to the wind and staying an extra night in the city by the water, just so I wouldn’t have to miss out on a second of fun.
So now the challenge – how can the Minneapolis .Net user group top Milwaukee? ;)
The biggest highlight for me on the speaker side was Scott Hanselman. Scott presented about the general coolness of open source software, and how we should all aspire to have great solutions rather than “accidental” code. In this context, Scott visited the subject of dasBlog. I have to admit that at the beginning of his presentation, I couldn’t care less about dasBlog, and by the end of his presentation I was formulating my data migration plan. He had me laughing and enjoying the command prompt – who would have thought?
Besides the slew of entertaining and informative out-of-town speakers, the guys running the whole show were friendly, welcoming, and a fun group of people. I was surprisingly invited to a pre-event party and an after-event dinner. I was showered with cool new software – including Office 2003 Professional and Resharper. The WI .Net User Group networks like crazy, and I got to meet a new set of technical peers who now feel like friends. I even considered throwing caution to the wind and staying an extra night in the city by the water, just so I wouldn’t have to miss out on a second of fun.
So now the challenge – how can the Minneapolis .Net user group top Milwaukee? ;)
Thursday, April 20, 2006
Road Trip :)
The snow has all melted - the birds are singing - what better time for a Road Trip?
A good friend, and past colleage of mine, Avonelle, suggested we hit the road for the Wisconsin Deeper into .Net event this coming Saturday.
I have never been to Milwaukee, and am especially looking forward to Julia Lerman and Scott Hanselman speak.
Who knows - with two girls in Milwaukee for the FIRST TIME, we might have to go LaVerne and Shirley on the city and hop on a brewery tour :) This is my prediction of what we will look like in two days time.
A good friend, and past colleage of mine, Avonelle, suggested we hit the road for the Wisconsin Deeper into .Net event this coming Saturday.
I have never been to Milwaukee, and am especially looking forward to Julia Lerman and Scott Hanselman speak.
Who knows - with two girls in Milwaukee for the FIRST TIME, we might have to go LaVerne and Shirley on the city and hop on a brewery tour :) This is my prediction of what we will look like in two days time.
Subscribe to:
Posts (Atom)