Corporate Coder

I've been wanting to write this since giving a talk last week at the Indianapolis TFS user group.  Paul Hacker started this group and leads the sessions.  Props to Paul for having a great group of people.  Currently they meet after the Indy .Net Users group.  I thought it was a great interactive talk.  We'll see what the folks in Indy thought!  During the meeting I got the chance to meet Eric Wilke another developer (software architect actually) who is utilizing a kanban system.  During the talk and after we had a lot of discussion about making the kanban better. 

I've mentioned this in a thread on the kanban yahoo group.  To summarize, this is what I think is the way to limit the kanban in a situation where your team supports multiple applications.  Here is how I think the requests would work.  Application 1 has 14 change requests in a parking lot somewhere. We currently budget 3 requests in the Kanban for that application. Next application 2 usually has 10 requests in the parking lot. We usually budget 2 requests in the Kanban. But for some
reason, this week they have 1 request in the parking lot. Based on a rule, we now allow application 1 to increase their budget to 4. The following week, when application 2 has 4 requests in their parking lot, their budget goes back to 2 and application 1 goes back to 3.

That's the theory, I'll get back to how this works.  I'd love to hear others experiences with this.

There is a new version 0.3 release of the Kanban template for TFS on codeplex.  This new release took a lot longer than I anticipated.  It does include some new process templates.  Also, 2 new reports are included (Cycle Time and Flow).  These should begin to help.  Also, I hope to test this with the Sticky Buddy project on codeplex.  I hope these are complementary.  I would love to hear requests for reports in this template.  No guarantee on when I get back to this, but I will be working on it.

On June 12th I will be in Indianapolis, IN giving a talk on TFS and Kanban to the TFS SIG there.  Check out this link for information on where and when.

It's been a while.  I wanted to give some more insight on how we are proceeding putting constraints in our parking lot.  For some change management processes, your customers might be able to submit as many change tickets as they want.  In most scenarios, at least some of those change tickets should never be done, they are waste.  As mentioned in previous blogs, we are now limiting our change tickets. 

Our customers accepted this limitation without a lot of pushback.  I believe the way we implemented it explains the lack of resistance.  There are stakeholder meetings weekly.  Each week, the stakeholders can select new "stories" or changes.  This is based on points.  Once we complete a story, that frees up points.  But our Kanban can only hold a certain amount of points.  Based on that point system, the customers prioritize the stories. 

In this manner, the waste should flow to the bottom, or never be done.  I'd say the key to getting customer buy-in is to have scheduled communication, and updates.

I want to announce that I have posted an alpha version of the Kanban Process Template for TFS on codeplex.  The template as currently has a set of Areas and Iterations to help get started with Kanban.  This Process template is based off the MSF Agile template.  There is now a score field, that has points based off the fibonacci sequence.  I plan to add reports and more process guidance to this.  I'd love to get feedback on what else is needed for this template.  I assume that you know how to add new Process templates to Team Foundation Server.  This template has been tested with TFS 2008. 

I wanted to write an update about our change management system.  Now that we have a kanaban system driving our change process we are ready to limit certain parts of our current Kanban.  See this post for my earlier thoughts on what we would do.  That post was speculation on what we should implement.  We just decided to place limits on our parking lot.  For our customers this may be painful, but I believe our reasons for imposing this will benefit the business.

First our applications can only have a certain number of change tickets in our change ticket backlog (or parking lot).  So application A can only submit 5 tickets into the Kanban.  Once all 5 have gone through the Kanban board to completion, then the Product owners of Application A can submit 5 more tickets.

Since our system is FIFO, this helps us solve the problem of having customers prioritize their changes.  I think these limits will help us highlight constraints, and I hope that frivolous changes will drop off an not ever reach us.  One of the things I think we all need to keep in mind is that we will always be tweaking this process.   The goal is to be hyperproductive!

Hey folks. A quick technical post for anyone starting to implement Project 2007 Server from 2003.  Your enterprise global cannot be easily moved between environments.  This mainly means any VBA that you may have as carryover from 2003.  I'm assuming that if you utilize VSTO to code your Client tasks with Project objects, you don't have this problem.  But I see this as an issue that could be a lot easier.  I used to be able to get Project global from a development, to a testing to a production environment using backups.  Now I have to Import VBA files to the global.  And then I have to recreate views, tables and filters manually.  I'd like to see a better way to accomplish this.

