I used to be a believer that when a good idea came around you should throw it on the backlog.  Those ideas (or bugs) live on the backlog indefinitely waiting for their chance to "dance".  As I re-evaluate my thinking from a Lean perspective I am reconsidering that approach.  In Lean maintaining large amounts of inventory (queued inventory) is frowned up.  Without going into all the gory detail of Lean (if you are an Agilist, want to be an Agilist, or develop software go read about Lean and think about it in terms of your software development process - it will be good for you) large amounts of inventory lead to "inventory rot".  In the software world this amounts to requirements that were scoped two years ago by a Business Analyst that is no longer around or a bug reported by a tester two releases ago.  The information relevance in those backlog items has dropped considerably during the time that they were idle.  As time goes on and it becomes obvious that prioritizing them won't happen - close them.  Dump them.  If they are important they will show up again.

  In addition to trimming the backlog appropriately it may make sense to have tiered backlogs.  There will be a Sprint backlog (or Iteration Plan) that represents the work in flight.  It is useful to have an "on deck" backlog that represents the work coming up in the next 6 months or so.  The "long range" backlog represents those ideas and concepts that are more "out there" and likely are fairly vague, large, and inestimable.  Each backlog requires different types of care and feeding and involves different sets of people in the care and feeding process.  The Sprint backlog is the focus of the team, talked about in Standup as people report progress, and the tactical focus.  The On-Deck Backlog should be actively worked by the Business Analyst, Customers, Technical Lead/Architect, and Project Manager.  Perhaps this is a weekly, bi-weekly, or monthly meeting.  The Long Range backlog is likely discussed perhaps monthly or quarterly as needed to identify items ready to move on-deck and be fleshed out, identify new directions that need to be captured, and obsolete ideas that are no longer applicable (don't forget this one!).

  With bugs I subscribe to the Broken Window theory.  The more you have the less likely you are to care.  You have to be careful with that of course - take it too far and you end up with a product with no bugs, but no features either because you have spent all your time fixing bugs that weren't important.  Once a bug has been identified as costing more to fix than it is worth you start to have a case for closing it and dropping it off the bug backlog.

  The goal is to make sure your focus is where it needs to be.  Your Sprint Backlog efforts should be  focused on execution.  Moving those items through the development process as effectively as you can.  On-Deck Backlog efforts should be focused around locking down the requirements for the items so that they are ready to be executed on (a blog on how critical it is to do requirements definition is in the works).  The Long Range backlog efforts should be focused around making sure that you have outlined the key strategic elements for the future and analyzing them in the context of the market you are serving to see what value propositions make the most sense to pursue.

Note: I use this blog to post both Personal and Technical articles.  For a technical only feed use the following URL (http://bryanandnoel.spaces.live.com/category/technology/feed.rss).  For a family only feed use the following URL (http://bryanandnoel.spaces.live.com/category/family/feed.rss) Technorati Tags: Agile,Backlog,Lean,Software Engineering

I had a developer ask me how to use Resources the other day.  Honestly I had never used them for any production system and so I didn't know.  So I decided to find out.  Below is the code on how to do it in WPF and then after that how you would do it in Winforms. WPF

I borrowed a lot of  this example from http://mostlytech.blogspot.com/2007/09/enumerating-xaml-baml-files-in-assembly.html.  The article I link to showed how to iterate through Resources files that are in your solution with the Build Action set to Resource.  I then use that to put an image on a button that alternates every time it is clicked.  At http://forums.msdn.microsoft.com/en-US/wpf/thread/1bb025e8-a20a-43c4-a760-8666c63ff624/ it explains how to work with Resources that you define in the Resource tab in the Project Properties.  You can also set an image directly in XAML as shown below

using System;

using System.Collections;

using System.Collections.Generic;

using System.IO;

using System.Reflection;

using System.Resources;

using System.Windows;

using System.Windows.Media.Imaging;

namespace WpfApplication1

{

    /// <summary>

    /// Interaction logic for Window1.xaml

    /// </summary>

    public partial class Window1 : Window

    {

        private int ButtonClicks = 0;

        List<object> EmbeddedResources = new List<object>();

        public Window1()

        {

            InitializeComponent();

            Assembly asm = Assembly.GetExecutingAssembly();

            Stream stream = asm.GetManifestResourceStream(asm.GetName().Name + ".g.resources");

            using (ResourceReader reader = new ResourceReader(stream))

            {

                foreach (DictionaryEntry entry in reader)

                {

                    if (entry.Key.ToString().Contains(".jpg"))

                    EmbeddedResources.Add(entry.Key);

                }

            }

        }

        private void Button_Click(object sender, RoutedEventArgs e)

        {

            ButtonClicks++;

            ButtonImage.Source = new BitmapImage(new Uri(EmbeddedResources[ButtonClicks % 2].ToString(), UriKind.Relative));

        }

    }

}

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <Button Click="Button_Click">
        <Image Name="ButtonImage" Source="Images/IMG_7680.jpg" />
        </Button>
    </Grid>
</Window>

I didn't spend as much time looking at the Winforms side of things, but here is a snippet of code that can be used.  Note that I set the Build Action for the Image file to EmbeddedResource because that is what all the examples said to do.  Bitmap has an overload that allows it to resolve Resource References.  The name of the resource becomes <Namespace>.<Path>.<Filename>.

pictureBox1.Image = new Bitmap(typeof(Form1), "Images.IMG_7680.jpg");

Note: I use this blog to post both Personal and Technical articles.  For a technical only feed use the following URL (http://bryanandnoel.spaces.live.com/category/technology/feed.rss).  For a family only feed use the following URL (http://bryanandnoel.spaces.live.com/category/family/feed.rss) Technorati Tags: WPF,Winforms,Resources,.NET

  Most Agile methodologies I have tried, read about, etc... include the concept of Velocity.  Velocity essentially is a historical measurement of the rate at which a software team produces value.  I am currently reading Agile Management for Software Engineering by David Anderson.  I believe the term he uses to describe the philosophy of using velocity to predict future output is Empirical Process Control.  I haven't finished the book yet, but as I was thinking about empirical process control and velocity in the context of Lean and the Theory of Constraints I had the thought that I have been looking at velocity all wrong.

  The teams I have been a part of have generally looked at velocity in one of two ways, either it was the measure of how many work items went from Resolved to Closed (meaning that QA successfully completed testing them) or it was how many went from Active to Resolved (meaning that Dev finished coding and unit testing and was ready for the feature to be run through QA).  When reexamining that strategy in the light of Lean and Theory of Constraints we actually should have been measuring velocity for both of those functions (QA and Dev).  Theory of Constraints is all about identifying the bottleneck and managing your input into the system to make sure you 1.  Feed the Constraint as effectively as possible (don't let it run dry) and 2. Manage inventory so you don't overload the pipeline with excess inventory. 

  Before diving into how and why you would measure velocity at different points perhaps a little aside into the dangers of excess inventory is in order.  Say for example Developer Tom finishes Story A and marks it as Resolved so that it moves into Tester Tim's queue to QA Tom's work.  Tim is currently the constraint in the system so work is piling up in front of him.  He isn't able to QA Tom's work for a week.  Tom of course doesn't sit around for that week and he moves on to a new story.  A week later Tim discovers that something isn't working right with the feature Tom completed and reactivates it.  Now several bad things happen as a result of the delay - the work Tom did on Story A is no longer fresh on his mind and so he has to spend time spinning up on it again.  The work he started on the new story gets interrupted and he will have to take some time to reacquaint himself with it when he finishes the rework on Story A.  Additionally we measured velocity by how how much the Devs marked as Resolved and so the previous week we reported X number of story points completed when due to the rework on Story A it was only X minus the number of Story Points for A.  We have a mess on our hands.

  Now you can't eliminate rework in the system no matter how hard you try. QA will identify issues with the code Dev delivers and Devs will find issues with the story details delivered to them by the Analysts or Customers, etc...  By reducing the excess inventory in the system and managing to the constraint you can reduce the cost of the context switch that the rework incurs.  In our situation Tim is the bottleneck and we shouldn't keep piling up inventory on his doorstep.  We need to slow the cadence of the development line to match his production.  With the excess time in other queues you look how you can leverage them in the meantime perhaps developers use it for training or if excessive enough leverage them on a different project.

   In order to manage all this we need to measure the velocity at each queue in the process (a queue being Dev, Test, Requirements Generation and Development, etc...).  When we do that we can then look at the software process, identify the constraint, and then work the constraint to improve it if improving the constraint makes business sense.  If for example development is the constraint, at some point you hit the Law of Diminishing Returns where adding more devs or improving their productivity is more costly than the resultant throughput improvement.  Measuring throughput at the different queue levels is critical if you want to be able to accurate assess the health of your development efforts. 

  I think of Agile Management as Active Management or perhaps even better Proactive Management.  An Agile Project Manager is actively engaged in analyzing the system and determining where improvement is needed.  In so doing he is much more effective than the project manager that runs around checking with everyone if they are still on track with what the Gantt Chart says.

  Metrics are certainly an important part of the Agile Management process.  The metrics considered important by Agile/Lean are certainly differently than the ones historically used by standard methodologies, but still critical to guiding projects successfully.

Note: I use this blog to post both Personal and Technical articles.  For a technical only feed use the following URL (http://bryanandnoel.spaces.live.com/category/technology/feed.rss).  For a family only feed use the following URL (http://bryanandnoel.spaces.live.com/category/family/feed.rss) Technorati Tags: Agile,Theory of Constraints,Software Engineering

• OS (Vista preferred, but XP SP2 otherwise)
• IE8
• Firefox 3
• Google Reader Note Bookmarklet
• Live Mesh
• Office 2007 SP1
• Zoomit
• VPN
• Virtual PC
• iTunes (do I have to??)
• Windows Live Suite
• Twirhl (everybody says use Tweetdeck, but I persist frankly because I don't need anything more than Twirhl)
• Verizon Access Manager

• Visual Studio 2008 SP1 (including Team Explorer)
• Team Foundation Server 2008 Power Tools
• Mindscape File Explorer (VS Plugin)
• Resharper
• SQL Server Management Studio (at least the Express version)
• Fiddler 2

• PL/SQL Developer
• Oracle Locator Express

Note: I use this blog to post both Personal and Technical articles.  For a technical only feed use the following URL (http://bryanandnoel.spaces.live.com/category/technology/feed.rss).  For a family only feed use the following URL (http://bryanandnoel.spaces.live.com/category/family/feed.rss)

  Ed Bott covered this weeks ago when the news was made public that Intel was planning on skipping Vista and he provides good insight into the history around that and why it isn't super significant.  Being a former Intel employee the move doesn't surprise me.  It has been a little under a year since I left the company and they were already setting up that decision already.  A lot of the engineering effort to roll it out was slowed way down if not iced completely.  There is a lot of things I loved about Intel, but this Vista decision highlights one that always frustrated me.

  Intel seems to promote a "Do as I say not as I do" policy.  They tried mightily to get Microsoft to certify certain platforms as Vista Capable to promote hardware sales even when the hardware specs made the Vista experience sub-optimal (plethora of articles).  They also obviously promote people buying newer computers to get the latest processing power at a time when the average email reading, Internet surfing consumer has an average CPU usage of below 10% (a personal guess that I believe to be in the ballpark - if anyone knows a source for data like this I would be interested in it).  They want Vista in the consumer market because of the extra CPU requirements that features like the Aero interface bring yet internally they don't drink their own koolaid.

  Intel is a company and it is about making money fundamentally and I am sure they looked at the business bottom line and made this decision.  But it is nice to see companies that align their public message with their internal image.  In this case I think there is an mismatch between the message that Intel sells and the one they practice.  There is basically one option for a laptop through Intel's IT department (I don't count the ultra-thin as an option for most but technically there was the ultra-thin and then the laptop for everyone else) .  No Core 2 Duo options, 2 GB of RAM, slow HDD, small screen.  You can read in many places on the web what an appropriate developer machine is (like on Coding Horror), but those specs don't come close.  In my new job I was immediately handed a Core 2 Duo machine with 3.5 GB of RAM, good sized laptop screen, plus a large LCD. 

  I always got the feeling that even though Intel sells IT as an investment to your company that will bring good ROI internally they see it simply as a cost center.  My manager at Intel realized the insufficiency of the machines we were given and allowed budget for us to go out and buy machines that we could really use.  So for all of Intel's attempt to be cost conscious by providing a very limited set of IT supported hardware all they really did is promote more expense by forcing people to pay for an IT machine plus another machine that would really do what they needed.

Note: I use this blog to post both Personal and Technical articles.  For a technical only feed use the following URL (http://bryanandnoel.spaces.live.com/category/technology/feed.rss).  For a family only feed use the following URL (http://bryanandnoel.spaces.live.com/category/family/feed.rss) Technorati Tags: Intel,Vista,IT

  I was going to post this on Twitter - but shockingly - Twitter is down - I know - haven't heard that one before.  So in light of that - I am dropping my thought on my blog - so 2007.  Dare has some good thoughts around scaling and points out rightfully so that you can find examples of many different technologies that companies have scaled successfully even when you'll have people vehemently proclaiming that there is no way that technology can scale.  Scale in many cases is simply a function of how much work you want to put into it - guaranteed that the companies that Dare cites all have done some pretty tricky flips to eek out extra performance from their foundational technologies.  In the Team Foundation Server space which I follow quite heavily Brian Harry has documented on many occasions Microsoft's efforts to scale their TFS environment to meet the demands they place on it.

As a closing note people that take extreme (or absolute) positions on technology are almost always WRONG!

  Technorati Tags: Twitter,Scaling

See http://www.liveside.net/blogs/main/archive/2008/07/21/mac-client-for-live-mesh-review-and-download.aspx for the news!!!

  One of my first tasks at my new job has been to look at integrating the Exception Handling block and Logging block into our .NET Stack.  We are also exploring using Unity as the Dependency Injection container.

  Things were moving along as I started playing with Unity and the Exception Handling block, but as soon as I tried to simply add logging of the handled Exception - it all blew up in my face.  Fortunately others had discovered the problem as well which was traced back to a bug in the CLR which had previously been reported and marked as fixed in .NET 4.0.  Now I understand that bugs happen and especially when they are bugs in the underlying platform there is only so much to be done.  The Entlib team did provide a code fix that could be applied to the source code and then with a custom compilation of Entlib you could be off and running again.  Well sort of - having a custom version of Entlib introduces other problems when you are talking about using the VS config tool to manage Entlib config.  When deploying this to 30 developers so they can manage Entlib config on their projects it gets to be problematic as the instructions for getting the built-in config tool involves changing solution properties and copying binaries around are not trivial.

  If I were doing something out of the ordinary I would be more willing to pay the price  - but I am trying to do the most basic Unity-EntLib integration here.  I am disappointed that issues with such a common scenario weren't caught before release.  The p&p teams have obviously invested time to make Unity and EntLib play nicely together (ala the Unity extensions that are available out of the box to enable Entlib to work with Unity) - I would have imagined that acceptance testing of any sort would have caught this.  Perhaps the explanation is as simple as the issue repros differently (perhaps JITs differently) on different machines.  Here is hoping that when the fix to the binaries that is hopefully in the works comes out that the team will explain how this happened.  Based on the principles that p&p espouses I know they value quality highly which makes this even more unusual. 

 Note: I use this blog to post both Personal and Technical articles.  For a technical only feed use the following URL (http://bryanandnoel.spaces.live.com/category/technology/feed.rss).  For a family only feed use the following URL (http://bryanandnoel.spaces.live.com/category/family/feed.rss) Technorati Tags: EntLib 4.0,Unity

Note: I use this blog to post both Personal and Technical articles.  For a technical only feed use the following URL (http://bryanandnoel.spaces.live.com/category/technology/feed.rss).  For a family only feed use the following URL (http://bryanandnoel.spaces.live.com/category/family/feed.rss)

   In about a week I will be transitioning from my current team (Data Integration) and role as a Data Warehouse Engineer to what we call the .NET Stack team.  It has been great expanding my Data Warehouse experience - I am more familiar with the Kimball method of designing data warehouses now (and even see a lot of similarities between the Kimball approach to Data Warehousing and the Object-Oriented world that much of the programming world uses).  I won't be sad to leave the ETL tool behind that we use here (Business Objects Data Integrator or DI) though.  For the last couple of months DI and I have been working together with a very loose truce - I promise not to curse it too much if it promises not too crash or do otherwise crazy things.  My co-workers have been great to work with and I will miss sitting with them on a daily basis - a fun group to work with.

  In my new position on the .NET Stack team I will be working on defining, developing, and integrating various technologies and concepts that the .NET development teams working with the different Church departments can use to be more productive, effective, and efficient.  This will allow me to be back involved with Team System/Team Foundation Server like I was at Intel which I am very excited about.  I will also be spending time with WCF, WPF, nHibernate, Entity Framework, LINQ, and a lot of the other .NET technologies out there.  Should be a fun and challenging task - looking forward to it!