Beware Backlog Tunnel Vision

Many Agile techniques rely on a backlog of items to work upon. Ideally everyone would know all the items that are in the backlog, but practically this is not always possible. A typically process is to have a handful of team members groom the backlog to prioritise the order the items. The very real danger is that when a team starts working on an item they do not have a holistic picture of the backlog. Without acknowledging (rather than needing to fully understand) the future requirements the team risk making choices that will need to be redone.

The Tour Bus Example

One of my favourite Agile examples is the Band Tour Bus. A band has struck it big overnight and they need to go on tour quickly, so they need a tour bus. A waterfall model would dictate that all the requirements for the bus are fully specified, costed, prototyped, etc. When the bus is ready everyone’s forgotten about the band and many new groups have replaced them. There is no money to pay for the bus – sad times. Enter Agile, a backlog of all the features for the bus are created and it’s deemed that a basic bus will be delivered first. Hurray the band make it to their first gig, granted not in style, but they get there. Now, let’s say that part of the bands master plan requires a long tour and they need to take their families. The occupancy requirement goes from 4 to 12. Upon grooming the backlog it is decide that feature will be done 6 sprints into the development. However, the development team haven’t been told and create a lovely in-bus bathroom. Sprint 6 arrives and there is no real-estate to create the additional living quarters, disaster. How can we avoid this problem?

How to clear the blinkers

As with most things in Agile the simple solutions are often the best;

a) Grooming team review the start of the work. The grooming team have the facts, they should review the start of work to ensure there are no obvious clashes or dependencies on items in the backlog

b) Items are categorised to allow all team members to quickly search for potential dependencies. When a new item is examined the team run a quick search over the backlog.

Whilst (b) is a useful mechanism, especially for longer running projects (e.g. products) where the grooming team changes, I would always recommend at least (a). If your team only considers the narrow view of the next Sprint or the next set of work items then the project will be at a real risk of expensive re-writes.

Posted in Agile | Tagged | Leave a comment

Why TFS Online Task board is Anti-Agile

