If you’re looking to achieve the MSCD ALM certification, there are three tests you need to know about.  Below are resources for all three exams.

70-498: Delivering Continuous Value with Visual Studio 2012 Application Lifecycle Management

Recently Anthony Borton (EnhanceALM) and myself (Steven Borg) ran an 8 hour Jump Start training session to prepare for the Delivering Continuous Value with Visual Studio 2012 Application Lifecycle Management (70-498) exam. There were over 700 attendees from over 60 countries!    If you’re interested, it’s not too late to watch some or all of the event.  Microsoft recorded the training as 7 separate sessions. Below are links to watch the those sessions.

• Applying ALM with Visual Studio 2012: (01) Introduction and Exam Overview: This module provides an overview of the Path to MCSD: Application Lifecycle Management, and which exams are part of this certification. It focuses on the requirements and preparation necessary for taking the exams.
• Applying ALM with Visual Studio 2012: (02) Define an Effective End-to-End Software Development Lifecycle: In this session Steven and Anthony address the value of an end-to-end view of Application Lifecycle Management (ALM) tools and practices. They explain the benefits of fast feedback and go over strategies to reduce end-to-end cycle time, to improve software quality and how to implement and track these.
• Applying ALM with Visual Studio 2012: (03) Define the ALM Process: There are different roles in the ALM processes. Tune into how to implement a Scrum/Agile process, how to define a Scrum/Agile process for a team using the Microsoft Solution Framework (MSF) for CMMI Process Improvement.
• Applying ALM with Visual Studio 2012: (04) Define a Software Iteration: The key to a successful release cycle is to plan a release by defining project-tracking and scoping it correctly. Watch this module to see tips and tricks on the best practices from two experts in the field.
• Applying ALM with Visual Studio 2012: (05) Define End Value for the Software Iteration: In this module Anthony and Steven provide an in depth overview on the best ways to elicit requirements, how to best estimate, document, and prioritized requirements.
• Applying ALM with Visual Studio 2012: (06) Develop Customer Value with High Quality: The success of a project requires clear understanding of success measurements. Watch this session to learn more on defining code quality indicators, how to incorporate unit testing, how to develop code and validate quality.
• Applying ALM with Visual Studio 2012: (07) Integrate Development and Operations: This module provides an overview on implementing an automated deployment process, implementing a pre-production environments and how to manage feedback between development and operations while successfully troubleshooting production issues.

70-497: Software Testing with Visual Studio 2012

Following up on the success of the 70-498 Jump Start, Microsoft is sponsoring one for the 70-497 exam.  This exam is focused on delivering end-to-end quality for the Visual Studio 2012 tools, and contains a large number of questions around the Testing tools.  This Jump Start is LIVE at the end of May. Like the 70-498 exam, it will also be recorded and available via streaming video.  Both Anthony Borton and myself will also be delivering this course.

Date: May 28th
Exam: 70-497: Software Testing with Visual Studio 2012
Register
More Information

70-496: Administering Visual Studio Team Foundation Server 2012

On the day immediately following the 70-497 Jump Start, Anthony and I will deliver the 70-496 Jump Start. This exam focuses on the installation, configuration, and administration of TFS 2012. 

Date: May 29th
Exam: 70-496: Administering Visual Studio Team Foundation Server 2012
Register
More Information

I’m looking forward to seeing you at the upcoming Jump Starts!  If you have any questions for Anthony Borton or myself, please don’t hesitate to email us!  (Feel free to use the email below!)  Alternatively, you can tweet your question to @stevenborg.

For additional information or question, please contact clientservices@nwcadence.com.

Northwest Cadence can help you implement a modern application life-cycle. Call rick.flath@nwcadence.com today to help you get there more easily...

The open-source getKanban game is a great learning tool, but its affordability comes at a price. We still like it. Here’s how we are adapting it to better suit our objectives.

Andrew, Steven, and I have been using the open-source version 2 of getKanban in our new Agile Foundations course. Thanks to the heroic efforts of Mykaela back at the office, we’ve been able to travel with lightweight disposable game kits and have run it 20+ times across Seattle, London, and Budapest.

During our first sessions in London, Steven, who has played the game (and its successor versions) zillions of times, wanted to hack the rules; I, who had never played it before and am sensitive to the interconnected nature of game mechanics, insisted we must not tinker with it. I won the battle, but Steven won the war. Long after Steven had flown home for quality time with his new baby, Andrew and I ran the game many more times and grew frustrated with its limitations. It teaches the mechanics of Kanban well enough, but team after team taught themselves the wrong lessons about Lean! (See also: Underpants Gnomes.)

So, at last, we hacked the game.

What we hacked and why

We set up the games during a tea (it’s London) break, and I commandeered a flipchart for the hack and a few general tips, in roughly chronological gameplay order (see image):

Our tips and hacks at the start.

1. Because teams consistently set aside the stories they’ve already accounted for in their finance charts every third day, and then lose track of them and screw up their Cumulative Flow Diagrams. Most teams improved upon this suggestion by making a Paid substate at the bottom of their Done column instead of to the right, which works better because it keeps them all inside the orange border where they can more easily be counted. About half the teams screwed up their CFDs anyway.

2. Just to make it easier to do the finance charts. It helped. NBD.

3. This is the big hack and requires further explanation below.

4. I originally wanted this to be “reduce, but not increase”; Andrew said I was making it too easy for them so we left it generically “alter”. Sure enough, every single team who changed their WIP initially raised it.

I also created a separate flip chart listing the seven Lean principles we taught the day before. I wrote Limit WIP in the brightest color and made it slightly larger than the other six. Andrew said I was making it too easy for them.

Learning objectives and how they are thwarted

You start getKanban on Day 9 with a board full of stories and some WIP limits, and you’re meant to discover that your cycle time is averaging 8-9 days, which is far too long. The economic model of the game punishes teams quite severely for long cycle times. This begins to dawn on the teams and there are a few things they can do to try to improve:

• Reprioritize stories (pop the most expensive ones to the top of their column to push them through faster)
• Reallocate personnel (designers, developers, and testers swarm to help clear blockages), represented by dice

Teams quickly gravitate to these two strategies, not realizing that they are only optimizing the speed at which items move from one column to another—not the speed of the whole system. As they expedite individual items, the cycle time for everything else in fact gets worse.  What we really want them to understand, but which the game doesn’t offer any direct clues about, is to reduce cycle time systemically by:

• Limit Work in Process

We spent considerable time the day before teaching them how Little’s Law proves, using math!, that limiting WIP is a leading metric for cycle time. But it’s a new day, and they’ve all forgotten.

Enter Carlos.

The trouble with Carlos

Firstly, there’s someone on our customer’s team called Carlos. He’s a delightful person and not at all deserving of the animus directed at getKanban’s evil test manager character Carlos. He attended our earlier, pre-hacked training course and handled the evil character with much grace. (If I were to keep playing with evil Carlos, I’d definitely want to Photoshop a goatee onto a picture of delightful Carlos…)

