The latest Pulse 2.1 build, 2.1.16, has just been finished. This build is significant in that it is the first non beta release of the 2.1.x series. This is particularly important for all those people that have been patiently watching the progress of all the new features in the beta, but unable to take the risk associated with running beta software.

For those that have not been keeping up to date on the new features and improvements in the 2.1.x series, you can check out what’s new.

To briefly summarise the main updates:

• Project dependencies
• Multi-command projects via the UI
• Numerous personal build improvements
• Improved .NET tool support
• Agent utilisation statistics
• Build result comments
• Finer grained build cleanup
• Built in reference documentation
• Pluggable commands
• Admin UI improvements

And much more.

Yes, we have been busy . Get over to our website and download the it now — it’s free to try, and a free upgrade for customers with current support contracts!

Ellen Gottesdiener (at least, I think it was Ellen – whoever it was, thank you!) recommended Anne Lamott’s book Bird by Bird: Some Instructions on Writing and Life to me. Though it is more about creative writing, and though I found the author to be a bit of a kook at times, I’m taking away a lot of advice from it.

Lamott highly recommends participating in a writing group. This was good affirmation about our writing-about-testing group. But she cautions about criticizing others’ work: “you don’t always have to chop with the sword of truth, you can point with it too.” Having been chopped down before, I appreciate this advice. We need criticism, but we also need civility.

She also talks about the joy of having a writing partner, and I can attest to the value of that! Janet Gregory is the best writing partner anyone could want, whether we are writing something together or helping each other with individual projects.

Here are some more tips from the book that stick in my head:

“Short assignments” – if you have an anxiety attack trying to start a project, write down as much as you can see through a one-inch picture frame. Tell a one-inch piece of your story. I think this applies well to our kind of writing too.

“Shitty first drafts” – All good writers write them. That’s how they end up with good second drafts and awesome third drafts. I put this to use already on my Agile 2010 proposals and so far I’ve got some shitty first drafts, yay!

Get over your perfectionism. (I think this is particularly difficult for us Type A testers).

Quiet your negative inner voices, and get out of the way of your subconscious. At first I thought this was not applicable to technical writing, but all writing comes from within us, doesn’t it? We figure problems out while we’re thinking about something else or zoned out in the shower. Who knows what might be locked up in my subconscious, if I could just quiet my brain down enough to hear it?

There’s a lot in the book about characters and dialog that I didn’t find all that relevant to my writing, but it was still interesting.

Lamott writes about keeping at least one index card and a pen with her at all times to jot down notes, ideas, observations. She wrote the book in 1994, so maybe now she uses an iPhone, I dunno. But, I know at times I’m out walking the dog or something and have an idea – like this morning I had an idea about my proposal while I as out walking – it would have been good to have a way to note it down so I didn’t forget.

Another interesting chapter was on jealousy – being jealous of other writers (especially of your friends) when they have a huge success and you don’t. I don’t think I feel jealous about others’ success, at least not in the field of writing (I am envious of my former neighbors who retired to Hawaii, but at least I get to visit them), but maybe I just don’t admit it to myself because I know it seems bad? I do get envious when other people get fabulous jobs in fabulous locations, but why? I have a fabulous job in a fabulous location!

I think my wonderful writing-about-testing community as well as the other agile and testing communities in which I participate will help me avoid wasting time on envy and take advantage of every resource that can  help me write well. I write because I have something to say that I think could help someone else. I’m grateful for the opportunity to pay forward all the help I’ve received over the years as I’ve learned better ways to develop and test software.

While working on some code with Toni we realised that we'd managed to create two functions that were almost exactly the same except they made different service calls and returned collections of a different type.

The similar functions were like this:

private IEnumerable<Foo> GetFoos(Guid id)
{
    IEnumerable<Foo> foos = new List<Foo>();
    try
    {
        foos = fooService.GetFoosFor(id);
    }
    catch (Exception e)
    {
        // do some logging of the exception
    }
    return foos;
}

private IEnumerable<Bar> GetBars(Guid id)
{
    IEnumerable<Bar> bars = new List<Bar>();
    try
    {
        bars = barService.GetBarsFor(id);
    }
    catch (Exception e)
    {
        // do some logging of the exception
    }
    return bars;
}

We're defining the empty lists so that if the service throws an exception we can make use of an empty list further on in the code. A failure of the service in this context doesn't mean that the application should stop functioning.

My thinking here was that we should be able to pull out the service calls into a function but the annoying thing is that they return different types of collections so I initially thought that we'd be unable to remove the duplication.

Thinking about the problem later on I realised we could just define the return value of the service call in the function to use generics.

We therefore end up with this solution:

private IEnumerable<Bar> GetBars(Guid id)
{
	return GetValues(() => barService.GetBarsFor(id));
}

private IEnumerable<Foo> GetFoos(Guid id)
{
	return GetValues(() => fooService.GetFoosFor(id));
}

private IEnumerable<T> GetValues<T>(Func<IEnumerable<T>> getValues)
{
    IEnumerable<T> values = new List<T>();
    try
    {
        values = getValues();
    }
    catch (Exception e)
    {
        // do some logging of the exception
    }
    return values;
}

I think the code is still quite readable and it's relatively obvious what it's supposed to be doing.

