Richard Banks - Agile and .NET

Lean Kanban Australia Conference

2013-05-13T15:10:00.001+10:00

A number of Australian agile community people, including my colleague Steve Godbold, have decided to run a conference for Lean and Kanban approaches.

The interesting thing about this conference is that it is being funded and run using a crowd sourcing model and the organisers need to know if there's enough interest to run this thing. Of course, this means they need you to get behind it and pledge something towards it and sooner rather than later.

What do you need to do? Two things:

1. Go to http://www.pozible.com/lkanz and pledge something towards the conference
2. Spread the word.

Simple!

What’s Visual Studio’s Code Map All About?

2013-04-17T22:18:00.001+10:00

In Visual Studio 2012 Update 1 (VS 2012.1) Microsoft delivered a feature for the Ultimate edition called Code Map with the goal of visualising relationships in code.

In Visual Studio 2012 Update 2 (VS 2012.2) they’ve extended the Code Map experience to include debugging support and the ability to generate code maps on the fly as a debugging session is conducted.

If you saw the announcement then you may have had one of the following reactions. Reaction 1 would be something like “Oh. It’s in Ultimate. I don’t have it. I’ll ignore it”. The second might be similar to mine: “Is this really going to be that useful?”. After ignoring it for a bit I decided to answer that question for myself.

For the purposes of this post, I’m used the excellent RestSharp project. You can grab it from https://github.com/restsharp/RestSharp. Oh, if you’re not aware of what it does, it’s a library that help’s you build REST based client and server applications by taking away a lot of the plumbing work you would otherwise have to do.

Getting Started

To start begin by asking a simple question. How does RestSharp make a client request? I’d never looked at the internals of RestSharp before so I wasn’t sure where to look.

Fortunately RestSharp comes with a set of unit and integration tests that I could use to explore the code with. I started with the integration tests and tried to find a suitable test in there to use and came across the Handles_Non_Existent_Domain() test. That seems a reasonable place to start. Note that if you want to follow along at home you’ll need the XUnit.Net Test Runner for Visual Studio 2012 extension installed since the tests are written for xUnit.

