I wanted to open a discussion about the concept of code freezes in Scrum. I attached a few blog articles to help curve any discussions. First I apologize about Bob Hartman’s vernacular, he is so passionate about anti-patterns in Scrum (I admit maybe to passionate).

Quick Story:
During my tenure as a .Net Lead/Manager, I attempted to solve a problem by creating a concept called “code freeze”. On our team I was trying to give time to fix bugs and solve coding issues. Sounds innocent right, I thought so too. There were bugs that only seemed to come up after reviewing code changes just before a product release. So I built out “code freeze”(stop doing, review and fix). My Sr. Scrum Master, at the time, proceeded to slap my “ego”/hand about this as soon as he was made aware of what I was doing. First, he asked me a few questions about my goals around “code freeze”. We discussed the teams typical Sprint issues, see if any of these matches what you could be going with your teams:

1. Business interests in mostly Project Management, they wanted drivers, leading indicator, ever increasing “Velocity” (and of course they did not want to pay for it)
2. Business is engaged at the end of the Sprint and/or with limited involvement and/or input during development time.
3. Business writes all requirements up front without Leads and/or Team present, leading to unrealistic commitments to customers
4. No time frame in the middle of the Sprint for code reviews and “gut” checks, like Sprint Reviews with the Business and/or QA
5. Bugs found always at the end, when the Lead, or business had time to review it leaving no time to fix issues
6. Bugs don’t add to Velocity, so teams don’t want to report them to the Product Owner to be prioritized in the Backlog (bugs are bad and the more you have the “perception” is you’re not doing well)
7. Lead doing more of development work the their individual team members
8. No time for refactoring to write better code.

I explained my attempt to reduce time to fix bugs or refactor badly written code. I gave him a couple of examples to bring power to my intent and frustrations with Scrum. One goal I wanted was to get more time to fix bugs found by our business analysts and/or quality control team. He asked me about how I managed bugs and how I can simply add this to the next Sprints Backlog. ‘Oh’, I said, like that was no big deal, “I can just add them like Stories and tasks”. I let him know that was unrealistic, especially since bugs don’t add to Velocity and they report to the Business that this team has no clue how to write code.

I really wanted a good “Product Release” every time (Goal). My manager “hat” wanted to solve this myself. I was supposed to lead the team and help them meant solving it, right? My Scrum Master and I spend more time on our team’s Sprint and Release Planning process. His goal was to make sure all players (devs, BA, QA, etc.) were involved in the Sprint Planning process before moving on with development. He was concerned I was trying to improve on the process without attempting to understand the real problem. My Scrum Master and I continued to improve business engagement, beginning by improving communication about product status, then involving every team in the coding process. If the QA was on another team, he challenged me seek out the business to provide more dedicated resources. Next, we implement Mid-Week Sprint Reviews, for Business Analysts mostly, and demo what we think is the right implementation. This meeting facilitated early discussion about our code and what we were writing it also was not a formal meeting. Next we planned our Stories to be smaller, we included testing, deployment, automation, and included time for risk and uncertainty. Finally, he helped our team remove my perceptions about Bugs. We planned time to discuss how to improve bug reporting to the business and reducing them with early feedback indicator from the testing team. I learned, if QA automation scripts run the whole application, this could take a while and not a good practice for improving feedback during a Sprint. So I would periodically meet with the QA team and help them build out a more local automation script for the current Sprint. This really improved on communication about bugs and provided an early warning indicators if we were on target.

To my surprise my Sprint Velocity improved dramatically. Removing my desire to manage code changes directly, we opened the opportunity for our team to get involved with problems early. This resulted in improved development cycles, improved testing and quality code, it reduced unrealistic expectations (numbers don’t lie, Velocity is what a team can do, its empirical data, don’t fight it). Ultimately we just did not need the “code freeze”. We improved on business interactions, on early indicators from our testing team, and we increased everyone’s participation in Sprint Planning and Sprint Releasing process.

Velocity Slump Indictors: If there are teams with Leads doing all the talking in Sprint Planning, this can indicate a lack of team cohesion. (See: ). Team Leads (as I learned too) should not be doing all the design and discovery work. Let your less experienced team members design the solution during Sprint Planning. It was scare when I tried it too. Help them learn about identifying risk in their own ideas, and plan out the process for themselves. This power can boost their creativity and promote team ownership. (I learned this the hard way from my “favorite” architect, he really challenged me to lead by example)


I thought I post a conversation I am having with the team I work for about WPF vs Winforms

Their question stated, is WPF built on the premise of usability by providing easy to use styling in XAML with resource styling and theming?

My response: There is a learning curve with WPF, but styling is really not the major concern if you plan to use component like DevExpress. A drawback to WPF is developers (me included) can become overly concerned about styling, leading to misuse. WPF is designed to separate design/presentation concerns from the development/business concerns and so on. The real learning curve in “data-binding”. WPF can minimize concerns around user experience (UX) and styling. Of course, users learning any new application really has nothing to do with the underlying technology choices. It’s really the psychology around how people think, behave, their “way of work”, and their interactions with specific interface components, hence the concepts around UX. UX is about whether particular components improves user experience, drive new behaviors, or how it may achieve business related benchmarks. It really has nothing to do with the underlying technology. On the other hand, UX may influence a decision around what to use at the component level, but not around the governing technology, like whether to go with WPF, Winform, or ASP.NET.