Looking at the web service factory more I see some possible value.  I had problems installing the version with source,  but it turns out that it was my directory structure.  I initially used My Documents to store the project and the documentation does mention that you might get this error.  Apparently my brain was thinking this only happened to the other guy, until I finally tried in a smaller tree (c:\dev). 

Now that I've got that figured out, I'm actually following the 15 minute walkthrough on codeplex.  I believe that this process can aid agile development by creating standard structures for your projects etc.  It's an interesting demonstration of the guidance package technology. 

I do question how agile this is.  For some reason I believe we can utilize this for an agile project, but some the service factory model smacks of the architect creating the design from on high, and don't let the developers below don't muck with it.   Even if that becomes my final verdict on the service factory, I think you can create lighter guidance packages that can help do some of the more mundane work for your projects.  I'll continue to post on this new way of architecting, and guiding developers.

Just released earlier in February, is the Web Service Software Factory: Modeling Edition for 2008.  This new software factory utilizes the Guidance Automation toolkit in the source code.  An intial look seems to me that it's a bit heavy for an agile process, but that's just my initial reaction.  I want to see if software factories can be included in an agile process, so I need to do a deeper dive.  I'd love to hear what others think.

Quick heads up on a great new tool for teams on the patterns and practices msdn site.  The Guidance Automation Extensions and Guidance Automation Toolkit Feb 2008 release is now out.  This tool looks like that it might be a great addition to aid enterprise development groups in emphasizing coding standards. 

Call me crazy, but I see a use for guidance for something like custom sharepoint applications.  For instance, documentation on our standard event handler code, along with sample classes.  I'm not sure if this is possible with this tool, but I'll be investigating.  I'd love to hear if anyone else is using this tool, for this purpose.

Interesting post over on the Lean Software Engineering blog, "There are no a priori best practices".  In a couple of sentences Corey lays out what I think being Lean is about.  What I get out of the 2 sentences are that you must ALWAYS improve.  You may be the best but that doesn't mean your software practices are the best.  In 2 years there will be a better way to do things.   Keep these things in mind as you adopt new practices, and don't be afraid to experiment.

On MSDN, there are a series of articles to help explain how to use VSTS and TFS within a large organization.  Called Global Bank: A Scenario for Visual Studio Team System 2008.  This article has an excellent introduction to the possibilities of how VSTS and TFS can assist with your software development life cycle. 

There is a lot I love about VSTS and TFS to help in managing development.  And there is some room for improvement.  The article shows how a company utilize all aspects of VSTS.  For instance there's a good introductory scenario using the architecture tool.  I'm not sold on this tool for various reasons, but if you haven't tried it out, there's a good example of how to use the tool.  What sets this apart is the interconnections between the different tools. 

Another problem I have with the presentation of this is that it follows a more waterfall method.  So I'm thinking an agile scenario might be a good story to create.  Hey that might be a great idea that I might write!  But if you don't have a mature software organization, this series could help you visualize how to grow that organization.

Since I use virtual images of TFS for some of the things I'm doing, thought I'd let you know that these virtual machines are available now on MSDN. The nice about these images is the preinstallation of Visual Studio Team System, and Team Foundation Server.  I'd also wish for preinstall of at least the BI studio stuff for SQL Server 2008, but having the other parts already installed is great. 

Hey, these images are trials.  But if you have an MSDN subscription or buy a valid version of this stuff, there are instructions for upgrading these images from trials to full versions.  Without unistalling a reinstalling, which should be helpful.  For some of the articles etc. that I write, these is extremely helpful, and saves time.  Happy coding!

I wanted to share some general accomplishments from our first quarter of using Kanban in terms of metrics.  Our cycle times have been slashed in half!  Our backlog is the lowest I've ever seen it at.  And we've been able to quickly identify blockages and fix those issues.

I don't want you to think there's not room for improvement.  Our quality needs some work.  Since we don't have a QA group, we need to find some better way to bake in quality.  From the Kanabandev mailing list , Stuart C. mentioned that we could create a situation to encourage developers to better test their code.  This would be accomplished by forcing devs to change any bugs encountered after they say the change item has been completed.  This new work is in addition to their current work, so hopefully this encourages developers to create quality code.

I'm a little late to the party on this, but Microsoft is going to release their MVC for ASP.NET.  In Object Oriented programming I'm looking at this model, and I'm not initially sure if this helps.  If you already are creating loosely coupled SOA or standard objects, then what would be the reason for MVC?  We're already using Patterns, so I don't think that it will take the place of my current coding practice.  I'll keep looking at this to see what I might be missing, but I'd love to hear someone else's experience.