I came across an interesting post that Roy Osherove wrote a few months ago where he talks about 'Willed vs Forced Designs' and some common arguments that people give for not using TypeMock on their projects.

I'm not really a fan of the TypeMock approach to dealing with dependencies in tests because it seems to avoid the fact that the code is probably bad in the first place if we have to resort to using some of the approaches it encourages.

Having said that Roy makes the following point which I think is quite accurate:

You let an automated tool (rhino mocks, Moq etc..) tell you when your design is OK or not. That point alone should go against anything ALT.NET has ever stood for, doesn’t it? If you need a tool to tell you what is good or bad design, then you are doing it wrong.

While it is true that it's useful to be able to know for ourselves whether our code is drifting into territory where it's become way too complicated, I think it is useful to have the tests as a reminder that this is becoming the case.

It's quite easy when you have a delivery deadline and are under pressure to stop being as observant about the quality of what you're coding and to rush to complete our particular task.

In these situations it can be useful to be restricted by our framework to the extent that the pain we'll feel in trying to test our code will act as an indicator that we're doing something wrong.

What I found interesting when reading Roy's post is that the arguments sound sounds quite similar to the discussion a couple of years ago with respect to whether using Mockito instead of jMock was bad because it hides design problems that you have with dependencies. Steve Freeman wrote the following comment on Dan's post:

But, it also became clear that he wrote Mockito to address some weak design and coding habits in his project and that the existing mocking frameworks were doing exactly their job of forcing them into the open. How a team should respond to that feedback is an interesting question.

In the meantime, I’ve found that I /can/ teach using the existing frameworks if I concentrate on what they were intended for: focusing on the relationships between collaborating objects. I’ve seen quite a few students light up when they get the point. In fact, the syntactic noise in jMock really helps to bring this out, whereas it’s easy for it to get lost with easymock and mockito.

In this case I definitely prefer the style of mocking that we get with Mockito over jMock even though I've worked on code bases where we've created objects with way too many dependencies and haven't felt the pain as much because the framework is so easy to use.

I can't think of a compelling argument for why this is different to the TypeMock vs other mocking frameworks argument. It seems to be a similar argument around dependencies in our code.

The other thing I'm intrigued about is whether the choice of framework should be in some way linked to the level of skill of the people who are going to use it.

If someone is a Dreyfus Model novice with respect to object oriented design then it would make much more sense to use a tool which makes it really obvious that they're doing something wrong. In that case using a perhaps more limited tool would just be a quick feedback mechanism.

Once we have a bit more skill then it would seem more appropriate to use the more powerful tool which we have the ability to abuse but hopefully now have the experience to know when we can and cannot get away with doing so.

In the end the argument seems quite similar to ones I've often heard about programming in Ruby and whether or not we should give programmers powerful language features because they're liable to hang themselves.

In conclusion I'm thinking that perhaps TypeMock in experienced hands isn't such a bad thing and could actually be useful in some select situations but would probably be quite a dangerous tool for someone new to the whole unit testing game.

By Kevin Meyer

While Toyota executives are scurrying around having lost their way, the employees at their factories are doing what Toyota does best: improving.

For the past week, Toyota's leaders have wrestled with the fallout from an unprecedented recall of 4.5 million vehicles that will likely cost the automaker $2 billion in repairs and lost sales. Here at the company's largest North American plant, the workers who assemble two of those recalled models are thinking more than ever about quality.

Those employees still understand that the power of the Toyota system revolves around people, especially the brains of those people.

Workers affected by the idling had the option of taking paid vacation or unpaid leave, but the vast majority came to work, with many taking training sessions, cleaning assembly line stations or applying new coats of paint. But it's also been a time for the plant's more than 200 "quality circles" to meet and find ways to solve assembly problems, searching for sometimes elusive answers to Toyota's quest for better efficiency and lower costs.

Each circle, a program done globally at Toyota plants, consists of seven to eight employees across the plant who volunteer to focus on a particular issue. When the assembly lines are running, the circles meet after work or during break times.

So what types of problems and issues are tackled?

"Sometimes it's tough to work on the processes while the line is up, so this is an opportune time this week to go to the process and make some modifications while the line is down," said Nancy Corey, quality circle administrator in Georgetown.

On Friday, among the teams meeting were one examining how to make faster and less expensive repairs to tools and another looking to recycle a supplier's velcro ties.

"Some things seem very small but they have a big impact," Corey said.

Small things... small improvements.  Toyota is known for many suggestions per employee per year and the art and science of kaizen.  The cumulative effect is massive in terms of productivity and quality.

Toyota is also known for the andon - celebrating the discovery of problems as a chance to improve, and the stopping of the line to ensure those discovered problems never see the light of day.  Contain the problem, fix the problem, then prevent the problem from ever reoccurring.  I saw it myself when I visited the Lexus factory in Kyushu.

Toyota's executives, perhaps in their haste to grow and conquer new markets, forgot that last part.  They still have a chance to survive the increasing maelstrom if they leverage what their employees still remember.

I’ve just submitted a proposed session to the Agile 2010 web site:

Test-Driven Development for the iPhone, iPod and iPad

Please go to the site and let me know in the comments there if you have any suggestions about the proposal!