There is quick guide about layering and Separation of Concerns at the following URL if you’re interested in learning more:

Their question stated, What are to pros lists out with MVVM specifically. Is this just an example, or are we considering other design patterns as well?

Mike’s response: Agreed, MVVM is about the way WPF is implemented. But that is the point. WPF/MVVM is symbiotic conveying the importance of WPF as an enterprise team oriented technology. The goals of MVVM vs MVC are different. The MVC, used primarily by ASP.NET, implements “controllers” that invoke server defined views associated with a model. ASP.NET MVC use this for good reasons when streaming views through any number of “throttled” internet connections. In WPF this would lead to unnecessary duplication, a dependence on models, and a lack of command/notification driven approach. WPF/MVVM is concerned about providing scalability, maintainability, and making allowances for reusable components.,-MVP-and-MVVM-Design-Patterns.html


Hi all! Here's some quick code to support linq and try...catch scenarios. In an attempt to traverse a list, the results should be string array of values, really simple. By unraveling a property chain on an object it could result in a NullReferenceException. I really wanted a Linq expression that provided a try…catch scenario and execute an "Or” type expression if an exception occurs.

Let’s review the extension class. First, I built a tree of expressions from the start of my .Try() method, then my .Or() method finalizes to result. For example, I have a list of conditions and each condition has a left expression, operand, and right expression. The lambda expressions could throw an exception so my Try..Or expression uses an alternative way to handle potential exceptions.

enumerable.Where(x => x.LeftExpression.Value.Equals("SomeData"))
.Try(x => x.RightExpression.Value).Or(x => string.Empty)

This quickly solves the need to test or catch errors, within each property also a quick way to extend the ability return a result set. HEADS UP!! I also included an OrElse statement as well.

enumerable.Where(x => x.LeftExpression.Value.Equals("SomeData") )
.Try(x => x.RightExpression.Value).OrElse(x => x.LeftExpression.Value)
.Or(x => string.Empty)

Here's the code: (also below is some erroneous html, sorry just delete it)

    public static class IEnumerableExtension
        public static Tuple<ienumerable <TSource>, IEnumerable<func <TSource, TResult>>> Try<tsource , TResult>(this IEnumerable<tsource> source, Func<tsource , TResult> selector)
            return new Tuple<ienumerable <TSource>, IEnumerable<func <TSource, TResult>>>(source, new[] { selector });

        public static Tuple<ienumerable <TSource>, IEnumerable<func <TSource, TResult>>> OrElse<tsource , TResult>(this Tuple<ienumerable <TSource>, IEnumerable<func <TSource, TResult>>> source, Func<tsource , TResult> selector)
            return new Tuple<ienumerable <TSource>, IEnumerable<func <TSource, TResult>>>(source.Item1, source.Item2.Concat(new[] { selector }));

        public static IEnumerable<tresult> Or<tsource , TResult>(this Tuple<ienumerable <TSource>, IEnumerable<func <TSource, TResult>>> source, Func<tsource , TResult> selector)
            var finalized = new Tuple<ienumerable <TSource>, IEnumerable<func <TSource, TResult>>>(source.Item1, source.Item2.Concat(new[] { selector }));
            return finalized.Item2.SelectMany(method => source.Item1.Select(method).Catch());

        private static IEnumerable<t> Catch<t>(this IEnumerable<t> source)
            using (var enumerator = source.GetEnumerator())
                bool next = true;

                while (next)
                        next = enumerator.MoveNext();

                    if (next)
                        yield return enumerator.Current;

Writing test is simple. Pick a class or object; start writing a test to the functionality, and use assertion to see if my test assumptions are right or wrong. If they are wrong re-write the test to fix it. This viewpoint to writing a test can lead to mistakes in so many areas. Considered a classes function, purpose, does the test cover all dependencies on classes or even how “deep” the functionality should be to complete a test. What about inherited classes or COM objects that can run in a unit of code or work?

Have you considered if the test covers all the possibility of this specific unit? What is my intent to write an “implementation test“. If your intent is to write a more functional or implementation test great, but beware it is not a distributive unit test.

In this next series of blogs, I will discuss how to start and finish a good unit test and the difference between implementation test and unit test and avoiding the pitfall associated with each approach, and finally on mocks in Visual Studio.

A unit test is by definition a single test designed to assess a unit of code in combination with diverse inputs and output with the unit. Code is written in the concept of units, such as a mathematically class which may contain a “unit” of code to add two numbers. This class provides a “function” or “method” specifically designed for a single purpose. The code may call on external functions to develop into a unit of work, but we should attempt to ignore influence on the unit. The school of thought for unit test is to maintain only my unit of work and to avoid maintaining external units of work. Here are a few tenets to help you get started.

  • Tenet #1: Only test one unit, the function or method called is the only code to test
  • Tenet #2: Refactor code that creates dependencies on external units
  • Tenet #3: Mock all dependencies on external units
  • Tenet #4: Try to go no more than one level deep into any one unit
  • Tenet #5: Each unit test should cover one scenario of the unit; build another test to cover different scenarios of the same unit. Such as expected errors from a try…catch block