First thing to do? Set a breakpoint on the first line of the Handles_Non_Existent_Domain() test and start debugging the test. When the breakpoint is hit open a Code Map for the debugging session by either clicking the button in the toolbar (highlighted in the screenshot), choosing Show Call Stack on Code Map from the Debug menu, or pressing Ctrl+Shift+` if you’re using the default keyboard mappings.

Visual Studio will now split the document window and display a second document pane with the code map in it. Initially the code map will looks like this:

Not very interesting, right? Don’t worry, it gets better. Let’s start stepping into various methods to see how this test works.

Stepping Deeper

Press F11 to step into the RestClient constructor. As you do, you will notice the code map updating. Continue to step through the code until the first call to AddHandler() has completed. Your Code Map should now show something like the following:

Note that as we step back up the call stack that the colours of nodes in the Code Map change to reflect that methods we have called but that are no longer in the call stack. It helps us keep track of where we’ve been, not just where we are now. This is kinda cool. I no longer have to mentally keep this tree in my head, and can focus more on what the code is doing rather than where I’ve been and which methods might be relevant later on.

Depending on your resolution, you may also start noticing the zoom level on your Code Map keeps resetting. If you want it to use a specific zoom value then go to the layout options and turn off “Automatically Layout when Debugging”

What Happens When You Skip Over Methods?

The code map only updates when execution pauses. It means that if you step over methods the Code Map will not show you what happened in the code you stepped over. It also means that if you use multiple breakpoints and after hitting the first breakpoint continue execution until you hit the next one, then the Code Map will only reflect the call stack from when the breakpoints were hit. You won’t see anything related to what happened in between breakpoints.

It helps keep the noise in the map down, and presumes that if you’ve skipped over code you’re also not interested in seeing it in the map. That seems to be a reasonable assumption to me.

Anyway, let’s get back to the test we were stepping through and continue execution until we get to the line that calls the Client.Execute() method.

As you step into the method the Code Map will update. Look at the tooltip for the newly added node and you will see details of the method itself based on XML Doc comments, as shown:

This can be handy when you’re deep within the bowels of something and can’t remember exactly how you got to where you are or which specific overload of a method was called.

If we then step into the switch statement, we see that we’re passing in a value of Method.GET. It might be handy to remember that; especially as both parts of the switch statement call Execute(). We can make a note of that on the Code Map by right clicking the node and selecting Add Comment (or hitting Ctrl+Shift+K)

At various point you’ll notice that the some calls go through external code first. The code map will reflect this when it occurs by marking the fact on the call stack arrow, as shown.

Way Down Deep

If you continue to step through the code you will eventually get to the RestSharp.Http.GetRawResponse() method and your Code Map will start to look somewhat busy, as follows:

A lot of the nodes in the Code Map are not that interesting now that we’ve stepped through things and are improving our understand of how it fits together. It’s fast becoming noise. To organise the map better we could simply select nodes we’re not interested in anymore and delete them or we can choose to group them by selecting a few, hitting the mouse right-click context menu and choosing Add Parent Group, to get something like the following:

We can then simply collapse groups to hide items we’re not really interested in at the moment.

With a little bit of judicious grouping I produced a Code Map as follows and now I have something that helps me better navigate the internals of RestSharp and get familiar with it.

Wrapping it Up

I can add to this map over time as I explore the code further and step through other tests to see how it works, I can also get a feel for which parts of the code are called often and what happens in those methods.

If I wished I could also save the code map and share it with the rest of team, or grab an image of it and post it in the team wiki for documentation purposes or put it on the wall as a reference.

While Code Maps might seem a little gimmicky at first, I’m finding them fast becoming an useful tool in helping me better understand code I’m wading through and in improving my knowledge of what exactly is happening when I’m using an application.

Give Code Maps a try (assuming you have a copy of Ultimate) and see what you think.

Confessions of a Product Owner - Scrum Australia 2013

2013-04-11T18:00:00.001+10:00

The Scrum Australia 2013 conference has just finished and I had the pleasure of delivering a session for Product Owners aimed at helping them improve what they do and identify some of the mistakes they may be making. A big thank you to those who attended and for making the session as interactive as it was.

As promised, I’m posting the slides from the session here. Just remember that the slides are an aid to the presentation and that the back half of the deck was designed for interactivity in the room, not for offline consumption. Regardless, here it is.

This is an embedded Microsoft Office presentation, powered by Office Web Apps.

Why a Short Feedback Cycle is a Good Thing

2013-04-03T10:22:00.001+11:00

n 1981, Barry Boehm published information on the cost of change in software at various stages of the development cycle. The following chart shows this cost curve:

Boehm's Cost of Change Curve – 1981

This model has historically led the industry to believe that the most important thing we can do is “get the requirements right!”. The thing is, the model above is somewhat incorrect. It assumes a traditional software development lifecycle is the only way software is built and that working software can only be used at the end of a project. With the rise of agile development techniques this is no longer true and we can deliver usable software every week or two.

Also, from the chart, consider that bottom axis – time. Time here represents the length of the feedback cycle; i.e. how long it takes to realise a problem exists and that a change is needed. Time is the critical element in determining the cost of any change. The longer we go before realising we need a change, the higher the cost of that change.
In an agile approach, the short iterations of a few weeks or less result in a much shorter feedback cycle.

Scott Ambler published the following chart on the cost of change in relation to defect correction and the point in the development cycle where that defect is detected. Again, the longer the feedback cycle the higher the cost of rectifying the problem.

Image via Scott Ambler - http://www.ambysoft.com/essays/whyAgileWorksFeedback.html

So by using Scrum and putting in place good engineering practices alongside a short feedback cycle we establish a number of mechanisms that help us rapidly detect mistakes in both requirements and their implementation. This in turn allows us to take corrective action and fix the problem while it is still cost effective for us to do so.

In the end, this helps us keep our application quality high and provides better value to our end users and customers.

I’m speaking at the Scrum Australia conference this April

2013-02-18T07:17:00.001+11:00

The inaugural Scrum Australia conference is on in Sydney this April and I’ll be there, speaking about the mistakes Product Owners tend to make. if that doesn’t interest you then fear not, as there’s plenty of other great content being delivered. Don’t believe me? Just have a look at the schedule. There’s even an open space event for making sure you get to talk with other people about topics that specifically interest you.

This should be a great conference so talk to work and arrange some time out so you can get along on April 11 and 12. I’ll see you there!

Git is now an option for TFS Source Control

2013-01-31T06:50:00.001+11:00

Yes, it’s true. Hell has frozen over!

After much waiting the TFS team have today announced that Git is a fully supported source control choice for TFS, and that Visual Studio 2012 now has tooling available for working with Git repositories, built right into the VS shell. I know, right?! Oh, and it’s not some Microsoft half baked git like implementation, it’s the full thing.

Here’s the announcement on Brian Harry’s blog: http://blogs.msdn.com/b/bharry/archive/2013/01/30/git-init-vs.aspx

And here’s a quick getting started post on the VSALM team blog: http://blogs.msdn.com/b/visualstudioalm/archive/2013/01/30/getting-started-with-git-in-visual-studio-and-team-foundation-service.aspx

So what’s stopping you? If you haven’t already created an account on http://tfs.visualstudio.com then get to it. Download the bits for VS2012, create yourself a team project with Git as your source control provider and see what it’s like.

P.S. In case you’ve forgotten, for those using a TFS server with the standard version control system, you can use Git-Tf to put a local git repository in front of it.

A Scrum Reading List

2013-01-25T10:29:00.001+11:00

When I run one of my Scrum.org classes I’ll often mention various books that I’ve found useful and students will typically jot down those book names for looking up later. When one of the students in a class I did recently asked for links to all the books I mentioned I thought to myself “Why didn’t I have that list handy?” So, after that #facepalm feeling passed I organised myself and put together an Amazon ListMania list for future reference. Here it is for your perusal.

Richard’s Scrum Reading List

Enjoy!

Oh dear. Another Waterfall #FAIL…. to the sum of $1.3 Billion

2013-01-22T09:31:00.001+11:00

Have a read of this article on the NYTimes - http://www.nytimes.com/2012/12/09/technology/air-force-stumbles-over-software-modernization-project.html about a failed US Air Force project. Failed to the cost of US$1.3 Billion, 6 years and with nothing to show for it. Nada. Zip. Diddly squat. Zero.

Take a few moments to get over that sick feeling you have in your stomach and then ask yourself “When will people learn?”

I’m still shaking my head over this article. And more so over statements like “did not succeed in imposing the short deadlines of 18 to 24 months”. 2 years is short? Seriously?

What about this; “We’ve never tried to change all the processes, tools and languages of all 250,000 people in our business at once”? Or this; “We started with a Big Bang approach and put every possible requirement into the program, which made it very large and very complex,”. It appears people still haven’t learned that the only thing you will likely get from a big bang approach is a loud explosion, lots of smoke and debris and, if people are involved, there’s usually plenty of blood on the walls. There’s always people involved.

Unfortunately I know of far too many projects right now that are still taking the big bang approach and hoping it will work. Note that key word there – “hoping”. Hope, as one of my former CEO’s used to love to say, Hope is not a business strategy.

Companies should be learning the painful lessons of other organisation’s #FAILs and taking on more agile approaches. Steve Denning has put together an interesting write up of the whole fiasco and the organisational impediments that prevented such an approach from being undertaken let alone being successful. Maybe the scale of waste in the project will be just the catalyst the military needs to genuinely improve, and maybe people will learn that COTS like Oracle or SAP or any of those consulting-ware packages combined with old-school systems integrators like CSC really aren’t worth the money they charge. Then again, maybe not. #sigh

//BUILD 2012 Wrap Up

2012-11-06T11:38:00.001+11:00

This was an editorial for the Australian MSDN newsletter that got bumped for various reasons so I’m posting it here for your edutainment.

----

By now you’ve no doubt heard that both Windows 8 and Windows Phone 8 have been released to consumers and I’m sure many of you are looking forward to getting your hands on the exciting new Windows 8 tablets and ultrabooks or checking out the awesome new Windows Phone 8 handsets. When you do, I don’t think you’ll be disappointed!

You may also have seen that attendees at //BUILD were given a Microsoft Surface RT and a Nokia Lumia 920 to build applications for. Having used both devices extensively for the past few days you can colour me impressed! These are wonderful pieces of kit! I’ve also spent time with some of the other offerings from Microsoft’s hardware partners and these devices have some serious competition. Check out Steve Ballmer’s keynote to see some of these other devices in action.

I’m also confident that the prophets of doom in the press predicting the end of the world as we know it will be proven wrong in time. I say this because I visited one of Microsoft’s retail stores in Bellevue a number of times this week to watch how “average consumers” interacted with the new Windows offerings. The store crowded every time I visited, which was great, though my confidence comes from seeing people pick up devices with some initial trepidation, play with them for a few minutes before cracking into a grin as they got how Windows 8 worked and then handing over their cash and walking out of the store with newly purchased devices!

What this means is that the consumer demand is here, now and it’s huge! The question you need to ask yourself now is “what apps can I build to meet that demand?”. You already have the development skills you need; just learn the specifics of building Windows Store and/or Windows Phone apps and you’re all set to go. Nothing is stopping you.

Oh, that isn’t all that has happened this week either. There have been a slew of announcements from the ‘other’ Windows (Azure). Windows Azure web sites now support .NET 4.5, there are updates to Windows Azure Mobile Services, the Azure hosted Team Foundation Service has RTM’ed and it was announced that Halo 4 will be using Azure to scale out and meet the demands of the millions of gamers all wanting to frag each other.

This week the Windows ecosystem has taken an evolutionary leap forward and the future is bright so if you haven’t already done so, go and check out the session recordings at Channel 9 and then get started building great apps for both Windows 8 and Windows Phone 8 today.

Finally, if you want learn about building modern apps using Visual Studio 2012 tooling then you should definitely check out the Microsoft and Readify Modern Apps, Modern Processes road show happening this month.

Happy coding!

Where are all the new desktop keyboards for Windows 8?

2012-09-27T09:52:00.001+10:00

With Windows 8 being RTM’ed and a slew of new devices to be launched on October 26 (just a few weeks away) I can’t help but wonder where the new keyboards are. Sure, Microsoft has announced some new keyboards and mice, but they’re not gesture enables and have no charm keys on them. The keyboard is just a fairly standard keyboard with the new Windows logo on it. Boring!

I was expecting something to be announced that supports the touch style gestures and the Windows 8 Charms. The Logitech K400 is has potential with it’s inbuilt touchpad but is still missing the key elements.

So, what do I want on my keyboard?

Firstly, I want the charms on my keyboard, mirroring what’s on screen. Sure, I can press Win+C just like everyone else, but I’d rather a single key press. I’m lazy.

I also want a mini-display on my keyboard that mirrors my current display so I can do swipes, pinch and zoom, and so on simply by using gestures on the in-keyboard display instead of reaching out across my desk to touch the screen and looking like a fool. Plus too much of that and I’d get a tired arm.

I want something a little like this and I’m willing to pay for it:

Maybe something has already been announced, but if so I can’t find it.

UPDATE

I just came across the DeathStalker keyboard from Razer. This looks really promising. Here’s the main thing that could make it work – the Switchblade UI. I could definitely see the charm keys up along the top of the trackpad and the trackpad itself looks like it has the display and multitouch capabilities sorted already. Looks like all we need is a Windows 8 app written for it. Does anyone have some rock hard C++ skills? :-)

HATEOAS? Surely we can come up with a better acronym!

2012-09-13T21:42:00.001+10:00

Today on twitter I mentioned that a class I was teaching REST to was having trouble with the HATEOAS acronym and what it was all about.

For reference HATEOAS stands for Hypermedia As The Engine Of Application State. The concept that an application’s state is in the hypermedia sent between client and server and that both the client and server themselves are stateless.

The awesome Paul Batum responded with this:

I completely agree with his sentiments and for that reason I’m proposing a new acronym. This one is a TLA, and one you can say! What more could you want. So here it is:

ASH – Application State in Hypermedia

What do you think? Can you come up with something better? What would you propose? Drop comment on the post and let’s see what you think.

Visual Studio 2012 Cookbook is now available

2012-09-06T10:01:00.001+10:00

I’m pleased to announce that my Visual Studio 2012 Cookbook is now available from Packt Publishing. Amazon and other distributors should have it available shortly.

As a developer you should always know how to make the most of the tools at your disposal and the Visual Studio 2012 Cookbook is a great way to reduce the learning and discovery time for your shiny new IDE. The book is a “ramp up” book that aims to quickly familiarise you with the major new features of VS2012 and assumes you have a working knowledge of a prior Visual Studio version.

Because it’s a ramp up book it won’t be for everyone, however it’s priced so it can be more time efficient to buy the e-book (or tree-book if you must) and use it to learn the new features rather than trying to find the same information by either exploring the app click by click or scouring the web looking for “what’s new” articles.

Go ahead, buy a copy today, and don’t forget to get one for your Mum as well! I’ve got starving children to feed!

Using Git-Tf with TFSPreview.com

2012-09-04T20:38:00.001+10:00

You may have noticed a few weeks back that Microsoft has released an open source project named Git-Tf which is very similar to Git-Tfs in that it allows you to have a local git repository that can push/pull from a remote TFS server.

The first question? Why would Microsoft do this if Git-Tfs already exists and does the job? The answer is pretty simple. The Git-Tfs project is windows only, and Microsoft wanted a cross platform solution so that linux, Mac/XCode developers can also put their source into TFS. Microsoft even talked to the git-tfs team first before building their own version and then open sourcing it.

One of the problems with the initial versions of git-tf was that it didn’t talk to TFSPreview.com because of the requirement to login using a Live Id. That’s all changed in recent days so here’s how to get it working:

Step 1 – Enable Basic Auth on your account

This was an update in the TFSPreview service made at the end of August that allows you to set up basic auth credentials for your account. You will need to enable it.

Go to your profile and turn it on:

Next, go to the credentials tab and enable the alternate credentials.

Step 2 – Update Git-Tf (if required)

You may need to update your git-tf version if you already have it installed. You should be running version 1.0.1.20120827 or later.

Use git tf --version to check what you are currently running and you can get the latest version from the Microsoft Downloads page.

Step 3 – Clone your repository

This is pretty simple. Simply use the git tf clone command and point it at your tfspreview account.

Here’s me cloning one of my projects

And then you’re done! You’ve now got yourself a local git repository connected to tfspreview and everything is all set to go!

Fantastic :-)

An Exercise in Analysing Estimates

2012-09-03T16:12:00.001+10:00

I’m currently coaching an organisation undergoing a Scrum implementation and we’re having some problems with velocity within teams and the consistency of estimates across teams. The teams are delivering well, but velocity is a little choppy and the teams are feeling a little blind as to their true rate of progress.

As an exercise we looked at the stories the teams sized up and took on across a few sprints, and we looked at their estimated effort for each story once they did the task breakdowns and had built their sprint backlog.

The Data

Here’s what we saw after a few sprints:

Team 1

Points	Avg Estimated Time	Standard Deviation
3	2.5	1.32
5	2.67	1.89
8	7.67	3.25
10	9.75	1.77
13	9.67	7.23
20	19.86	9.33
30	22	0

Team 2

Points	Avg Estimated Time	Standard Deviation
3	2	.71
5	8	0
8	9.5	4.69
13	23.5	16.99
20	44.67	9.29

Before you measure, understand the goal

The temptation when looking at any numbers here is to over analyse things and fall into the trap of “we need better estimates” and forget about the true aim of any Scrum Team, which is to deliver creatively and productively deliver business value to your customers.

The primary goal is always delivery! Not better estimates. The only reason we estimate in the first place is to help our product owners forecast when items are likely to be completed.

With that said, if we have bad estimates we will have bad forecasts and unhappy product owners and customers. We would like to have reasonable estimates so that we have reasonable forecasts, but not if it means we spend so much time estimating that we forget to get out there and build some awesome stuff that makes people happy.

The purpose of this exercise is to improve our understanding of the estimates we are providing, But remember, better estimates are a secondary objective and inconsequential compared to the prime objective of delivery.

When scaling, should teams have a consistent baseline?

Both teams are working on the same product, though in different areas of the product to avoid stepping on each other’s toes. Initially each time has sized the work they are doing using individual product backlogs.

Do they need to have some level of consistency between teams? Maybe – maybe not. In my customer’s case they would like that consistency because they’re having trouble knowing how long things will take and are having trouble forecasting using the velocity numbers from each team. While at the moment the teams are fairly separate, this may not always be the case and if the teams end up working on the same area of the product it would be nice to know that if Team 1 sizes something at 5 points that Team 2 would size the item at 5 points as well.

If the teams stayed distinct all the way through development, this consistency wouldn’t be required.

Cross team sizing comparison

Look at the estimated effort for a 13 point story in Team 1. It’s about 10 hours. The same 10 hours in Team 2 is an 8 point story.

Why the difference? Is it just because Team 1 is much faster than Team 2? Do they just have a higher velocity and are more awesome than the other team?

Is it because Team 2 is working on items that are harder than they estimated when they sized them?

Honestly, the numbers can’t tell you. You would have to look beyond the numbers to see what’s going on.

In the case of my customer the two teams are roughly equivalent. Same team size, roughly the same domain knowledge and skill level. As such I would expect that both teams estimating the same sized items would come out with approximately the same number of hours for the effort involved.

When that’s added to the understanding of the numbers I’m inclined to think that Team 1 is simply estimating using higher numbers than Team 2. This is not uncommon for teams starting with Scrum and learning to do sizing for themselves. As long as they stay consistent, their team velocities will cancel out any “padding” of the story points they have done.

Relative sizing is “Relative”

Now we come to the more interesting thing we can consider in the estimate statistics and the one I’m much more interested in raising the awareness of within the teams.

Firstly, no team sized any 1 or 2 point stories. This is a smell straight away for me and makes me think the team are padding their sizes. After talking to the team, I know this to be the case and it’s something they’re having to unlearn.

Next, if we consider relative sizing then the difference between a 5 point story and a 20 point story should be about 4 times.

In Team 1, a 5 point story is 2.67 hours. A 20 point story should be around 10 hours. Instead we see that 10 hours works out to be around the 13 point size and the 20 point story is about 20 hours. Almost 8 times the 5 point items.

Maybe it’s just that Team 1 didn’t use 5 as their “average” size story, but rather 8 points. Let’s see. An 8 point story is almost 8 hours. OK. So a 20 point story would be about 20 hours – not bad. However the 13 point story doesn’t fit, nor does the 5 point story.

Only 3 estimate brackets?

In fact looking at the average estimates it would that the team can only estimate in Small, Medium and Large timeframes where small is about 3 hours or less (half a day). Medium is a day (8-10 hours) and Large is 20 hours (2-3 days). Again, this is not uncommon for teams starting out and something I’ll need to work through with the teams to help improve their understanding of what they are doing so that they can inspect & adapt.

What about Team 2?

Doing the same analysis of Team 2 we see that a 5 point story is 8 hours estimated work. That means a 20 point story should be around 32 hours. Well, a 20 point story is 45 hours, it’s a difference, but not overly large..

However, the 5 and 8 point stories are fairly similar in size, so maybe the 8 is more akin to a “medium” story. 8 points is about 10 hours, give or take, so a 20 point story should be around 25 hours. Now we have a size gap of almost 50%. This is very similar to the behaviour we saw in Team 1.

Again, looking at the sizes it would appear that we have 4 obvious sizing ranges. Small, 2 hours. Medium, 8 hours, Large, 3 days and Very Large, 5-6 days.

Why didn’t Team 1 have a similar Very Large story size in their estimates? Likely because they recognized the Very Large story and broke it down into smaller items.

Why measure standard deviation?

You will have noticed that the stats have a standard deviation column. This is so we can see the volatility of the estimated effort for the various story sizes. For example the 13 point stories for Team 2 are all over the place. A standard deviation of 16 hours is very large – that’s a 2 day variation in effort and likely indicates that the team is still learning what their story points feel like in terms of effort.

DON’T ABUSE THE NUMBERS – They’re just indicators

Now that we’ve looked at these numbers, what do we do with them?

We want to use them to Inspect and Adapt; to learn how to be better than we are today, but we must remember that the numbers are just indicators. We may even be looking at numbers that are misleading. If we pay too much attention to the numbers people will start to change behaviour to make them look better. We don’t want the teams to start gaming the numbers since that would reduce visibility and transparency.

While the statistics would seem to indicate that the team do not completely understanding their requirements (the high standard deviations), or that they are padding estimates and still learning what relative sizing is all about, we cannot rely on the statistics alone.

We should take these numbers to the teams for their next retrospective and talk them through. Let’s see what the team can make of them and what steps they suggest for getting better at estimating.

Since these teams are wanting to improve, information like this can help.

Given the estimate size bandings one suggestion for the teams is to move away from story points for a time and adopt T-Shirt sizing instead. Given they have already got this with their Small/Medium/Large time breakdowns it may help them with their estimating in the short term and then we can revisit the points approach in later sprints once they have a better understanding of themselves and what they are estimating.

The final thought: It’s OK to look at your statistics. Learn from them, but don’t be ruled by them.

Do You Need Somone To Bounce Your Ideas and Problems Off?

2012-07-16T11:08:00.001+10:00

Of course you do. Everyone does.

The question is do you know who to talk to? Often the best person is someone outside of the situation you are in who can give you the perspective you don’t have and the ideas that you may not have come up with on your own.

Throughout my career leading teams there have been many times where I would’ve loved someone outside the company that I could freely talk to about what was happening and to have them poke holes in the approaches and decisions I was making, but I didn’t know who that could be.

I’ve been thinking about this scenario for a while and it’s time to do something about it. As a result I’m making myself available to technical leaders who want someone to confidentially bounce ideas off. No sales pitches, no hidden agendas. All I want is to build relationships and to genuinely help you come to the best decisions about the problems you have. I’m not going to tell you how to do your job or pretend to know all there is about the day-to-day realities of your environment but I will be someone you can chat to openly about what’s going on and what problems you are facing.

So if you’re located in Sydney and you hold some form of technical leadership role then please get in touch. The easiest way to do so is to drop me an email at richard.banks@readify.net or via twitter (@rbanks54).

I’m looking forward to having a chat with you soon!

How To Prevent Visual Studio 2012 ALL CAPS Menus!

2012-06-01T11:45:00.001+10:00

For all those people who can’t stand the ALL CAPS menus in Visual Studio 2012 there’s a way to switch them to normal casing.

Crack open your registry editor and create the following registry key and value

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\General\SuppressUppercaseConversion
REG_DWORD value: 1

Here’s what it looks like BEFORE

And here it is after the change

You’re all very welcome! Now go tell your friends

Visual Studio 2012 Cookbook

2012-04-18T11:33:00.001+10:00

I know I’ve been a little quiet lately, but with good reason; I’m writing a book :-)
Visual Studio 2012 Cookbook

Short, sharp and to the point, and affordable as well! I’ll post more details as the publishing date gets closer, but there’s nothing stopping you preordering a copy now and helping me feed my starving children!

I’m not the only one…

As it turns out, there are a number of other Aussies also writing books at the moment. You should also have a look at what they’re offering and support Australian technical authors.

David Burela just released his Silverlight 5 & Azure book: http://www.packtpub.com/microsoft-silverlight-5-enterprise-integration-on-windows-azure/book

Luke Drumm is currently finishing an XNA 4.0 book: http://www.packtpub.com/microsoft-xna-4-0-game-development-cookbook/book

Alex Mackey, Mahesh Krishnan & William Tulloch are writing a .NET 4.5 book: http://www.amazon.com/Introducing-NET-4-5-Alex-Mackey/dp/1430243325

What do I do With Partially Completed Stories in Scrum?

2012-03-15T22:16:00.001+11:00

It’s not that rare an occurrence for a scrum team to get to the end of a sprint and find that they have one or more stories that don’t meet the definition of “Done!”.

Question

This week from one of my former Professional Scrum Master students asked me about this situation:

”What should we do with un-done work at the end of the sprint?
I was thinking we have two options:
1) Move the user story to the backlog for re-prioritisation (maybe into the next sprint). The problem here is that I’m not sure what to do with the story points as it screws up our sprint velocity
2) Split the user story. In this case we would leave the old user story’s points as-is, then create a new user story with the remaining work and re-estimate with planning poker.
I was reviewing the scrum.org scrum guide and it doesn’t seem to have any details in this area.”

Answer

The lack of detail in the scrum guide should be enough indication on the approach to take. If the scrum guide doesn’t talk about splitting stories then it’s probably reasonable to assume you shouldn’t do it :-)

Putting the story back on the backlog for reprioritisation. Sure, you won’t get any credit for the story in the current sprint because it’s not done, but it won’t screw up velocity either because velocity will be a true reflection of what you actually delivered during the sprint. We want velocity to measure our rate of delivery not our effort. On average, over a number of sprints the velocity figures will average out in any case. So yes, you may well have a few peaks and troughs when looking at single sprints but looking across the last 3 to 5 sprints you should have a good reflection of your actual rate of progress.

Not having a story finished and getting no credit for it also gives the team something to talk about during the retrospective. “Why didn’t we get to ‘done’ on story X?”.

On the flip side, I don’t like splitting incomplete stories because

1. it gives teams an “out” for not finishing properly and they get credit for effort not delivery. It stops them pushing for a goal and stymies the inspect and adapt process.

2. how do you actually split the story that was almost finished? Can you split it in such a way that the work that was “almost” finished meets the “done” definition? Can you do it in such a way that your product owner is absolutely sure that the completed part of the story is Done and that their acceptance criteria are satisfied? Can you cleanly separate the business value delivered between the completed part and the incomplete part? I doubt it.

Taking an incomplete story and splitting it just to make it look like you have a stable velocity reduces transparency and hides the truth of what you can actually achieve from your product owner, your stakeholders and most importantly yourselves. Don’t do it.

The Visual Studio 11 Interface, With More Metro

2012-03-04T18:05:00.001+11:00

Without getting into the “It sucks! No, It rocks!” debate about the new user interface there are some areas that people are particularly fired up about, including the use if colons as a placeholder for menu bars.

On the Visual Studio User Voice site there’s a request to tweak the UI and go “all in” with the Metro styling borrowing from the Zune interface (an interface I happen to particularly like).

Let’s have a look at the current UI as posted on the Visual Studio teams blog entry Introducing the New Developer Experience:

Now let’s look at the proposed user interface with it’s makeover (via http://i.imgur.com/Dh0zV.png):

Not to be left as the sole alternative, here’s a slightly different take on it (via http://i.imgur.com/EWH1R.png)

I’m not campaigning for votes for the feature (and at this stage the UI is going to be mostly set in stone in any case), but what I do want to do is point out that a consistent focus on the Metro design principles makes a difference.

If you go Metro, go full metro, not some halfway house. The alternate user interfaces work in that they remove as much window chrome and scroll bar noise as possible, letting developers focus more on the content and they realise that if typography is king, then make typography king! Fix menu fonts, title fonts, and so forth and be consistent about it. By improving the typography they also managed to retain the shouty tab names in such a way that they don’t grate anywhere near as much as the current UI does. The UI also feels cleaner because the ::::: lines aren’t there adding unnecessary noise.

It’s interesting to see how much of a difference the Metro design language can actually make to a user interface, and definitely something to consider if you get asked by your users to create a Windows 7 or desktop application that feels like a Windows 8 Metro style application.

How To Unit Test Async Methods with MSTest, XUnit and VS11 Beta

2012-03-04T09:10:00.001+11:00

MSTest finally got some love with the Visual Studio 11 Beta and one of those changes was to enable tests to run asynchronously using the async and await keywords.

This is required if you want to write tests against any async methods (especially with WinRT!) but can also be used anywhere else you need to perform asynchronous operations.

Here’s a silly sample test to show you how it’s done

[TestMethod]
public async Task LoadGoogleHomePageAsync()
{
    var client = new System.Net.Http.HttpClient();
    var page = await client.GetStringAsync("www.google.com");
    Microsoft.VisualStudio.TestTools.UnitTesting.StringAssert.Contains(page, "google");
}

XUnit also supports this option as shown here:

[Xunit.Fact]
public async Task XUnitAsyncTestMethod()
{
    var c = new System.Net.Http.HttpClient();
    var result = await c.GetStringAsync("http://www.google.com");
    Xunit.Assert.Contains("google", result);
}

Be aware that if you have a testsettings file specified in the Unit Test Explorer that async tests will not work. This applies to the beta only. Apart from that everything works as expected.

Git-TFS Presentation at the 2012 MVP Summit

2012-03-03T20:43:00.001+11:00

The day before the 2012 Microsoft MVP Summit kicked off in earnest there was an MVP-to-MVP day. For those of us in the Visual Studio ALM area we had a day long series of lightning talks about all sort of TFS related subjects, making for a good and wide-ranging day.

For something different, I did a talk about git and TFS integration and how git-tfs can be used to hide many of the problems with TFS source control. Below is a slightly modified version of the slide deck I used.

I hope you find it useful.

Git TFS

View more PowerPoint from Richard Banks

Improved Unit Testing with Visual Studio 11 Beta

2012-03-03T19:59:00.001+11:00

There’s just so much new stuff in the Visual Studio 11 Beta! In fact, someone should write a book about it… Oh wait, I am! (more on that when the time is right). For now, let’s have a look at one feature that makes me so very happy: Visual Studio’s new and improved unit testing capabilities.
It’s widely recognised by those with a desire to do unit testing that there are better unit test frameworks out there than MSTest but given that Visual Studio has always been so tightly coupled with MSTest it’s always been more difficult than it should be to get other test frameworks working well in Visual Studio. The TestDriven.NET and ReSharper test runners have helped, but the integration back to visual studio was always lacking.
That all changes with the Visual Studio 11. Now it’s a case of “Use the framework that makes you happy. We don’t mind”.
You want to use XUnit? No problem!
NUnit? Easy!
MSTest (without the baggage it usually has)? Sure thing!
QUnit for JavaScript? Bring it on!
Something random that we’ve never heard of? Write an adapter and it’ll work just fine!

Dogs and Cats Living Together!

Visual Studio 11 introduced a test adapter model so that any test framework can run inside Visual Studio if there is an adapter for it. The adapter model also means that you can not only run XUnit, NUnit, or any other type of test but you can run them in the same test assembly if you really wanted to! Why? I don’t know! But you can :-)
Maybe you have a suite of MSTest tests but you also want use XUnit’s data driven test features because MSTest sucks for unit testing. You can do just that. It’s really nice.
Note: In MSTest’s favour, in this release when MSTest is used in a plain old class library for unit testing the MSTest test adapter uses a cut down, light weight version of MSTest with just the features needed for unit testing and none of the baggage that it normally comes with, making it quite usable for most unit testing needs. For most developers with an existing investment in MSTest tests they will see an improvement in performance as a result.

Pre-Requisites

Get yourself started by loading the appropriate adapter for your unit test framework from the Visual Studio Extension Manager. MSTest is already in the box so you don’t have to worry about that one. In this screen shot I’ve loaded up the XUnit, NUnit and Chutzpah test adapters.

Running Unit Tests

Create a new C# Assembly project (NOT a test project) and add the XUnit and NUnit test frameworks to your project using NuGet

You can also add a reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework so that you can do MSTest based unit tests.
Here, I’ve started by adding a simple XUnit test, then building the code and running the unit test as shown:

As you can see in the output window there is now a “Discover test started” phase where Visual Studio looks at the assemblies and determines what tests are in the system so that it can spin up the right framework and execute the tests.
The Unit Test explorer on the left shows the tests that were run, the time it took and any error information for failed tests.
In the same code I have then added MSTest and NUnit tests as shown, however at this stage I have not yet built the project – take note of the unsaved changes icon in the document tab, indicating that the project is neither saved nor built as yet:

Run Tests After Build (Almost Continuous Testing)

Continuous Testing is the idea that as you do your work all the unit tests are constantly running in the background and giving you live feedback when there are problems code by highlighting where tests have failed and where your code is broken. The immediate feedback cycle makes test driven development an even faster development process since there’s no waiting around for all the tests to run.
Visual Studio has taken a step towards this ideal with the “Run Tests After Build” option as shown in the image below. Turn that setting on and as soon as you compile your code Visual Studio will run the tests automatically on a background thread so that you don’t end up with a blocked UI and can get on with coding the next thing on your list.

If a test failed the unit test explorer goes red and it’s obvious that there’s a problem. The interesting thing is that in smaller projects the tests often run so fast that you don’t even notice them happening!

As a tip, once you’ve been using the test after build feature for a while you will probably want to stop the Output window from popping up every time you build so that you don’t have to keep closing it. You can do this in the Visual Studio Options as shown

Don’t Forget JavaScript Unit Tests!

OK, I won’t. Make sure you have the Chutzpah test adapter Visual Studio extension installed (see above).
In a standard web project include QUnit or Jasmine in your project and then create a JavaScript file for your tests. Once you have your tests written run them as you normally would and Chutzpah will do the tricky work of finding the tests and running them. Here’s a screen shot of a web project with a QUnit test in it

Conclusion

So there you have it! A brief overview of the new unit testing features in Visual Studio 11 Beta. Go and get it now and start playing with it.
Having Visual Studio automatically running your tests each time you do a build will change your development workflow for the better and keep you more focused on coding and help you stay in the mythical zone if you ever get there.
Remember that since all tests run in the background and this removes the time spent waiting for tests to finish that you can have tens of thousands of tests taking minutes to run each time and you won’t even feel a delay in your development activities. Fantastic!

Why do Developers Underestimate

2012-02-04T21:38:00.001+11:00

There’s a very funny response to a question on Quora doing the rounds at the moment. The question is “Why are software development task estimations regularly off by a factor of 2-3?”

The response (go ahead and read it) makes an analogy to hiking from San Francisco to Los Angeles to visit friends, underestimating the distance, terrain and rate of progress as well as encountering a number of impediments like the weather, colds, blisters and so forth. It’s a really good read.

It was mentioned on the Australian Alt.Net mailing list, this week and followed up with the question of “so what do we learn from it?”

Two simple lessons come to mind.

Lesson 1: It takes time to produce a reasonable estimate

On any reasonable project don’t expect to be accurate if your estimate takes you less than 5 minutes to arrive at. In the example, it’s pretty obvious that little time was spent coming up with the estimate for how long the hike might take. Once they’d decided they were going to hike, taking time to estimate how long it would take was just stealing time from actually hiking!

As developers, we allow ourselves to do this all the time. “I like to write code, I don’t like to estimate. If I get the estimate done quick then I can get back to doing what I like.”

Stop it. You’re only storing up pain for yourself down the track.

Lesson 2: Think about what might slow you down

When you estimate think about what might slow you down. Very few teams do this but it’s critical if you want to be more realistic about how long something will take.

Most developers estimate with the same approach that they test their own code. They only consider the happy path.

You can hear them in their heads saying “It takes this long to do that. And that long to do that. And … then put it all together and the estimate is X months!!”.

Very few developers then say, “so the baseline is X months. Now what is likely to slow us down?”. Yet there are so many things that can do just that.

Want a basic list? How about the following:

Have you done anything like this before? How vague are the requirements you have at the time of estimating?
How well do you know the technology you’re using? Or the design and techniques you’ll be implementing with?
How well do you know the people on your team? Are you all co-located? Can you communicate easily?
Does your team have all the skills you need to get the job done or will you have to rely on other’s being available?
How well do we know the problem you’re being asked to solve?
How well can you communicate with your customer(s)? How available will they be?
How bad are the worst people on your team and how much will they slow everyone down?
How’s team morale? Are people likely to leave mid project and take a whole lot of knowledge with them? How long would it take to replace them and get them up to speed?
How sucky is the code you’re working on?
How likely is it that people on the team will get pulled off on to other work? And how often?
If you’re estimating will you be doing the work? Or are you estimating on behalf of someone else without involving them?

That’s a starting list of things all teams should consider when estimating and all of those items should be used to take your “happy path” estimate and adjust it from there.

So next time you need to estimate something, keep these two simple lessons in mind and good luck!

Parameters: You’re Doing It Wrong!

2011-11-24T10:39:00.001+11:00

Having parameters for a method is perfectly fine however like anything, they can be used for evil. So let me give you a tip: If your code looks anything like this method signature (and I kid you not, this is a real method) then YOU”RE DOING IT WRONG!

SaveContentSetItem(ContentSetItem,String,String,Int32,Int32,Int32,Int32,DateTime,DateTime,DateTime,DateTime,
    DateTime,DateTime,DateTime ,DateTime,Boolean,Boolean,Boolean,Int32,Int32,Int32,Int32,Int32,Int32 ,Boolean,
    Boolean,Boolean,Boolean,Boolean,Single,Boolean,Boolean ,Boolean,Boolean,Boolean,Boolean,Boolean,Boolean,
    Boolean,Boolean ,Boolean,Boolean,Boolean,Boolean,Boolean,Boolean,Boolean,Boolean,
    FileLocation,String,Stream,String,FileDisplayFormat,Boolean,Stream)

Please, for the love of all things good, turn off your computer right now. Pack it in a box. Put the box in a locked safe. Put the safe in a bunker under a mountain. Seal the bunker using 40 foot thick concrete and collapse the entrance. Place a minefield and barbed wire around the bunker, and never EVER WRITE A LINE OF CODE AGAIN!

Ready Player One

2011-11-23T11:01:00.001+11:00

I wouldn’t normally mention a fiction book here as your taste for books is likely to be different to mine, however in this case I’ll make an exception. I’ve just finished reading “Ready Player One” and enjoyed it so much I read it in just 2 days whilst catching planes and trains and by skipping on sleep. It was such a good read I simply couldn’t put it down! I loved it!

Why so? Because it’s a near future, sci-fi book with a big virtual reality/gaming element that I think most geeks will love, especially those who know what an easter-egg is and those with a good knowledge of 80’s geek-, gaming- and/or pop-culture. Plus it’s got some seriously fun puzzles to try and solve before the reveal happens.

This book was also Amazon’s book of the month for August 2011, and deservedly so. Here’s the Amazon review quoted verbatim:

Amazon Best Books of the Month, August 2011: Ready Player One takes place in the not-so-distant future--the world has turned into a very bleak place, but luckily there is OASIS, a virtual reality world that is a vast online utopia. People can plug into OASIS to play, go to school, earn money, and even meet other people (or at least they can meet their avatars), and for protagonist Wade Watts it certainly beats passing the time in his grim, poverty-stricken real life. Along with millions of other world-wide citizens, Wade dreams of finding three keys left behind by James Halliday, the now-deceased creator of OASIS and the richest man to have ever lived. The keys are rumored to be hidden inside OASIS, and whoever finds them will inherit Halliday’s fortune. But Halliday has not made it easy. And there are real dangers in this virtual world. Stuffed to the gills with action, puzzles, nerdy romance, and 80s nostalgia, this high energy cyber-quest will make geeks everywhere feel like they were separated at birth from author Ernest Cline.--Chris Schluep

That review made it sound a little formulaic and it could easily have fallen into that trap, but blissfully it doesn’t. It’s a fast paced, highly entertaining, well written book and my inner geek loved each and every bit of it, especially the retro 80’s references; from Devo to AC/DC, Dungeons and Dragons to Car Wars (awesome!) and from Ferris Bueller to Family Ties.

As a bonus, this is Ernest Cline’s debut novel. If he keeps up this level of writing or, even better, improves then I can’t wait to see what he comes up with next!

P.S. In the interests of full disclosure I’ve got no affiliations with the book or author and I get no kickbacks for mentioning this book, though I wouldn’t mind if there were some, hint, hint!

If you haven’t read it, go grab it (just a suggestion) and if you have, did you enjoy as much as I did?