I like Visual Studio, and I like a number of things about Visual Studio Online (VSO). However, there is one part of VSO that I think I very dangerous and can easily put your Agile project at risk. What is this terrible evil? Well I’m guessing you’ve read the title so it will be of no surprise when I say, the Scrum Work Item Task Board (see https://msdn.microsoft.com/en-us/Library/vs/alm/Work/scrum/task-board?f=255&MSPPError=-2147217396).

My experience of this task board is that it leads to a complete disintegration of the Agile practice. But it looks fine, how can such an innocent artefact lead to such problems? A number of Agile practices rely on a set of key overlapping points; 1. Transparency of the work 2. Collaboration and trust 3. Exiting with completed work. When you work on an Agile solution you will have a group of people with a set of specific skills, or at least wear the hat of a specific skill. Let’s assume we have a project owner, tester and developer. I firmly believe these are the minimum roles, even if you chose to only employ one person for all of them.

When you use a non-electronic task board you will, typically, go though a process that encourages collaboration. A note representing the ‘task’ will be placed on the board and those involved will discuss the issues around it. At first the team will agree what will be delivered and, crucially, how you prove that it has been successful. A common strategy here will be that at least the owner and test team will be responsibly for delivering an automated acceptance test for the task. The development team will be involved but perhaps not so hands-on, their main interest is to ensure the task is available for them work on. I.e. it is in the developers interest to track the progress of the owner/test team. Next the roles switch, the developers will implement the task to meet the acceptance criteria. The owner/test team play a lesser role but now they are interested in ensuring that the progress of the development is kept on track. Once development finish the owner/test team will then give the final yes/no on the result. Even without a Limited Work In Progress (WIP) strategy the team are always aware of the progress of the task and that it is their collective responsibility to collaboratively complete the task. Various process methods are used to help re-enforce this but the majority come down to a simple level of communication and, importantly, participation. So back to the topic, what is the problem with the VSO (Scrum) task board?

The first problem is that VSO wants you to separate out responsibility by creating a task per person. So rather than a task move through the team members hands, each person has their own task. Now when the team meet up each person has their own, pardon the overused term, story to tell. As their individual tasks progress it is an unfortunate human trait that the teams interest in individuals tasks wanes. Worse still, when a task completes in simply finishes and is really only of interest to that person. One task finishing does not trigger the start of another. What we have now is a system that purports to be agile but is really just a system crying out for a Gantt chart.  This is not VSOs problem per se. The task board is based, or bolted onto, old Team Foundation Server (TFS) non-agile templates. I.e. the agile processes, in this case Scrum, has be coerced onto a platform that doesn’t really support it. Happily the VSO team have working hard and have recently allowed more customisations that may offer a way out. Also this blog has been focused solely on VSOs Scrum process, you could choose Kanban instead. Whatever you choose, you should consider what are the human ramifications. Also try to keep the team, as a whole, focused on the progress of the work. It is everyone’s responsibility to deliver the work, that only ends when it is delivered. Ok, even that’s not strictly true, but lets keep those worms in the tin for now.

Be very careful of VSO Work Items, don’t be fooled into thinking you have an out-of-the-box agile process. Or just don’t use Scrum…

Posted in Agile | Tagged , , | Leave a comment

The mystery of when to add that extra property path junk

This is a note post since I know I will want to come back to this again;

From: http://stackoverflow.com/questions/4640573/round-brackets-in-xaml-syntax

The parentheses indicate that this property in a PropertyPath should be constructed using a partial qualification. It can use an XML namespace to find the type with an appropriate mapping. The ownerType searches types that a XAML processor has access to, through the XmlnsDefinitionAttribute declarations in each assembly. Most applications have the default XML namespace mapped to the http://schemas.microsoft.com/winfx/2006/xaml/presentation namespace, so a prefix is usually only necessary for custom types or types otherwise outside that namespace. propertyName must resolve to be the name of a property existing on the ownerType. This syntax is generally used for one of the following cases:

  • The path is specified in XAML that is in a style or template that does not have a specified Target Type. A qualified usage is generally not valid for cases other than this, because in non-style, non-template cases, the property exists on an instance, not a type.
  • The property is an attached property.
  • You are binding to a static property.

 

 

Posted in Uncategorized | Leave a comment

Trick to see if you have a soft Steering Wheel in use

I’m sure there are some people that love the soft Steering Wheel. But sometimes, very rarely, they cause a problem when you are trying to arrange your page. One little trick you could use is to utilize the fact that the Bottom App Bar will be pushed up the screen to make room for the Steering Wheel. If we can compare the top position of the App Bar then we can assume that the Steering Wheel is in play;

GeneralTransform bottomAppBarTransform = this.TransformToVisual(this.BottomCommandBar);

Point appBarPosition = bottomAppBarTransform.TransformPoint(new Point(0, 0));

var pageHeight = this.ActualHeight;
var appbarHeight = this.BottomCommandBar.ActualHeight;

if (pageHeight - Math.Abs(appBarPosition.Y) > appbarHeight)
{
      // Hello Steering Wheel
}

Hopefully someone out there will reply with a, “no just use this simple API”. That would be nice.

Posted in Uncategorized | 1 Comment

The data area passed to a system call is too small

Got caught out with this nice error today; The data area passed to a system call is too small

I was creating a file and writing some text to it. The problem was that although the file was writing to disk correctly I couldn’t write any contents to it. Turns out it was because the full path file length was 256. Given that as soon as you write to iso store the path has already consumed ~100 chars you have to be really tight with your allowed app-relative paths. Should also be filed under, ‘why OS, why only 256!’

 

Posted in Uncategorized | Leave a comment

Is the DLLImport you want to use supported by the Store?

I know I’m going to forget this within the next 10 mins, so I thought I’d write it down. If you are using DLLImport in your UWP project and you’re not sure if the Store will allow it, then you can check for yourself by looking at the Supported API XML files in the certification kit folder. For me that’s;

C:\Program Files (x86)\Windows Kits\10\App Certification Kit

The files depend on the target architecture but you probably only need to check one of them, e.g. SupportedAPIs-x86.xml

 

 

Posted in Uncategorized | Leave a comment

Problem hosting a LAN game in Unreal Tournament?

Just installed the classic UT from Steam and discovered that LAN gaming doesn’t work. When you try and host a game you get;
Your network configuration may not be compatible with
hosting matches. Please check your router’s manual for
instructions on setting up “Port forwarding” or a “DMZ
server”.

The easiest way around this is to get the Host to write down their IP address. Then they should start a LAN game as normal, ignore the dumb error message. Then the other players start UT open the console (F10) and type; open {Host IP Address}

NB if you the client gets an error complaining that they don’t have Steam Authentication then they should close UT, go to Task Manager and kill any Steam processes and try again.

I checked, it is almost 2016 and we’re having to do this :s

Posted in Games, Uncategorized | Leave a comment