The worse problem with evil Carlos is that the appearance of his character and his evil rules is a distraction from the Lean principle we most want them to learn: that to reduce cycle time systemically, they need to lower WIP.

By the time Carlos appears, nearly all teams have begun to figure out that their Kanban boards are telling them bad news, and most teams are attacking this problem with a little bit of reprioritization (the game, awesomely, intentionally makes this difficult by presenting many competing but hard-to-compare incentives and risks) and a lot of reallocation of dice, I mean personnel, especially to the Test column, which by now has emerged as a bottleneck. Carlos’ evil rule is that personnel may not be allocated into or out of Test. It takes that tactic off the table for several days, enough for a massive queue to build up ahead of test, leading to uncontrolled congestion and blocking the rest of the team.

Unfortunately, nearly all teams want to attack this problem by increasing WIP in Test. Their devs and designers aren’t allowed to help clear the Test queue, and Carlos is pissing them off, so they see no option but to make it Carlos’ team’s problem. Just like life, isn’t it? They win the battle and lose the war. Their designer and dev dice are back up to full utilization, piling more work into the Test queue that’ll never be completed. By the time (spoiler alert) Carlos gets fired, even with the onboarding of a new tester die, the queue’s grown too gnarly to clear before the game ends.

Even though Carlos is supposed to take resource allocation off the table, in real gameplay it tends to cause teams to rathole on resource allocation and ignore WIP, or misuse it in frustration. They don’t learn what we want them to learn.

And so, hack #3. We killed Carlos. (The one with the goatee.)

(I made one error in the details: about half of our teams, heeding the instruction to “ignore Carlos”, ignored all instructions regarding Carlos, including the one where he [spoiler alert] gets fired, so they overlooked the good news therein about hiring another tester and thus never added their third tester die.)

A better way?

Our six teams started their hacked games the same as always, with Andrew leading them through Day 9 (the game’s starting day) step-by-step, prescribed-dice-roll-by-prescribed-dice-roll. This level-setting first day is quite helpful in managing large groups and multiple game boards. He had to use his Unruly Class Voice to be heard most of the time—teams engage with this game right away and they’re eager to get going.

As the teams started Day 10, trying to navigate the game’s confusing rule set on their own and handle their own now-random dice rolls, we strolled around, answered questions, and tried to catch errors. I dropped hints to the teams about the kinds of choices they should consider making:

“You’ve got the fixed-date audit story on the board, good. You started it on Day 9? Great.

“When’s it due if you want to avoid that big fine? Day 15?

“And what’s your cycle time right now? There on your Control Chart 9 days? So at that rate when’s it going to be done? Day 18? That won’t work, will it?

“Hmm, what can you do to move that story through faster? I see you’ve reprioritized it to the top of the Design column. That’ll help. What’s another way you can reduce your cycle time?”

After a few circuits around the room, I discovered that one team with whom I’d had this conversation, with a team member who’d seen the game played before, had raised their WIP limits.

That’s it. I’m not going to take this anymore.

My really big hint, to which Andrew objected.

A great big hint they cannot possibly miss…

I stomped up to the front of the training room.

“Andrew, I need to project that Little’s Law slide.”

“No way. You can’t just tell them. That’s too easy. They need to learn it for themselves.”

“But they’re not learning it for themselves. We’ve done this twelve times and they never have. I think we need to coach them to get it properly.”

“It’s too much.”

“Just enter your password and open that deck.”

(This is, by the way, a total role-reversal from our normal M.O. in consulting and we argue about that too.)

… which they missed

We were both wrong. The hint on the projector wasn’t too much, and it didn’t help them get it. I strolled around, I called teams’ attention to Little’s Law, I flat-out told them that limiting WIP is mathematically proven to reduce cycle time, and at one point I literally jumped up and down pointing at the screen.

None of the teams lowered their WIP.

A chance encounter

We told teams to self-organize their comfort breaks, so after several days of gameplay I happened to run into Fiona, a Product Manager, in the ladies’. She was quite bothered by the state of her team’s game board. 

“I don’t know how to explain it. I know there must be several stories stuck on the board where we’re going to lose money because they won’t be done in time because our cycle time is too high. I feel like if I could just do the mental arithmetic, those stories would be flashing red at me, but I can’t do the math quickly enough, and I can’t explain it to my team! It’s so frustrating!”

Her team consisted of herself and two senior developers. I told her to find a notepad and do the math with a pencil and show it to them. They’re devs, I said. They respond to math.

“And while we’re on the subject of math, have I mentioned how Little’s Law proves mathematically that lowering WIP reduces cycle time?”

Fiona headed back to the training room in search of a pencil.

Show, don’t tell

Andrew’s and my high-speed low-WIP game. Flipchart with the Lean principles is in the background.

In previous training classes during the game wrap-up discussion, Steven had told us that if you drop the game’s starting WIP limits from 6, 3, 5, and 3 to 3, 1, 1, and 1, you’ll get to where you can deliver multiple stories every day with an average cycle time between 1 and 3 days. No one ever believed him, because their gameplay had gone so differently and the image of goateed Carlos was fixed in their minds as the reason for it.

This day, Andrew and I realized: Mykaela packed us a spare, seventh game kit. I brought a quart of Chessex six-sided dice from home, so we had plenty. The teams are playing self-sufficiently enough, and since we know the rules quite well, it wouldn’t be hard for us to make up the head start they had on us time-wise. Why not crank out a game of our own with the WIP limits we want, and prove to the class how much better it works?

We hurried to set up the board and rushed through Day 9, honoring the game’s WIP limits at first so as to start Day 10 in roughly the same situation as our teams had done. Then we dropped them down, but not to 3, 1, 1, and 1. We picked 2 for the Ready queue, 1 for Design, 3 for Dev because the dev effort required on stories tended to be large, and 2 for Test because we still had a testing bottleneck and queues that we knew would take time to work through. We planned to drop WIP even further when things cleared out.

And that’s when things went not at all as I/we expected.

A difference of WIP queues

We started deploying stories fast, and like everyone else we swarmed dice on Test to clear the queue there. But as I ran the Control Chart, our cycle time didn’t fall. Day after day, it in fact grew worse: from 8 up to a solid average of 11 and a high of 12. 12! Just like all the other teams, we were delivering plenty, but we started to lose subscribers and money because we couldn’t bring our cycle time down. Even with every single resource swarming Test, and halfway decent dice rolls, the queue remained stubbornly in place, and the Dev queue behind it wasn’t shrinking either.

It took nearly our entire game to unwind the starting queues and get our cycle time down!

We discovered Design’s WIP limit of 1 made it 50-50 on any given day whether we’d starve it, or congest it so we couldn’t start anything new. With Ready’s WIP limit of 2, if we got blocked by the limit in Design, we couldn’t introduce new stories onto the board at all, which meant we couldn’t reprioritize to get high-value stories through as their deadlines approached.