dependencies are at times unavoidable; refactoring your code can help. When code is considered untestable, it’s probably due to a dependency on another class or function, use common design patters to help resolved these issue. For example, when writing WPF applications, Model-View-ViewModel (MVVM) pattern is a dependency separation model to a view and event from this view. One example is the MessageBox control. When a unit test is tested the process of running the test may stop to show a message box, and this inadvertently causes or test process to wait for user response. Using the builder patterned, (see. Builder Pattern (, I can create a class named MsgBoxBuilder. This class will ultimately call the System.Window.MessageBox, now my code is testable. When passing MsgBoxBuilder as interface to the constructor of a View Model, I can use a “mock” to remove the dependencies on the MessageBox control, and I am ready to test my code.

Example : Refactored code in MVVM style for a MessageBox

    public class MyManagerViewModel : IMyManagerViewModel 
        private readonly IViewModelFactory _factory;
        private IMsgBoxBuilder  _msgBox;
        public WellboreManagerViewModel(IMsgBoxBuilder msgBox = null, 
            IViewModelFactory factory = null)
            _factory = factory ?? new ViewModelFactory();
            _msgBox = msgBox ?? new MsgBoxBuilder();

    public class MsgBoxBuilder : IMsgBoxBuilder 
        public void Show(string message)

        public void Show(string message, string title)
            MessageBox.Show(message, title, MessageBoxButton.OK);

My Next Blog we will discuss Tenet #3 using only Visual Studio 2012.


If you looking to create a clickonce package in Visual Studio that is created using Team Foundation Server's Automated Builds(MSBuild), here's an idea I found worked really well for me. Basically, the goal is 1) to create a ClickOnce package from the Build server, and 2) to create a bat file that can move the files into a version-ed folder upon request. If you add this to your project file, use "mage.exe" -

The Clickonce packager within Visual Studio is available for every project, but it does not account for the build that needs to pull dll's into a Release folder post the build, and any non-referenced dll's in your project. Geek moment, I'm done.

For additional help with mage.exe, go to MSDN Mage.exe (Manifest Generation and Editing Tool)

Review the code below it should help.

   <target Name="PostBuildMacros">
     <getassemblyidentity AssemblyFiles="$(TargetPath)">
       <output TaskParameter="Assemblies" ItemName="Targets">
      del /Q "$(TargetDir)*.application"
      del /Q "$(TargetDir)*.docx"
      del /Q "$(TargetDir)*.manifest"
      call "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\mage.exe" -ClearApplicationCache
      call "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\mage.exe" -New Application -FromDirectory "$(TargetDir)." -Name "$(TargetName)" -Processor "$(PlatformName)" -Version @(Targets-&gt;'%(Version)') -ToFile "$(TargetDir)$(TargetFileName).manifest" -IconFile "Resources\EMfinditLogsLogo.ico" -TrustLevel "FullTrust" -Publisher "YourCompany" -UseManifestForTrust "true" -CertFile  "$(TargetDir)$(ProjectName)_TemporaryKey.pfx"
      call "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\mage.exe" -New Deployment -AppManifest "$(TargetDir)$(TargetFileName).manifest" -Name "$(TargetName)" -Processor "$(PlatformName)" -Version @(Targets-&gt;'%(Version)') -ToFile "$(TargetDir)$(TargetFileName).application"  -Install "true"  -CertFile  "$(TargetDir)$(ProjectName)_TemporaryKey.pfx" -Publisher "ExxonMobil"
      call "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\mage.exe" -New Deployment -AppManifest "$(TargetDir)$(TargetFileName).manifest" -Name "$(TargetName)" -Processor "$(PlatformName)" -Version @(Targets-&gt;'%(Version)') -ToFile "$(TargetDir)$(TargetName).ctp.application"  -Install "true"  -CertFile  "$(TargetDir)$(ProjectName)_TemporaryKey.pfx" -Publisher "YourCompany" -AppCodeBase "@(Targets-&gt;'%(Version)')\$(TargetFileName).manifest"

      echo \$(TargetName).ctp.application\ &gt; exclude.txt
      echo $(TargetFileName).application &gt;&gt; exclude.txt
      echo \MakeReadyFor.ctp.bat\ &gt;&gt; exclude.txt
      echo \exclude.txt\ &gt;&gt; exclude.txt

      echo mkdir "../LogAvailability_CTP/@(Targets-&gt;'%(Version)')" &gt; MakeReadyFor.ctp.bat
      echo xcopy . "../LogAvailability_CTP/@(Targets-&gt;'%(Version)')" /s/i/q/y/exclude:exclude.txt &gt;&gt; MakeReadyFor.ctp.bat
      echo xcopy "$(TargetName).ctp.application" "../LogAvailability_CTP" /s/i/q/y &gt;&gt; MakeReadyFor.ctp.bat