'); //-->

Erik Gfesser posted a lovely review of Manage Your Project Portfolio. Thanks, Erik!

Tweet This Post

Free Realms Reaches 8 Million Registrations!

Free Realms was developed using Scrum by SOE.

Over half a dozen SOE developers have become ScrumMasters in one of my past Certified ScrumMaster for video game development courses.

dzone_url = "http://www.targetprocess.com/blog/2010/02/visual-design-escaping-flatland.html";

Books by Edward Tufte are a piece of art. I’ve been savoring them to myself for a while, and now I decided to share some sketches and criticism inspired by Tufte’s high art visual designs.

Commonly, designers represent visual information by scarce means of 2D realm: screen and paper. Our universe is 3D (if not 5D, 6D or whatever more dimensions), but people got used to squeezing  images into 2D flatland.  Even rock paintings of pre-historic humans have their touch of 2-D abstraction and symbolism.

Our universe is not just 3D. It’s dynamic 3D. Paper is static (paper planes are exceptions). That’s another limitation of 2D.

Limitations are great. They motivate designers to find solutions. The more limitations - the harder it is to find a solution. Good designers love difficult tasks, since they view them as great opportunities to put their brains to use. Bad designers do not want to use their brains - they want to use templates.

The image below is a template solution for a weather map. View from above.  Let alone template thinking, the representation of this template is poor.

The appalling hint of white shade is a helpless attempt to compensate inadequate color selection for numbers.  What do you think of blue numbers on blue background? You hate that, to say the least of it. What’s the message of these pseudo-3D grey circles? Are they some grey moons? Or cavities  in the designer’s brain?

Now let’s take a look at the Euronews channel weather map.  One may think that this map represents the effects of global warming and Australia is completely hidden under water now. Also, what do those bold numbers show? Probably the depth of the ocean in this area. In meters. Or in miles? But the area is still lit by sunshine, which instills some hope.

As a contrast, here’s a weather map from a Japanese daily, beautiful in its simplicity.  This is the same Japan as on the first weather map above, only from the ocean perspective.  This map provides 0°C и 10°C  isotherms.  You see fine clouds on this map. The map shows sun movement.  OMG, it shows stratosphere! And it’s nothing more than just a weather map from a daily newspaper  - but created by a good visual designer.

Of course, Japan is well-suited for such a nice graphical representation. But you gotta have guts to catch and use this ocean perspective, instead of helplessly surrendering to boilerplate view-from-above weather maps imposed by paper sheet or screen limitations.

var dzone_style="2";

Software value verification is a new concept for me. Is the agile community paying attention to verifying value in software? Not so much. I have been trying to get my arms around measuring...

Sometimes wildly informative.

Agile development is often initiated by the development team itself. Whilst they may find some good advantages, the most profound benefits of agile software development will not be realised unless it is driven from the top.

Here's why:

1. Multi-disciplined teams

One of the key concepts of agile development is the idea of multi-disciplined teams - "one team". An agile development team needs all the skills necessary to complete its task from cradle to grave. From initial request to delivery to market, the team should be able to deliver without reference to another team.

Having multi-disciplined teams reduces coordination, creates clear ownership and responsibility, speeds up delivery, and empowers the team. As I said earlier, profound benefits, but benefits only possible to realise often by making changes to the organisational structure, which usually need to be driven from the top.

2. Co-location

Another key concept of agile software development is co-location. Ideally the whole team will all be located in the same place - not just the same office but literally sitting side by side in the same room or space.

Having co-located teams also reduces coordination, speeds up communication, fosters closer working relationships, creates the opportunity for continuous collaboration, enables face-to-face communication, means you can get better visibility of progress etc by putting things on the wall, and strenghtens team spirit.

These factors, over the course of a project, can make or break it. Co-location often requires management intervention, in order to move people around so they can all be together. Sometimes it may be even more fundamental than that - moving people from offices in different cities and physically reorganising the company. So again, it really needs to be driven from the top.

3. Product ownership

A common problem in large organisations is that there are many stakeholders for any given product. It is also common for development teams to be developing and maintaining multiple products. The effect of this is that many people make requests, and to each of the stakeholders, their request is naturally the most important.

With so many requests coming from so many directions, how does a development team prioritise and manage expectations. Usually, it's a case of who shouts loudest! This is not the best approach for the business, as it's sometimes those demanding the most attention that get priority and not those that drive the most business benefit. It also creates an unpleasant working environment, where the default system for getting things done is to moan, shout and escalate. It's not the most motivating way to work, and it's not the most effective.

A development team needs a clear Product Owner, at least for each product if not for the whole team. The Product Owner needs to be the one person who prioritises on behalf of the business, and needs to have real authority to make decisions and stand by them. The team need to know that this is the one person they should listen to the most.

Having clear and empowered Product Owners transforms a teams' performance by enabling them to work on the most important requests, cutting out a lot of noise, creating a more positive working environment, motivating the team, and strengthening business relationships.

The trouble is, in large businesses, there is often not one person who naturally holds this position and has this level of authority. The role of Product Owner needs to be explicitly assigned to someone and communicated clearly to all stakeholders. As this role often spans business units, this usually needs to come from the top.