We survived the financial audit without a fine—just, and only because we’d put it into Ready on Day 9 when the WIP limit was still 6! You can see its little trough there on the control chart: we moved heaven and earth to push it through in 4 days, which as it does for every other team meant that the cycle time on the stories behind it went up for a while.

The end of the game approached and I couldn’t believe I was still plotting in the 10- and 11-day cycle time range!

Finally, as you see, things cleared out and our last two stories had the promised land: blazingly fast cycle times of 3 days each. And then we ran out of days!

Game over!

We finished the game with about $15,300 on our finance chart, but I’m not sure this was so much because of WIP as because we knew which stories were the highest value, so we could game the economic model. (We also screwed up and forgot to apply the Blocked sticky at the proper time; we did it a day late. This gave us a small-but-cumulative financial advantage because at least one story deployed before it should have.)

We deployed nineteen stories. The only ones we managed to get onto the board ourselves were the same ones we flew through in 4 days, 3 days, and 3 days. All the others came out of the start-of-game queues.

So what happened?

You start getKanban on Day 9 with a board full of stories. 17 of them. The clock’s already started on their cycle time.

When you lower WIP on a column with items already in it, you don’t push the stories back in time: you just wait until you move them forward out of that column, and you decline to replace them, until you’re under your new limit. So those 17 stories are sitting in expensive queues, and no matter how early you lower WIP, the queues remain. And the queues kick your ass, even if you are a high-powered consultant who’s supposed to know what you are talking about with respect to cycle time.

We hypothesize now that our WIP limit choices may not have been ideal. We were guessing. Perhaps it would have been better to squeeze down WIP from the leftmost column first, gradually to the right as the queues moved along, rather than tightening the bottleneck at the end while there were already multiple queues behind it.

Maybe better dice rolls at better times would have saved us. (We think the dice have tiny goatees, and we are inclined to blame them for our problems.)

Meanwhile, our teams finished their games with a really similar frustration level but without blaming the evil Carlos. Most teams made a bit of money; about half lost the $2,200 to the auditor fine; about half reduced their WIP; only one of those really saw their cycle time start to drop before they ran out of game days.

Which team reported that lowering WIP really helped their cycle time, and had the Control Chart to prove it?

Not me and Andrew.

Fiona!

What have we learned?

I went into getKanban (repeatedly, on more than one continent) certain that the lesson I was teaching with it was that lowering WIP reduces cycle time.

I think I was wrong. At least partly.

I think the first lesson of getKanban, with or without evil Carlos, with or without lowering WIP, with or without evil dice, is that queues suck.

Another thing my very smart colleagues have proved, using math!, is that once a queue has formed, it’s impossible to get rid of by normal means alone; extraordinary effort is required. In the game, you swarm the dice and hope to roll a crit. In software development, you declare a bug bash or a stabilization sprint or a tiger team or some other special project effort to clear whatever your queue is: defects, untested code, disruptively innovative features, or technical debt. In-game and out, it’s expensive and it takes time.

The danger and stubbornness of queues is a powerful lesson indeed. Playing the game, more so than hacking it, helped us instructors understand that getKanban version 2 teaches this painfully well!

What about cycle time?

Fiona’s team saw modest-but-noticeable improvements in cycle time after they lowered their WIP. I think there’s hope for this lesson too!

Future hacks

• Rest in peace, evil Carlos. We’re keeping you dead.
• I still like giving teams hints.
• We’ve talked about extending the number of days in the game, to allow teams to see and feel the unwinding of the queues more effectively. This is potentially challenging only because new players can take a long time just to get through the days as written (and there’s always one team that falls behind and gives up entirely).
• Steven keeps telling us how the later (expensive, non-open-source, non-travel-disposable) versions of getKanban eliminated dice entirely in favor of standardized effort cards. No randomness means all variation in outcome can be traced to teams’ in-game choices, which makes the impacts clear and allows for meaningful comparison with other teams.
• We’re threatening to write a getKanban version 2 simulator to play through all the variations of WIP limits that we now want to try. (One of the many perks of leading the NWC Practices Team!)

Have your say

Have you learned, or taught, the value of lowering WIP or eliminating queues to shorten cycle time? What was your a-ha moment? What, if anything, persuaded you that it would work?

Northwest Cadence can help you implement a modern application life-cycle. Call rick.flath@nwcadence.com today to help you get there more easily...

By the time you hit the AgentScope activity in a TF Build workflow you are already running on the agent and if you have things you need to configure you need to figure out some way to reserve an agent before you get there.

• Update 2013-04-04 – All three of the activities below have been added to the TFS Community Build Extensions project on Codeplex and will be in a future release.

There are a number of reasons that you might want to reserve your TF Build Agent in Visual Studio 2012 Team Foundation Server before you hit the default AgentScope. The one I am working on with a customer is that they have a build that can only be executed once on a Build server and then always fails. Yes, the build breaks the Build Agent. Yes, I know that this is something that is the development team’s responsibility and should fix it but the Software Configuration Management (SCM) team that owns the servers can only encourage good behaviour and not enforce it.

Figure: Agent Scope runs on the agent

The current solution is to revert the build server to a snapshot after every build. This causes a bunch of knock on problems:

1. Revert to Snapshot
   We need to revert the VM Ware server to a Snapshot after every build.
2. Removed from Domain
   As the snapshot can be more than 30 days old the Active Directory machine security token may have expired in which case you would need to re-join that server to the domain. The result of this is that the Infrastructure teams will not have these build servers on the domain. And rightly do…
3. Shadow accounts need to be used
   As our computers are now in a workgroup we need to setup and maintain shadow accounts for access.
4. You can only use one AppTier
   As we need to maintain shadow accounts and these need to be one on each AppTier we end up with either AppTier1\MyAccount or AppTier2\MyAccount. So on the build server we get a conflict of Workgroup as these two accounts vie for workspace mappings.

So what can we do to alleviate this. One idea, the one that we’re going to try,  is to take the snapshot at the beginning of the build and revert at the end. That way the snapshot we are reverting to is only a few hours old at worst and our Build computers can continue to be serviced normally. Unfortunately we only know the agent… on the agent…

The way to solve this is to either rewrite the AgentScope Activity (not going to happen) or to do something a little sneaky. How about if we add another AgentAcope, reserve the agent in some way and then run the real agent scope…

1. DONE Reserve Agent in some way
2. Execute some action against the Agent
3. DONE Run on Reserved Agent
4. Execute some action against the Agent
5. DONE Reset the Reservation 

While this does complicate the build process, it does indeed look to be the best bet in this circumstance.

Figure: Reserve an agent before you execute the build for real

Reserve an Agent in some way

This should be simple even though it looks a little convoluted.

1. Add additional AgentScope
2. DONE Add a Tag to the Agent
3. DONE Get Machine name of the Agent
4. Exit AgentScope

Figure: Add additional AgentScope to reserve an agent

In this additional Agent Scope we can now call GetBuildAgent to populate the data we need and gain access to the Tags. However, we need to do a couple of things that are not normally done:

Add a Tag to the Agent

