I don’t know why I thought writing a WPF application in .NET 4 for Windows 7 would be any different.

If you start with a default empty window it is rendered nicely with a drop shadow around it (like all other windows).

However, I wanted to achieve an alternative layout, without the frame but with the shadow still on. Unfortunately setting WindowStyle="None" creates a rather blunt rectangle.

There is always the option to do something inside the client window to pretend your window actually does have a shadow but it is somewhat messy and just not as pretty (or perhaps I wasn’t ready to tinker with the Canvas and Effects enough). So will say it also comes with a performance penalty (since you would require transparent background).

Finally, with a little bit of Interop spice by calling Desktop Window Manager APIs I got the desired effect:

Mind you it only works if DWM is available (that is in Vista and Windows7) but I’m fine with that.

Here is the required code:

[DllImport("dwmapi.dll", PreserveSig = true)]
public static extern int DwmSetWindowAttribute(IntPtr hwnd, int attr, ref int attrValue, int attrSize);

[DllImport("dwmapi.dll")]
public static extern int DwmExtendFrameIntoClientArea(IntPtr hWnd, ref Margins pMarInset);

void ShellWindow_SourceInitialized(object sender, EventArgs e)
{
var helper = new WindowInteropHelper(this);
int val = 2;
DwmSetWindowAttribute(helper.Handle, 2, ref val, 4);
var m = new Margins
{
bottomHeight = -1,
leftWidth = -1,
rightWidth = -1,
topHeight = -1
};

DwmExtendFrameIntoClientArea(helper.Handle, ref m);
}

If you want to dig deeper there is WPF Shell Integration Library that does some of this heavy lifting for you.

P.S. Seems like Java folks have similar challenges.

I’m not sure I know where to start trying to pick this out… sadly this is just one of the many examples.

I have recently had an opportunity to take some extra training and, following very good past experience with training from Skills Matter, I decided to pick a Certified ScrumMaster training from their offer.

I have been doing Scrum for over a year now so I felt I have had some exposure and a little bit of knowledge of the subject. I have also witnessed some of the conversations in the community of advantages and disadvantages of Scrum as well as of alternatives such as (some will say) Kanban. CSM programme itself has also caused a bit of controversy.

I’m a pretty inquisitive person so decided this would be an excellent opportunity to get a first hand experience, gain better understanding and learn. I was also interested to meet Mike Vizdos whom I have heard of before through his witty Chicken & Pig cartoons at http://www.implementingscrum.com/

If I started a little apprehensive it faded away very quickly. Mike has a teaching style I really enjoy. He is passionate, energetic and enthusiastic without being patronising . He also demonstrated a good dose of pragmatism. His training was clearly rooted in hands-on experience and sprinkled with many interesting and relevant “was-stories”.

My most important take-away will certainly be the way in which Mike deliberately, consistently and explicitly applied the coaching and mentoring skills essential for any ScrumMaster in his training. He took the entire group of 17 people in the course on an accelerated journey through forming, storming, norming & performing. And guess what, it worked.

What I also liked about Mike is that he was open and honest about Scrum without compromising his integrity as a Certified Scrum Trainer.

It was an interesting experience to see some of the common misconceptions about the ScrumMaster role. The most prominent were perhaps that:

• ScrumMaster is just another fancy name for a Project Manager
  • SM does not replace a PM and a PM on a project does not automatically become a SM
• ScrumMaster is an additional role anyone can perform
  • To be done well, this is a full-time job and only on one team
• ScrumMaster is the guardian of the process
  • What process?
• ScrumMaster is present at and runs all stand-up meetings
  • stand-up meetings are for and are a responsibility of the team
• ScrumMaster is responsible for producing charts and creating process documentation
  • What documentation? Who are the charts for?

I can now re-iterate a Certified ScrumMaster is certified or, in other words, simply confirmed to have attended the two day training. Is that enough to be a ScrumMaster on a Scrum team – yes. Is it useful – yes. It is essential – no. Does that make one a good (or a better) ScrumMaster – definitely not. Since the pivotal role of a ScrumMaster is to work with people the only way to become good and competent is to practice, practice and practice and go through many deliberate learning cycles.

Also, it does make a difference, who your trainer is. I was lucky (or picked smart).

Thank you Mike for this enlightening experience, it was by no means a waste of time.

The Scrum alliance itself give the following definition for sprint burndown chart:

A sprint burndown chart (or “sprint burndown graph”) depicts the total task hours remaining per day. This shows you where your team stands regarding completing the tasks that comprise the product backlog items that achieve the goals of the sprint. The X-axis represents days in the sprint, while the Y-axis is effort remaining (usually in ideal engineering hours).

Mike Cohn too, gives an example, where effort remaining is tracked in hours. Scrum for Team System (STS) for Microsoft’s TFS provides a picture along the similar lines:

Having taught physics for a while and being an engineer I can’t help myself to think a graph like this ultimately represents time vs time. So long as we don’t approach the speed of light time goes at a pretty constant rate therefore the only correct line in the graph would be a straight line.

I know, it’s not clock hours, it’s remaining effort (ideal hours) and we are tracking our true progress against estimated time therefore not having a straight line should be OK. Still, to maintain the burndown chart we have to track progress and with a graph like that is needs to be progress in hours. Yet as people who grow and learn a particular perception of time we use clocks to track those hours. So when we record time we usually won’t think “Well, today in my 8 hour day I did only 4.5 ideal hours of my estimate”. It is just too easy to game the system as well “If I don’t tweak the numbers it will look as if I only did 2 hours yesterday”. For good, confident Scrum teams this will not be an issue. For forming and storming teams the temptation might be too big. It also provides a temptation for management (even though sprint burndown chart is solely a tool for the team) to say “You guys have only 5 extra hours left it seems, with a bit of over time you’ll be done on time”.

My answer to the problem is simple – although it requires some more discipline in analysis – break your stories down and track story points also in the sprint burndown chart.

With these thoughts I was glad to listen to Kevlin’s Henney talk at NDC 2010 who made some further remarks along the same lines.

• Time against time is a utilisation graph – not what we meant to be plotting
• We end up logging the amount of work we did – so just proved we are using 7 hours of the day as we said we would
• Kevlin is against plotting time against time at all because it gives false precision
• With 2 weeks iteration there are only 8 points of reference (8 working days) – not statistically significant for hourly estimates
• Visualise items of work left to complete

I’m glad Jeff Sutherland also recommends burning story points.

Ultimately, employers who state such requirements make one fundamental mistake. They think the only factor limiting how quickly they create software is how quickly their developers can type.

Yes, if you have worked with NHibernate for 2 years you will write the mapping file more quickly and you might already know what fetch strategy to use. You will not, however, deliver good, valuable software more quickly. The speed at which you type has never been, is not, and I don’t think will ever be a limiting factor, ever. It’s like thinking Picasso would have created more works of art if only he could have made his brush strokes more quickly, or that Pollock would have made a bigger impact on the art world if he could pour paint more quickly. Wrong.

There are many other things to look for in a good developer (more on that another time perhaps) but for now, start with people who are smart and get things done not the ones who have experienced a specific technology for more years and thus can write the code for that technology more quickly.