4. Agile project management/Stakeholder expectations

With agile project management, stakeholder expectations need to change. Where they may be used to seeing a full requirements document and/or specification up-front, they shouldn't expect to see that in agile. Where they may be used to seeing a detailed project plan in the form of a gantt chart, they shouldn't expect to see that in agile. Unless they know that, understand why that is, and really believe in the benefits of agile and why there is a need for change, this will potentially cause you problems.

Since these stakeholders are often senior managers and directors of the organisation, these steps are an important part of selling agile and where the real change management challenge is. This needs to be carefully managed and the message needs to reach all key stakeholders, at all levels of the organisation. In order to secure real buy-in, this usually needs to be driven from the top.

5. Different values

Agile development has different values to traditional project management methodologies. Unless people understand what these values are, how they are different to previous way of working, they will struggle to adopt or embrace some key aspects of agile software development.

People need to understand that whilst they will have less predictability and won't be able to see a clearly defined fixed scope, instead they will get a high-performing team that can deliver software faster and to a higher quality, and that they'll get much more visibility and flexibility that's more likely to meet their changing expectations, and with less bureacracy.

Everyone needs to know that it's okay to lack that perceived clarity from the outset in favour of flexibility and the other benefits that come from adopting agile development. They need to know that agile principles and practices mitigate risk in a different way - not with detailed planning and analysis and strict control, but through visibility, transparency and frequent delivery of working software in small incremental iterations.

People need to know that these values are supported from the top; that it's not only okay to behave in line with these new principles, it's expected.

Summary

Adopting agile development will help with many issues. But without these things being led from the top, you will only be partially successful and you will only see a small fraction of the possible benefits.

Kelly.

Photo by lepiaf.geo

Im März 3 CSM Termine - allen voran das deutsche CSM Training mit ScrumCooking in Wien am 15+16.3. Gefolgt von 2x Zürich: am 11+12.3. CSM in englischer Sprache Boris Gloger mit CST-Anwärter Ralph Jocham und am 29.+30.3. CSM in deutscher Sprache Boris Gloger mit CST-Anwärter Josef Scherer. Das der Auftakt unseres neuen Professional ScrumMaster® Programms in Wien: 4+5.3. TeamEntwicklungsTraining [...]

http://citconf.com/raleigh-durham2010

I wanted to let everyone know about CITCON North America in Raleigh Durham on April 16 & 17 because I co-chair the conference and the more of you that come, the better the conference becomes. This is the 5th year for the conference. We started the conference back when I was at ThoughtWorks doing CruiseControl work and JTF was at Agitar. It’s great to see new and old faces alike each year. Maceij from Urbancode described it as “an annual reunion of sorts”.

I love the open spaces format, largely because I have no idea what I will learn until I get there. I learn whatever everyone else is interested in. That’s an amazing way to take in new information. It’s humbling. In fact it reminds me of one of the first concepts I had to accept when I studying the philosophy of Socrates in university, “Before we can learn anything, we must first admit we know nothing.”

Can’t make it to CITCON RD? Then make it to one of the other ones – Wellington, NZ – Prague, CZ – Singapore.

CITCON, the Continuous Integration and Testing Conference, is an open spaces conference in its 5th year. The topics aren’t decided until the first night of the conference, but past events have proven extraordinarily useful to anyone interested in Continuous Integration and the type of testing that goes with it. Developer-testers, tester-developers, tool creators, and Agile advocates have all gained a lot from attending.

The conference is free to attend! You have to pay $20 to register, but you get that back when you attend the conference. (We are using long time conference supporter Obtiva’s EventWax for registrations. Just follow the registration link below.)

This year, the North American event will be in Raleigh-Durham at the Sheraton Chapel Hill Hotel. Registration is open, but limited to the first 150 registrants. Sign up now to reserve your spot at this innovative, exciting, education, fun event.
http://citconf.com/raleigh-durham2010/register.php

The conference operates as a non-profit, so our advertising budget is basically zero. We can use your help to get the word out. If you know someone that might be interested, please pass this announcement along to them.

Also, if your company or a company you know would be interested in sponsoring CITCON, there are a wide range of sponsorship options.
http://citconf.com/raleigh-durham2010/sponsor.php

If you have any questions, please don’t hesitate to contact me.

15 in before my talk in Dornbirn I was in panic! A super cool room, more than 100 people, the best media technology support I ever had and I had not prepared a presentation on slides. My idea was to do a dialogue with the people, but the room… In “Confessions of a Public Speaker” [1] [...]

“People only see what they are prepared to see.” - Ralph Waldo Emerson

At the beginning of the year, I like to take a quick survey of the Microsoft application platform.  It helps me figure out where to put my bets and where to explore.  It’s a “see the forest, from the trees” exercise.

And oh, what a forest it is.  The beauty is it covers a wide spectrum and supports so many scenarios.  The challenge is finding your way around.  To find my way around, I map out the platform and I think in terms of application types:

• Web applications
• Mobile applications
• Rich Internet Applications (RIA)
• Rich Clients
• Web Services