In order to add a tag to an agent we need to create our first custom activity. This one, as with all of the activities for this process are really simple. It takes the IBuildAgent variable that we just got and a string Tag that it then adds to that agent.

<span style="color: #000000;">namespace MrHinsh.TfsBuildExtensions
{
    using System;
    using System.Activities;
    using System.ComponentModel;
    using Microsoft.TeamFoundation.Build.Client;
    using Microsoft.TeamFoundation.Client;

    [BuildActivity(HostEnvironmentOption.All)]
    public sealed class BuildAgentTags : CodeActivity
    {
        [RequiredArgument]
        [Browsable(true)]
        public InArgument BuildAgent { get; set; }

        [RequiredArgument]
        [Browsable(true)]
        public InArgument Action { get; set; }

        [RequiredArgument]
        [Browsable(true)]
        public InArgument Tag { get; set; }

        protected override void Execute(CodeActivityContext context)
        {
            if (context == null)
            {
                throw new ArgumentNullException("context");
            }

            IBuildAgent buildAgent = context.GetValue(this.BuildAgent);
            TagActions action = context.GetValue(this.Action);
            String tag = context.GetValue(this.Tag);
            switch (action)
            {
                case TagActions.Add:
                    buildAgent.Tags.Add(tag);
                    break;
                case TagActions.Remove:
                    buildAgent.Tags.Remove(tag);
                    break;
                default:
                    break;
            }
        }
    }

    public enum TagActions
    {
        Add,Remove
    }
}</span>

Figure: Add a Tag to the Agent custom build activity

Once compiled and added to your custom assemblies location you can then add that new activity to your Build Workflow and configure it.

Figure: Add a Tag to the Agent workflow

We already got the BuildAgent variable from the GetBuildAgent activity and we can pass it in here. I am also choosing to use the Build Number, that we get from the BuildDetail object, to add as a Tag. This makes sure that it is unique to this execution and allows us a simple way to clean it up afterwards.

Figure: Tag added to agent

As you can see this successfully adds the Tag to the agent.

Get Machine name of the Agent

The second activity we need is to retrieve the physical server name for the agent that we are running on. We need to call into wither VMWare or HyperV to snapshot the server and for that I need to know what server to call.

This was even easier to get although it did take a little while poking at the API’s to find the right thread to pull. I had thought that I could get the server name from a property of an existing object but it was conspicuously missing. I decided that rather than trying to be difficult I would just parse it out of a URL. Simples…

<span style="color: #000000;">namespace MrHinsh.TfsBuildExtensions
{
    using System;
    using System.Activities;
    using System.ComponentModel;
    using Microsoft.TeamFoundation.Build.Client;
    using Microsoft.TeamFoundation.Client;

    [BuildActivity(HostEnvironmentOption.All)]
    public sealed class GetBuildAgentMachineName : CodeActivity
    {
        [RequiredArgument]
        [Browsable(true)]
        public InArgument BuildAgent { get; set; }

        [RequiredArgument]
        [Browsable(true)]
        public OutArgument AgentMachineName { get; set; }

        protected override void Execute(CodeActivityContext context)
        {
            if (context == null)
            {
                throw new ArgumentNullException("context");
            }
            IBuildAgent buildAgent = context.GetValue(this.BuildAgent);
            context.SetValue(this.AgentMachineName, buildAgent.Url.Host);
        }
    }
}
</span>

Figure: Get Machine name of the Agent custom activity

You can see that I am just using the build agent object and parsing the servers host name from the URL. This seemed a lot easier than using any of the other methods that I could think of and even after spelunking the API’s for a few hours I could not find a better approach.

Figure: URL from Build Configuration page of TFS Administration Console

This will give me the fully qualified name of the server as it is configured in the Build Configuration of the TFS Administration Console on the Build Agent server.

Figure: Get Machine name of the Agent workflow config

Again I am using the BuildAgent object and passing back the value as AgentMachineName to a variable that I can use outside of the scope of the “Reserve on Agent” sequence.

Run on Reserved Agent

Rather than creating something custom we really want to hook into what is already there. When you configured a build you were able to define some information on what agent to select and run on. In this configuration you were able to select things like Agent Name and Tags to filter by.

Figure: Selecting the Agent Settings

Using Agent Name will not provide us any value as we do not want another build to snag this agent but instead to ignore it. To do that we need to set the “Tag Comparison Operator” to “MatchExactly” and make sure that only the agents we want have the desired Tag set. In this case it is NONE. With no tags added this build should select any agent with no tags and ignore agents that have even tags.

So when we execute the first agent scope above our agent will be selected and we harvest the name and add a tag that is the same as the build number. Now all we need to do is update the Agent Settings above to include a tag that is the same as the build name and the second Agent Scope with only be able to choose our tagged Agent. And for that we need another custom Activity.

<span style="color: #000000;">namespace MrHinsh.TfsBuildExtensions
{
    using System;
    using System.Activities;
    using System.ComponentModel;
    using Microsoft.TeamFoundation.Build.Client;
    using Microsoft.TeamFoundation.Client;
    using Microsoft.TeamFoundation.Build.Workflow.Activities;

    [BuildActivity(HostEnvironmentOption.All)]
    public sealed class AgentSettingsTags : CodeActivity
    {
        [RequiredArgument]
        [Browsable(true)]
        public InArgument AgentSettings { get; set; }

        [RequiredArgument]
        [Browsable(true)]
        public InArgument Action { get; set; }

        [RequiredArgument]
        [Browsable(true)]
        public InArgument Tag { get; set; }

        protected override void Execute(CodeActivityContext context)
        {
            if (context == null)
            {
                throw new ArgumentNullException("context");
            }
            AgentSettings agentSettings = context.GetValue(this.AgentSettings);
            TagActions action = context.GetValue(this.Action);
            String tag = context.GetValue(this.Tag);
            switch (action)
            {
                case TagActions.Add:
                    agentSettings.Tags.Add(tag);
                    break;
                case TagActions.Remove:
                    agentSettings.Tags.Remove(tag);
                    break;
                default:
                    break;
            }
        }
    }
}
</span>

Figure: Add Tag to Agent Settings custom activity

All this code does is take the Agent Settings object and add a tag to make sure that we get the right agent the second time through the AgentScope.

Figure: Add Tag to Agent Settings Workflow

So we just pass the AgentSettings object and feed it the same build number that we used before as the tag. Now we can only get this agent to “Match Exactly” and thus the build should run on this agent.

Reset the Reservation

And to reset the reservation all that needs to be done is to remove that tag from the agent. For this activity we just set the “Action” attribute to be “Remove” and we remove the tag of the build name and free up the Agent for other builds. It is worth noting that if a build is cancelled then you may need a separate clean-up routine that runs and un-reserves machines that are reserved due to failed or stopped builds.

Conclusion

This process while requiring the customisation of your build process can allow you to do a bunch of things with your build server that you may not want to enshrine in it. You may want to do the snapshot and revert not because your developers are breaking the build, but because you want to start with a clean build machine each time to test your install process as well.

Figure: Successfully reserved agent and then used same agent

If we are trying to achieve “configuration as code” then we need to be installing all of our pre-requisites with our build script.

Published at Where Technology Meets Teamwork with permission of Martin Hinshelwood, Senior ALM Consultant. (source)

Northwest Cadence can help you implement a modern application life-cycle. Call rick.flath@nwcadence.com today to help you get there more easily...

Interested in using Lab Manager with SCVMM? Not sure how to test your installation? Check out the demo below!  Using Standard Environments is fairly straightforward, but we’ve seen many people have challenges validating that they have a correct Lab Management infrastructure when using a System Center Virtual Machine Manager (SCVMM).

In this Lab Manager demo, Steven Borg will cover several components in Lab Center, how a minimal architecture is defined for a SCVMM implementation, and how to verify that all the pieces are working effectively together.  This speedy demo also includes a quick walk through the basics around the Lab Manager Build Template and how to use a Team Build to create a simple environment build test.

For questions about this demo, please contact Northwest Cadence at clientservices@nwcadence.com. 

Northwest Cadence can help you implement a modern application life-cycle. Call rick.flath@nwcadence.com today to help you get there more easily...

The Octopack does not auto generate a version number that is the same as the TFS Team Build number for a .nupkg package.

Applies to

• Team Foundation Server 2012 (TFS)
• NuGet
• Octopack

Prerequisite

Have a Octopack installed in the application.

Solution

In the default team build definition template | Open the Run MSBuild for Project activity located under: 

Run on Agent > Try Compile, Test, and Associate Changesets and Work Items >  Sequence > Compile, Test, and Associate Changesets and Work Items > Try Compile and Test > Compile and Test > If BuildSettings.HasProjectsToBuild > For Each Configuration in BuildSettings.PlatformConfigurations > Try to Compile the Project >  Compile and Test for Configuration > Run MSBuild for Project

Figure 1

Right click on the Run MSBuild for Project | Select properties in the menu window

In the Run MSBuild for Project properties | Click on the CommandLineArgument eclipse button | The Expression Editor will open

Figure 2

Enter the following code | click  OK

 /p:SkipInvalidConfigurations=true {0}  /p:OctoPackPackageVersion={1}

Figure 3

Check-in the update to source control | Run a build where Octopack is installed

The .nupkg will have the same name and build number as the Team Build

Figure 4

Conclusion

Using the above method will allow you to add global types of MS Build arguments in a default build template.  You can also mask a user name and password if you don’t want everyone to view the information.

For the Octopack and NuGet versioning you can also add the TFSVersion custom build activity. Finally, you can also use the NuGetter custom build activities if Octopack does not fit well with your project. 

Additional resources

• https://github.com/OctopusDeploy/OctoPack 
• http://nugetter.codeplex.com/ 

Northwest Cadence can help you implement a modern application life-cycle. Call rick.flath@nwcadence.com today to help you get there more easily...

You stare at the square peg, holding it next to your round hole and pursing your lips. You make a few futile efforts at mashing the peg into the hole, to no avail. Cursing the peg for its square-ness and never considering why it is square in the first place, you pull out a knife and begin to whittle away at the peg. After several hours, a small amount of blood and a large amount of sweat you hold the peg up to the light. Perfect. You insert the peg slowly into the hole, and … NOOOOOOOOOOOOO…

There are a few situations where the blood and sweat invested in the previous process are entirely justified. If, for instance, you lived in a world where there were only square pegs, and every hole was required by pain of death to be created round.

You see, initially, you had a tool. That tool helped you with a particular process. Now you’ve got a new, modern tool. But instead of letting the modern tool help you transition to a modern process, you insist on attempting to force the modern tool to work within the context of your antiquated process.

So before you spend the next week customizing your shiny new tool, stop, and consider the underlying process you’re codifying into eternal law. You might just find that you can’t really remember why that hole is square in the first place.

Northwest Cadence can help you implement a modern application life-cycle. Call rick.flath@nwcadence.com today to help you get there more easily...

In the modern application lifecycle one of the key messages is one of quality enablement. Quality will be the key differentiator between you and your competitors over the next few years and the old excuses are just that… old.

All companies are now software companies and require more and more to deliver software that is a level of quality that wows your users. Gone are the days when your employees have access to better technology in the office as they are now way ahead at home and upgrading at a faster pace. As this technology has infiltrated the home, the expectations of the consumers (your customers or employees) has increased.

This new level of expectation have added more attributes to the qualities required of even your internal line-of-business applications. Users now expect that you can deliver usable, high-quality applications that work on any platform. This is the new normal for software development and we need to rise to meet it…

Figure: Quality Enablement means continuous quality for modern business applications

In order to achieve this goal we need to stop testing only at the end of our release cycle and start to test continuously and repeatedly to enable the quality levels that we need. We need to change our practices, and we need better tools to help. Visual Studio 2012 is a great tool for this…

Continuous brand differentiation in quality enablement

You must continuously differentiate your brand in order to compete in the marketplace and to do that you must continuously satisfy consumers whether they are customers or employees … and to do that without crashing and burning you must have a solid quality foundation…

Figure: Modern business applications require continuous quality

The quality of your inventory control systems will denote how quickly and efficiently you can serve your consumers and if your customer care team doesn’t have the caller’s information on hand, how does that make your consumer feel?

Systems of engagement in quality enablement

Your systems of engagement are just that: those systems through which your consumers engage with your organization’s data. These could be awesome Twitter application that you sell through the Windows Store, or it could be your call centre management system that your customer representatives use to view customer data. Many companies assume that your internal applications are just line-of-business but when they fail it is your customers that feel the pain…

I don’t know how many times I have spoken to a sales representative, either in store or over the phone to hear the fateful phrases “the systems are running slow today”, or “there was a crash, can you call back later?”. This could be due to a fault, excessive load, or the inability of the operator to use it properly. What about call in systems that ask you for your account numbers to get in the queue, only to be asked again when you talk to a representative. These are all deficiencies in the quality of the software that is being delivered.

Systems of record in quality enablement

The places where you store your single point of truth for your data would be considered your “systems of record” and while users do not directly, or should not, interact with them, they do use the services that they provide. You must be able to deliver updates to your systems of record without breaking your engagement systems and even if these engagement system are not primarily software, this is where you are a software company whether you like it or not. This is one of the core issues that your organization will need to solve in order to increase quality in response to the changes in modern applications and delivery.

In the last 5 years the consumers of our technology have been asking more of us. Modern applications are demanding, and our previous systems of delivery aren’t enough to meet that demand, we need a modern application lifecycle too.

Continuous value delivery with modern business applications

In order to be successful at delivering value to the business we know that we need to deliver more frequently. This allows for the business to apply corrective action as needed without interfering in the delivery process.

Figure: Continuous value delivery with modern business applications

In order to be successful at delivering value to the business we know that we need to deliver more frequently. This allows for the business to correct our course as we go and us to build a better product that more closely matches their needs.