By thinking about deployment targets such as cloud or desktop or browser or phone, etc. it makes it very easy to get in the ballpark in terms of context and technologies very quickly.  From there, I can worry about things like presentation or data access stacks or language platforms (native, .NET, or scripting.)   It’s also a quick way to explore relevant quality attributes (security, performance, reliability) or evaluate architectural styles.  In other words, it’s a way to hack through information overload and cut to the chase.

Microsoft Application Platform at a Glance
This is my draft map of the platform.   It’s a strawman that I use to walk the platform, find clusters of technologies, figure out what’s changed, and evaluate the latest story.  It’s easier for me to have conversations about the platform with customers or product teams when I start with a shared frame.  The hard part is putting the initial map together.  The easy part is improving it through feedback.  If something is missing, it’s easy to add.  If something is wrong, it’s easy to fix.

As simple as the map looks, it compacts a lot of information.  I stuck the code names in where I could find them.   Enjoy …

Category Items Application Infrastructure

• .NET Framework
• Base Class Libraries (BCL)
• Common Language Runtime (CLR)

ALM (Application Life-Cycle Management)

• Visual Studio Team System
• Visual Studio Team Foundation Server

App Frameworks / Extensions

• Enterprise Library
• Managed Extensibility Framework (MEF)

Cloud

• Windows Azure
  
  
• App Fabric (Dublin + Velocity)
• SQL Azure

Collaboration / Integration / Workflow

• Windows Workflow Foundation (WF)
• Microsoft Office SharePoint Server (MOSS)
• Microsoft BizTalk Server

Data Access

• ADO.NET Entity Framework
  
  
• ADO.NET Core
• ADO.NET Data Services Framework
• ADO.NET Dynamic Data (Jasper)
• ADO.NET Sync Services
• Language Integrated Query (LINQ)

Database Server

• Microsoft SQL Server

Development Tools

• Microsoft Visual Studio
• Microsoft Expression Studio

Games

• XNA

Identity

• Windows Identity Foundation (Geneva)
• Active Directory Federation Services (Geneva Server)
• Card Space

Mobile

• Silverlight for Mobile
  
  
• .NET Compact Framework
• Windows embedded
• Windows Mobile

Modeling

• SQL Server Modeling (M / Quadrant) (Oslo)

OBA (Office Business Applications)

• Microsoft Office
• SharePoint

Parallel

• F#
• Parallel Extensions for .NET
• PLINQ
• Task Library

Rich Client

• Windows Presentation Foundation (WPF)
  
  
• Windows Forms
• Windows Forms with WPF User Controls
• XAML Browser Application (XBAP) using WPF

Rich Internet Applications (RIA)

• Microsoft Silverlight
  
  
• Silverlight with AJAX

Services

• Windows Communication Foundation (WCF)
  
  
• WCF RIA Services
• WCF Data Services (ADO.NET Data Services, Astoria)
  
  
• ASP.NET Web Services (ASMX)

Web

• ASP.NET
  
  
• ASP.NET Web Forms
• ASP.NET Web Forms with AJAX
• ASP.NET Web Forms with Silverlight Controls
• ASP.NET MVC
• ASP.NET Dynamic Data

Web Server

• Internet Information Services (IIS)

Where To Find Out More
I’m a fan of teaching people to fish, as well as giving some starter fish.  Aside from people, events, and social media, the three best ways I know to figure out what’s happening on the platform are Wikipedia, Channel9, and the MSDN Dev Centers.  I started you out with some pages below …

Wikipedia

• Index of Microsoft Code Names - http://en.wikipedia.org/wiki/List_of_Microsoft_codenames
• ADO.NET - http://en.wikipedia.org/wiki/ADO.NET
• ADO.NET Entity Framework - http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework
• ASP.NET - http://en.wikipedia.org/wiki/ASP.NET
• Azure Services Platform - http://en.wikipedia.org/wiki/Azure_Services_Platform
• Parallel Extensions - http://en.wikipedia.org/wiki/Parallel_Extensions
• SQL Server - http://en.wikipedia.org/wiki/Microsoft_SQL_Server
• Windows Communication Foundation (WCF) - http://en.wikipedia.org/wiki/Windows_Communication_Foundation

Channel9 Training Centers

• Azure Platform Training Course - http://channel9.msdn.com/learn/courses/Azure/
• Identity Developer Training Course- http://channel9.msdn.com/learn/courses/IdentityTrainingCourse/
• Office 2010 Workshop - http://channel9.msdn.com/learn/courses/Office2010/
• SharePoint 2010 Developer Training Course - http://channel9.msdn.com/learn/courses/SharePoint2010Developer/
• Silverlight 4 Training Course - http://channel9.msdn.com/learn/courses/Silverlight4/
• Visual Studio 2010 and .NET 4.0 Training Course - http://channel9.msdn.com/learn/courses/VS2010/
• Windows 7 Training - http://channel9.msdn.com/learn/courses/Windows7/
• Windows Server 2008 Training - http://channel9.msdn.com/learn/courses/WindowsServer2008R2/
• Windows Server HPC Learning Course - http://channel9.msdn.com/learn/courses/HPCLearningCourse/

MSDN Dev Centers

• Architecture Dev Center - http://msdn.microsoft.com/en-us/architecture/default.aspx
• patterns & practices Dev Center - http://msdn.microsoft.com/en-us/practices/default.aspx
• .NET Framework - http://msdn.microsoft.com/en-us/netframework/default.aspx
• App Fabric Dev Center - http://msdn.microsoft.com/en-us/azure/netservices.aspx
• ASP.NET - http://msdn.microsoft.com/en-us/aa336522.aspx
• Azure Dev Center - http://msdn.microsoft.com/en-us/azure/default.aspx
• BizTalk Dev Center - http://msdn.microsoft.com/en-us/biztalk/default.aspx
• Data Dev Center - http://msdn.microsoft.com/en-us/data/default.aspx
• F# Dev Center - http://msdn.microsoft.com/en-us/fsharp/default.aspx
• Internet Explorer Dev Center - http://msdn.microsoft.com/en-us/ie/default.aspx
• Mobile Dev Center - http://msdn.microsoft.com/en-us/windowsmobile/default.aspx
• Office Dev Center - http://msdn.microsoft.com/en-us/office/default.aspx
• Parallel Computing Dev Center - http://msdn.microsoft.com/en-us/concurrency/default.aspx
• Security Dev Center - http://msdn.microsoft.com/en-us/security/default.aspx
• SharePoint Dev Center - http://msdn.microsoft.com/en-us/sharepoint/default.aspx
• Silverlight Dev Center - http://silverlight.net/
• SQL Server - http://msdn.microsoft.com/en-us/sqlserver/default.aspx
• Visual Studio Team System Dev Center - http://msdn.microsoft.com/en-us/teamsystem/default.aspx
• Windows Dev Center - http://msdn.microsoft.com/en-us/windows/default.aspx
• Windows Communication Foundation (WCF) Dev Center - http://msdn.microsoft.com/en-us/netframework/aa663324.aspx
• Windows Presentation Foundation (WPF) - http://windowsclient.net/
• XNA Developer Center - http://msdn.microsoft.com/en-us/aa937791.aspx

by BILL WADDELL

Someone said the definition of insanity is doing the same thing over again and expecting different results.  Try telling that to the boys running Clorox and P&G.  It seem Walmart decided that having four brands of sandwich bags is two too many.  Their own Great Value brand was sure to stay, but between Glad, Hefty and Ziploc, two were going to get the heave ho.

Glad is made by Clorox, in a joint venture with P&G - the same P&G that has made 'brand management' both a science and an art, racking up big earnings selling mediocre stuff at high prices with overwhelming marketing and advertising - as opposed to creating genuine value for customers.  The same P&G that has been taking a pounding since the economy turned down (as if an economic downturn reduces the need for soap - it doesn't - it just reduces the demand for overpriced soap); but I digress.

So Walmart decides to skinny down the sandwich bag line up, and Clorox responds by spending $58 million more in advertising.  That is what they did because that is what they know - about all they know it seems.  Their official strategy is to create shareholder value now - this quarter  - and to do so with the 'Three D's - Desire - Decide - Delight.  They went 0 for 3 at Walmart.  Customers neither desired Glad bags, decided they were worth the money, or were particularly delighted - so out the Glad bags went.

It might have had something to do with the fact that Clorox was laying their employees off to pay for the advertising, or the fact that they were jacking up their prices in the face of shrinking 'desire for, decision to buy or delight with' their overpriced stuff.  "Shipments were lower than our projections due to retailer inventory reductions and soft consumer demand in some categories,"Don Knauss, Clorox's chairman and CEO, said in the company's earnings release. "That said, the impact of price increases earlier in the fiscal year was in line with our pricing models. We continue to be cautiously optimistic about the remaining six months of our fiscal year. Overall, we remain well-positioned given the challenging economic environment.”  Don said that last Wednesday - then got kicked out of Walmart.  I wonder if losing their biggest customer was "in line with the pricing model"?  So much for brand managers coupled with old school accountants.

Pactiv, the makers of Hefty, got to stay - at least their factories got to stay.  Their brand managers and pricing wizards got kicked out of Walmart.  They got the contract to make Walmart's private label brand, but their Hefty brand got tossed onto the same trash heap as the boys from Clorox.  Imagine their shock at learning the customers of the world's biggest retailer think their bags are OK, but their cherished 'brand' isn't worth a dime.  I can imagine production workers snickering up their sleeves at the overblown boys and girls at headquarters struggling to absorb that one.

No doubt a big part of their ouster, arising from the same lethal combination of believing that marketing and accounting are value adding endeavors - value creating, for that matter - can be found in the statement, "Over time, we have been able to raise selling prices in many areas of our business to offset the dollar effect of resin cost increases, although there usually is a lag of several months.  We continually monitor the resin marketplace.  As oil prices have fallen from their historic highs, we have seen a reduction of resin costs, which has had a favorable impact on the spread (the difference between selling prices and raw material costs)."  Roughly translated - 'we gouged our customers by jacking up prices, blaming it on the cost of oil, then kept the prices high when oil dropped'.  I wonder how their pricing model works now that they are peddling Great Value brand bags to Walmart?

These guys have a 'lean' focus that revolves around laying people off and economy of scale buying, and they spend a ton of money on advertising.  Look at the leadership resumes and operating principles of Clorox, P&G and Pactiv and you can't find a nickel's difference.

There is a difference between the two losers in the battle of the bags and SC Johnson - the makers of Ziploc bags that are still on the shelves of Walmart.  SC Johnson hasn't laid anyone off since they were founded 124 years ago - in 1886.  They have won 'Great Place to Work' awards in the United States just about every year such awards have been given, as well as similar awards in Canada, Mexico, Argentina, Australia, Chile, Venezuela, Germany, Italy and Turkey.  They practically invented employer provided day care, profit sharing, employment for the handicapped, and employee pension plans.

“The goodwill of the people is the only enduring thing in any business,” said Herbert Johnson, son of the founder Samuel Johnson, way back in 1927. “It is the sole substance. The rest is shadow.”  Great description for what passes for management at the bag losers - 'shadow'. The great-great-grandson now running SC Johnson agrees with him, or he lives in mortal fear that the old man will come out of his grave and there will be hell to pay if he strays from that vision.  Either way, he understands and lives his principles with SC Johnson's "This We Believe" statement, that makes it crystal clear that taking care of every stakeholder is vital.  Still a privately held company, of course, that doesn't go in for the claptrap of the supremacy of short term 'shareholder value, and could care less what any Wall Street industry analyst thinks about them or anything else.

"SC Johnson was built by people who understood that what we do every day has lasting consequences."  The big thinkers and brand managers at Clorox and Pactiv who play games with prices regardless of product value, and trash their employees' lives for the sake of this quarter's earnings might want to read that statement and think about it a little.  Or not ... and get kicked off the rest of their customer's shelves.  Either way, SC Johnson will keep following the same business model and will keep growing and taking good care of their stakeholders.

A certain tweet I saw a few days ago has been on my mind. Something about it was bothering me. I think I understand what it is. The tweet reads as follows:

Tomorrow is end of 1st iteration with new client. Only about 1/2 the stories will be done. Management response will be interesting. :)