Let’s also note that this is not strictly speaking of an agile diagram. If you go round this loop in 2 years then it is not agile… If you go round in more frequent iterations it may be Spiral or Iterative. Only once you get this cycle down to 30 days or less can you consider it truly agile…

…why does that matter?

Well, the modern applications we’ve been talking about are not systems where you can get away with updating them every few years or even yearly. The new normal is really quarterly at a minimum, right, and probably shrinking. Modern app users are not going to wait around for months for a new feature. So whether you call it agile or something else, the point is, your process needs to be nimble enough to support these more frequent release cycles. Conventional thinking and scheduling will not do.

Figure: Conventional QA in the modern application lifecycle

In a conventional model you would leave QA, UAT, and operations verification until you have complete development. Unfortunately this results in:

• Rework of development efforts long after the developer has forgotten how that part of the system works
• Unmet user expectations as users see for the first time things that it is too late to change
• Increased costs as operations teams find performance and deployment issues to late in the game

Ultimately this results in an enormous increase in the cycle time for delivery and most often result in late delivery. We buffer for rework that we think we will get, but we are mostly wrong.

Quality enablement

Modern applications are delivered continuously and as such you need to practice continuous delivery to build them. In order to begin to deliver continuously we need to discern how to enable the level of quality that we need to achieve for our software. The ideas behind quality enablement are simple.

Find and fix problems as close as possible to the time that they are created. Accept that acceptance testing is a continuous activity, it starts when the original product or features are imagined and it continues throughout the lifecycle, not just at the end.

This includes problems encountered when testing, building, packaging and deploying in addition to identifying defects from either poorly met requirements, or poorly met expectations.

Figure: Continuous quality for continuous value delivery

There are four key areas that we need to look at to enable our ability to continually deliver high quality working software: acceptance test planning, continuous acceptance testing, testing in production. & reducing mean-time-to-resolution.

Figure: Acceptance test planning for quality Enablement

The thing that results in more unmet user expectations than any other single thing is poorly defined requirements. If you are going to succeed at building software you need actionable requirements. While you should consider your backlog of work under lean inventory control you still need firm requirements for your development team to work from. This doesn’t mean you write longer and denser specs that no one reads. Instead it means you engage with stakeholders and constantly check, re-check, get their feedback, and show them small samples, you do this as a continuous cycle of feedback and responsiveness.

There are many inputs to actionable requirements and you need to consider not just quality and operations requirements but the goal that your business has. This should be represented in a list of actionable requirements but does not end there. Your requirements are now actionable to the point of being able to break them down into acceptance criteria.

Building out tight acceptance criteria, usually in the Given->When->Then model helps you elicit more actionable details to your requirements and gives you an acceptance test plan. That is if you have a short measurable checklist for things that if you fulfill them the customer will accept that you have completed it correctly. This effectively brings User Acceptance Testing (UAT) inside of the continuous quality circle.

Figure: Continuous acceptance testing for quality enablement

So now that we have acceptance criteria we really want to turn them into something that we can execute. This can be done at various levels and certainly at the user interface level it would initially consist of manual testing. But as we build our software and add more features we need to both make sure that we have implanted the correct features and that we have not broken something that we have already delivered. This is hard and time-consuming as it means that we need to be continuously checking our acceptance criteria again and again to be sure. This will increase our cycle time as we move forward if we are adding tens of additional acceptance criteria for each integration. The only way, short of guessing which to run when we hit time constraints, to continuously run our acceptance criteria is to continuously automate them.

On each pass through our cycle we should have all of our tests automated. If we are working against our services, perhaps practicing Test Driven Development (TDD), we are likely starting with automated tests written in a unit testing framework. These tests would consist of unit tests, integration tests, and performance / load tests which are likely already automated. Once we start testing the user interface thing get a little more complicated and creating and managing tests and test cases get a little more difficult but regardless, if we don’t automate those tests as well we will end up with an unreasonable and unsustainable burden on our testers.

Just like putting coders under pressure to deliver forces them to increasingly reduce quality to meet the deadline, so putting testers under pressure will encourage them to repeatedly and consistently reduce the breadth of your test coverage.

To make matters worse it is not just the time for testers to execute the tests that impacts on the ability to enable continuous quality but it is also the time it takes to build and deploy your software…

Figure: Virtual lab automation for quality enablement

Whatever types of automation you create will all be for naught if you don’t have an automated deployment. And for automated deployment to work we need to have some sort of automated virtual labs so that we can dynamically spin up pre-configured environments to somewhere.

• Virtual labs in the modern application lifecycle

We need to be able to quickly and easily provision environments for development, testing, and fault reproduction in a consistent and automated manor. The time that this saves can be calculated using the Null Build technique which will show you just how much of your cycle time you are burning with deployments and configuration.

I learned about null builds from Brian Harry. A null build is a process by which you measure how long it takes you to deploy from source code. Immediately following a successfully deployment to production, create a new build of the same code and do it again. This time measuring how long it takes and where it gets hung up.

Figure: Testing in production for quality enablement

Even once we get to production we do not stop applying Application Lifecycle Management processes. We need feedback on our application and that comes from two main sources once we hit production; consumers and supporters. Once we get our completed increment of software in front of our users and stakeholders we can then get real world feedback that allows us to reconcile our backlog with what they now need. In addition our support organization are monitoring the health of our software and provide the same service to the non-functional aspects of our software.

This can only be done in production.

Figure: Mean time to resolution with Quality Enablement

How quickly can you fix bugs? The quicker that a bug is found, diagnosed and fixed the cheaper it is to fix so the mean time to resolution directly relates to cost of maintenances. But more than that it directly related to your consumers’ satisfaction. Ideally you want to be able to escalate directly from your incident management software to your development tools as well as include actionable diagnostics with the report. You don’t want to give developers access to production so we need enough information to reproduce the problem or at least understand the issue.

In addition, whatever the result we need to make sure that that issue once fixed never rears its ugly head again.

Figure: The business value of quality enablement

So now that we understand what quality enablement means, the impact to our software, our teams and potentially our organization, what do we get?

Quality Enablement: What have you done for me lately?

So what do you get?

Well, it is much easier to get to the root of what the business requires when you are able to show them something working now and to have their involvement as you deliver continuous value. As you loop round your cycle at least every 30 days working with the consumers of your application we are able to correct or even change the course of your requirements to achieve a more tailored solution to the objectives of the business.

With the short delivery cycle with smaller changes that your consumer is able to assimilate frequently you are able to get your efforts, the things that you are building, into the hands of your consumers much more quickly. This the results in much higher satisfaction from all of you consumers and stakeholders as they can not only see what you are doing, but give you suggestions and feedback that you can quickly iterate on.

The resulting reduction of cost is directly attributed to the increased quality in your software. Not only do you more closely meet the needs, so less rework, but you also have fewer defects in production so less of those expensive maintenance costs.

Figure: Measure for quality enablement

And now that we know what we get and we want it… how do we measure where we are in this process? How do we know whether it is working?