So, what's wrong? In the first iteration, the team is uncalibrated. There is no velocity yet. Therefore, the concept of "1/2 the stories" is meaningless. There should be no hard-and-fast expectations of the team's delivery capacity as of the first iteration. The fact management has a firm expectation of delivery from the first iteration is a process smell.

I’ve wanted to write this post for a while, and reading “Metaphors we live by” has given me some language and ideas to express it in. So here goes.

Requirements come from above

In a straw-man Waterfall project, requirements are delivered to senior developers to design. Senior developers deliver the designs to junior developers to implement. Managers instruct teams in how to progress. We have, in our language and hierarchical organisation, a metaphor which maps “up” to the origin of the project, and “down” to the implementing details. We also think in terms of seniority and power, with the originators of the vision having that seniority and power, and the more junior developers and testers being at the bottom of the pile. We even talk about the team members “on the ground”.

Think of every organisational chart with the managers at the top, or the V-model in which the requirements are split into increasing detail towards the bottom.

In life, things naturally flow downwards.

Orders come from above

The other hierarchy with which we’re familiar is the military. We can map our employment and communication hierarchies to those of the military. We even talk about companies fighting for market share, defending their reputation, a hostile trading environment, captains of industry, command-and-control management, etc. It’s hardly surprising that we have, in our subconsciousness, another pattern: that the more junior members of a company should obey orders. (This isn’t necessarily true even in the military, but it fits our perception of it.)

Turning the world upside-down

I once heard of a business analyst who got tired of explaining the requirements to the developers. “I’ve told you three times already!” she snapped. “Everything’s clear. Just do it.” The BA sees the developers as working to fulfil her requirements. They serve her needs, rather than the other way around.

When we write and deliver software to a user on an Agile project, we ask them for their feedback.

• Is this useful to you?
• Is this easy to use?
• Is anything difficult to use?
• Does it help you to do your job more effectively?
• Can you think of any ways we could make this more intuitive?
• What would you like next?

Because we think of communication in terms of orders, we also think of junior staff delivering value to senior staff. We don’t necessarily think in terms of the communication itself being a form of delivery. If we did, we might ask for feedback from the users of our communication.

• Is this communication useful to you?
• How easy was our communication to use?
• Was anything difficult to understand?
• Did it help you to do your job more effectively?
• Can you think of any format you’d find more intuitive than this?
• Any questions?

If the BA above was a piece of software, her users would be filing bug reports, working around her, and using her competitors instead. I imagine instead that she’ll get a poor review and teams will prefer to work with her colleagues. If they only have the one BA to work with, the project will probably fail – the developers won’t be able to use her to get their job done.

Stakeholders aren’t users

I’ve written about this before, and it takes on a new importance in the context of users, and stakeholders, of communication. When we get a management report, we often think, “So what?” We hit the delete key. Instead, we could try to think, “Who is it that cares about us understanding this? Why does he care?” It’s often the case that a user is meant to do something, as part of his job, which is for the benefit of someone else. Similarly, we may be asked to understand or act on something for someone else’s benefit – and it won’t be the person delivering the message either.

The stakeholders of communication on a project are often stakeholders of the project itself – the security expert, the chief architect, the facilities manager, etc.

Project experience

Eric gave me the concept of a “Project experience”. In the same way that we can think of communication as a form of delivery, we can think of the experience that our stakeholders and customers have when they ask us, as a project team, to deliver their code. We can ask usability questions about the team.

• How easy is it to use the team?
• Is it easy to see what’s going on and get information about the progress of the team?
• Is it easy to undo a mistake?
• Is it easy to input a new idea?

We often hold retrospectives amongst ourselves to work out how to change our processes. I’d also like to see us actively getting feedback from the people who use the project. And next time someone gives you some instructions which are unclear or don’t help you to do your job, perhaps this metaphor will help.

I remember hearing a radio play on NPR way back in the 1970s entitled "Temptation." I wasn't able to find any information about it just now, but I recall the story line. It seems a monk sought refuge from a storm in an inn in a village resembling a place in medieval Europe. As he sat in the pub talking with some of the locals, they asked him why he chose the life of a monk. He explained that the world was full of distractions and temptations, and he found the isolation of the monastery peaceful and relaxing. He had few duties to perform and no real worries. The locals nodded and murmured their approval of his choice. Yes, they acknowledged, it would be very tempting to avoid the trials and tribulations of ordinary life, and go to live in a separate place where basic needs were taken care of. Very tempting, indeed!

In the ordinary life of our world, trials and tribulations arrive in the mail every month like clockwork. This year, coaching opportunities seemed to get off to a slow start. Yet, the aforementioned trials and tribulations all have due dates attached to them. They all seem to want money, for some reason. How tedious! So, while waiting for one of several possible coaching opportunities to transform from Maybe to Yes, I took a short-term contract as a software developer. It was really one of the most enjoyable and relaxing things I've done in the past few years.

The client company has a fast-paced environment. It's not a start-up, strictly speaking, but it's a fairly young company that is currently on a sharp growth curve. It's not an agile or lean environment, and they didn't bring me on board to help them with that sort of thing. (Sorry to be crude about it, but they didn't pay me appropriately to do that, either.) I was just there as a programmer. Of course, I wrote code the way I always do — using TDD. I can relate to Slartibartfast in a way; he always does fjords because...well, that's what he does. Sometimes he wins an award for it. Usually it goes unnoticed. I always do TDD because I'm uncomfortable delivering code that may or may not work. Sometimes that is appreciated. Usually it goes unnoticed. Unlike Slartibartfast, though, as soon as someone comes up with a better way to deliver working code than TDD, I'll change.

Sometimes the coaching game gets a little frustrating. It seems as if everyone says they want to improve their processes, their methods, their effectiveness, their skills, their habits. When it comes down to doing so, it's a different story. I know that's not universally true, but sometimes it's nice to take a break from all that and just write code. No political battles, no cultural barriers, no psychological resistance to change.

This client had an application to build and deploy on an aggressive release schedule. The other developers felt they were under some pressure because of this. I didn't feel any pressure. My scope of responsibility was much smaller than it usually is. I think I mentioned already this is not an agile environment. There was no collective ownership. I was only responsible for delivering "my piece" of the solution. The rest of the group (I can't say "team," really, although the group worked very well together) didn't use TDD or any other agile development practices. So, they spent a certain amount of time with their heads in a debugger, and they were frequently surprised by unexpected behavior of their code once it was integrated with other code. What little testing they did was manual, ad hoc, and after-the-fact. I didn't experience that kind of pressure personally, because my test suite protected me from most of those issues.

As far as release date pressure is concerned...well, when the release date was in jeopardy, they just moved it. That's the time-honored approach of traditional methods. They didn't use dimensional planning or user story mapping or a similar agile planning approach to deliver a valuable solution increment early. Heck, they didn't even have user stories. I'm not really sure they had a clear definition of done for the project as a whole, let alone for individual features.

Despite the fact the guys were supposed to deliver a solution by a certain deadline, they were constantly interrupted to do other work; there was no concept of dedicated team. They didn't interrupt me, since I was an outsider and couldn't have helped with problems that popped up in other departments. I was free to keep chipping away at examples and building up the code for "my piece." Lovely!

So...yeah, not an agile environment. Okay. But still, a fun environment. A good, meaty programming assignment. A vibrant, bustling, noisy work area; just the way I like it. A group of highly skilled colleagues with a geeky sense of humor. An opportunity to learn another programming language. Company-supplied coffee. The chance to contribute to a product that improves quality of life for customers. It's all good. And on top of all that, a relaxing and enjoyable work experience. Not a lot of money, but that really wasn't a big deal. Sort of like living in a monastery, I guess. No responsibility for changing the world; just a few duties and no real worries. It's tempting to walk away from coaching and organizational transformation in favor of this sort of work. Very tempting, indeed!

But the reality is a person can add a great deal more value by improving an organization's end-to-end processes than by sitting at a desk writing code. Despite the temptation, it would be selfish of me not to rejoin the fray. So, after this refreshing break, I'll be returning to the battlefield in a week or so. One of those organizational coaching opportunities finally transformed from Maybe to Yes. It's time once again to brace for political battles, cultural barriers, and psychological resistance to change. It's time to leave the monastery and return...home. Where I belong, fighting the good fight.

Still, it's nice to know where to find the monastery, for future reference. I have a feeling I'll be back.

Riot's League Of Legends Sees Over 1 Million Downloads.

Riot uses Scrum for developing and their developers have spoken about the experience.