The first thing that we can measure is value delivered to our business. For every requirement that you deliver you should have a “value” figure. This can be in dollars or time, but is often a relative value estimate. Just as we will be asking your development teams to create relative effort estimates, so that we can gauge how many things that they can achieve, your business can do relative value estimates to give you an idea how you might order items on a backlog. If you are ordering items by value or ROI (value / effort) then you will quickly see the most relevant requirements float to the top. This will help you reduce the cycle time on your releases as you can stop when there is no longer enough ROI in the backlog to continue with the project.

Measuring how long it takes, on average, to deliver a single unit of work can help you identify places in your software where things are overly complex or places where your process can be improved to help reduce that number. If it takes two weeks for a tester to get to something that the coders built, or to verify a bug then this gives us an idea of where to focus our improvement efforts and how well we are doing.

In addition we want to look at the numbers of defects being found and fixed. There should be fewer defects found over time not more. If there are more defects being found then you may be looking at a reduction in quality (or an increase in the skill of your testers) and whatever the reason it will help you focus on quality.

All of this goes to reducing the amount of rework and thus reducing the cost.

Figure: Solution characteristics in quality enablement

In order to solve the problems that I am sure you have been envisaging throughout, we need tools to help manage some of the complexities around continuous quality practices and the work that we have to do to achieve them.

To do this we need tools that are tailored specifically for the types of user (their role) that will be using them. You don’t really want your business users to have to learn your development IDE tools, do you?

They need to be extensible because there is no way that any one company can provide you the tools to solve all of your problems, but we still want our problems to be solved. Above all we need to have a toolset that supports any conceivable platform that we might be developing for…

Figure: Solution architecture requirements for Quality Enablement

At a high level we are talking about having a set of tools that are tailored for all of your roles that are on a unified set of services that includes the ability to connect to any platform…

Figure: Solution architecture for quality enablement

… And if we delve in deeper into the roles actions and requirements we can start to build a profile of what is required, and its complex… we could build this by knitting together a plethora of open source tools and building custom integration between them…or we could find a single unified Application Lifecycle Management solution that does it all…

Where might we find one of those [looks confused and rub chin]….

The Microsoft Solution

For the last seven years Microsoft has been working on a system that embodies that quality enablement.

Figure: The Microsoft solution for quality enablement

Microsoft Team Foundation Server (on-premises) and Team Foundation Service (cloud) services are the backbone that provides features for both Windows and Java clients.

For each hat that your users may wear that equates to roles there are separate tailored tools that allow then to interact with Team Foundation Services in a way that is specific to their role.

Figure: Differentiation for quality enablement

With these continuous quality practices, coupled with tools that are tailored for each role we are able to more easily and effectively achieve continuous value delivery at least every 30 days.

Northwest Cadence can help you implement a modern application life-cycle. Call rick.flath@nwcadence.com today to help you get there more easily...

If you have been in the software industry for any length of time, you have heard or even experienced release management practices – the good, the bad, and the ugly.

If you are new to release management practices, it’s the “art” of building and deploying software into a consumer type of environment (yes, release management is an art).

In the words of Wikipedia: “release management is the process of managing software releases from development stage to software release. It is a relatively new but rapidly growing discipline within software engineering”.

The art of release management

I call release management an art because the build and delivery of software might sound simple, but it is not. The coordination of teams, tracking of build versions, and transparency of releases is not for the faint of heart. There is no “cookie cutter” way to achieve a well define and smooth workflow for all teams to follow. The release management process is always in a state of continual improvement. 

Why do we need release management?

If release management is so difficult why do we need it?  What benefits will come from the effort? Although it is not easy to implement in any organization the benefits of release management and DevOps out weight the effort and cost substantially. The more important questions to ask are:

• What is the cost for your production system to be down due to a rogue release or change?
• What is the cost of wait-time for Operations to release a new feature into production?
• What is the cost of not having transparency of which software version has been deployed to an environment?
• What is the hidden cost of non-collaboration between teams?
• What is the risk factor of manual steps for a release?

It’s about the risk

Release management is all about risk management.

Most companies use some type of agile practices for development and testing. In non-release management there tens to be iteration/sprint cycle-time of 2-4 weeks, along with a large amount of risk in the build, testing, and release process. As the development team create more features at a faster cadence, the release process (and testing) can become a bottleneck.

To make the release process go faster and meet the teams improved cycle-time, the “throw it over the fence” technique is usually used, as in “I’m done and it now over to Ops to deliver it into production”. This non-release management technique often creates even more risk, confusion, and is just plain bad!

As agile pushes the release management to build, deploy, and test faster through each environment, it normally stop short of the great barrier called, Operations.  Which is the most costly of the environments for uncertainty and bad practices to live. 

Those “Ops” people

What is wrong with those Ops people! Don’t they understand we need to get this simple feature out to production?  Why are they so paranoid and tend to over react to everything? 

There seems to be an ageless battle, Development does not understand Ops and Ops wishes Development would quit breaking production.

My recent favorite quote that sums up Ops view for Development is from The Phoenix Project: “show me a developer who isn’t crashing a production system, and I’ll show you one who can’t fog a mirror. Or more likely, is on vacation”.

The statement comes from a lack of trust between the two teams. And, from developer’s asking for access into production, while promising they will not break anything.  

Here is a link to a great summary of what sometimes happens when Ops gives a developer access to production (this is from a very funny blog post titled “Pictures from a developer’s life” that is worth a visit).

Ops’ main job is to protect production and keep it running. Often they feel that it is a full time job just to defend the production system from “script kitties”, developers who try new commands as they learn them, and the internal threats of just making a small change while “looking around”.

Is it any wonder why Ops people are paranoid? Everyone is out to get the production system!  Their main job is to protect production and keep it running.

Bridging the development and Ops gap

This is where release management helps. It bridges the gap and reduces the paranoia of Ops,  by using logical policies and reducing the uncertainty of a release and changes.

Transparency is key! The “throw it over the wall” technique gets replace with a known, transparent process. All of the teams can see what version of the software is in an environment and if a feature is ready for a production release. In short the risk in building, deploying, and testing software is reduced.

The “what, when, why, and how” is what Ops is looking for. Knowing this helps them find and fix issues quickly when something goes wrong. In addition, the development and testing teams benefit by having a reliable, repeatable, fast build and deployment system, which is critical to building quality software as features become more complex or cycle-time increases.

Release management benefits:

• Efficiency  – Reducing the time it takes to find, fix, and deliver reliable, quality software.
• Productivity – Teams can focus on more important items then trying to figure out what version or steps have caused an outage.
• Reducing risk –The ability to identify the what, when, where, and how for a release.
• Collaboration between teams – Opening a platform for the team to discuss blocking issues by using definite and transparent processes.
• Configuration management – Knowing what environment setting, application requirements, and dependences exist in the production, test, and development environments.

Even a small positive change to any one of these areas can greatly improve a team’s ability to deliver quality software to the customer. 

The other change is a faster feedback loop. This is achieved by not having to spend time sloughing through what caused the environment to break or which build the bug came from.

Not having to be in “firefighting” mode and the “patch and pray” policy, the team’s ability to focus on continues improvements and opportunities are greatly increased.  Not to mention the reliable, continuous delivery that all customers expect today! 

Continuous improvement with release management

Creating, building, and delivering quality product to our customer base is the goal, as well as being agile enough to react to opportunities and changes in our industries is required.

This is why we apply continuous improvement to our team. We, as professionals, naturally strive to do better and improve, as should our software development practices.

Release management is a part of that continuous improvement model. Creating and refining a logical process to delivering products to customers in a fast reliable cycle is one important way we keep our customer and improve our customer base.

With faster cycles of software features being released, it is very costly to not have a solid release management or DevOps process. Release management helps bridge the gap between development and Ops. It breaks down the “us against them” factor and replaces it with the knowledge that we are all involved in the improvement process. Not using a release management strategy has its own internal cost that are not seen and rarely measured.  Having high risk releases does not allow for teams to be agile or perform delivery and improvements that drive new innovations and quality into your software product.

What is next

Now that I have pointed out the reasons for release management in your software development process, it’s time to invest in the tools to create the infrastructure and workflow for all teams to use. Managed rollouts are not easy but very few things of worth are easy to obtain. In my next blog post I will cover some tools and techniques that will help you build your release management strategy.

My co-worker Martin Hinshelwood has also written a blog post covering  Release Management with Team Foundation Server 2012, which covers the process and the tools (and is simply a good read ). 

Other recommended resources:

• The Phoenix Project
• Beyond Agile: Tales of Continuous Improvement
• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Wrapping it all up in 12 steps

If you simply skipped to the bottom and did not read the above sections, below is the summary of the benefits of release management and having a DevOps practice: 

1. Release management improves your team’s ability to produce quality software with faster feedback and shorter delivery cycles.
2. The Ops team will stop giving you the “stink eye” when you ask them about the release night. 
3. Ops needs to be involved in the iteration/sprint and there should be no surprises.
4. Confidence in the fact that the next release has been tested and not simply “thrown over the wall”.
5. The hidden cost of low morale, late night bug fixing, and the blame-game.
6. Transparency into the what, when, where, and how.
7. Resolving configuration management issues between environments.
8. Drive quality in software development.
9. Faster more reliable and repeatable releases.
10. Getting your team out of the “firefighting” mode and the “patch and pray” practice.
11. Breaking down the team barriers and improving awareness across teams.
12. The ability and opportunity to reach continuous improvement and delivery for the whole organization.

Northwest Cadence can help you implement a modern application life-cycle. Call rick.flath@nwcadence.com today to help you get there more easily...

Even the term “vertical slice”, a common stumbling block in agile adoption, kinda implies a large-scale n-tier application. Modern architectures and agile can play nicer together than that!

“Story sizing”, decomposition, vertical slice of functionality, Minimally Marketable Feature (MMF), Minimally Viable Feature (MVF), and my personal least-favorite, Potentially Shippable Product Increment (POS*). I think it’s the biggest hurdle for orgs moving from not-agile to agile. I think many other problems with initial adoption (estimation, timebox sizing) boil down to this one.

Every dev team I see trying to get started with this initially tries exactly the same wrong thing, usually because it’s how they’ve organized their work in their not-agile process before: they want to split things up by architectural layers, and build, let’s say, all of the database and then all of the business layer and then all of the UI.

Any time I see a sentence with “do all of… and then all of… and then all of…”, what’s that remind me of? Oh yeah: waterfall. There are reasons we devs cling to this in spite of ourselves. Maybe another post another day.

The thing is, “vertical slices” aren’t satisfying either. Every single team I’ve worked with resists and/or struggles with this for basically the same reason: the users asked us for an epic-sized feature because that’s what they want. They don’t want a slice of a feature, they want a feature. One of the cornerstones of agile is that we’re doing these short iterations in order to get feedback from users. That’s hard to do when they’re inherently unsatisfied with these ugly proto-features they don’t want (and they’re deeply alarmed when someone calls them “potentially shippable”)!

I discovered an interesting thing at one of my customers recently, though. We struggled with “vertical slices” vs. Big Database Up Front for like two days, and only then did I find out how much they’ve worked to transition their legacy LOB (line-of-business) apps into a SOA (service-oriented architecture) model: collections of beautifully loosely-coupled services and APIs (I don’t remember what it stands for) with clean interfaces talking to each other to achieve some nice user-interfaced result.

Wow! This was exactly the hook I needed. Because what is a service or an API if not a neat encapsulation of a small logically-contained bit of functionality? I realized that even the term “vertical slice” implies a traditional n-tier architecture in kind of a large-scale sense. Today’s SOA (is that still what we call it?) has already broken down those giant tiers into little slices. The team didn’t even realize they were already doing it. Each service might have its own little n tiers, but on a much smaller scale. Small is exactly what we need!

My customer got stuck trying to decompose from the epic feature level, still thinking about all the little services they’d need to assemble (plus BDUF) in order to hook up a UI and show a “vertical slice” to the user. They didn’t see their services as value in themselves, but I think the value is right there. APIs don’t have a user interface, but, um, the “I” stands for “interface”. They encapsulate something someone finds useful, and they are independently testable. Better yet, they almost demand automated testing, a practice we already wanted to reinforce. Imagine: at the iteration review, sure, the team should demo UI mockups early and often to get feature-related feedback from users… but can’t they also “demo” individual APIs (that implement underlying business capabilities and algorithms that the users do care about) by reviewing the acceptance criteria for the service and showing off a suite of automated test results to prove that the logic works?

I guess my point is that, as it always has, agile practice goes hand-in-hand with what we know about how to architect high-quality, maintainable software. I was just pleased to understand this in a new (to me) way.

* j/k. But I do hate that term.

Originally published at blog.bsktcase.com by ALM Consultant Cheryl Hammond.

Northwest Cadence can help you implement a modern application life-cycle. Call rick.flath@nwcadence.com today to help you get there more easily...

Applies to

• Team Foundation Server 2012 (TFS)
• Test Manager

Findings

How can you import Unit tests into Test Manager for BVT suite?

Solution and Steps

1) You can use the TCM command to import a Unit Test (and others) into Test Manager.

2) Build the project with Unit Test.

3) Open Developers Command Prompt for VS 2012 as Administrator | Enter the following TCM /?

4) This will give you the options to import the test into TM.

Example:

tcm testcase /import /collection:http:///tfs/NWC /teamproject:NorthwestCadence /storage:"C:\CI_Dev_BlogEngine\BlogEngine.Core.Utils.Tests.dll"

figure 1

figure 2

figure 3

figure 4

Conclusion

The Unit Tests can now be a part of the build verification testing for a nightly build in team build, lab manager, and test manager.

Additional Resources

http://msdn.microsoft.com/en-us/library/ff942470.aspx

Northwest Cadence can help you implement a modern application life-cycle. Call rick.flath@nwcadence.com today to help you get there more easily...