How Microsoft/DevDiv uses TFS - Chapter 1 (Our Process)

How Microsoft/DevDiv uses TFS - Chapter 2 (Feature Crews)

How Microsoft/DevDiv uses TFS - Chapter 3 (Implementing the Process)

How Microsoft/DevDiv uses TFS - Chapter 3 (Addendum)

How Microsoft/DevDiv uses TFS - Chapter 4

How Microsoft/DevDiv uses TFS - Chapter 5 (Tracking Progress)

How Microsoft/DevDiv uses TFS - Chapter 6 (Tracking multiple projects)

How Microsoft/DevDiv uses TFS - Chapter 6 (Addendum)

How Microsoft/DevDiv uses TFS-Chapter 7 (Tracking Risk)

How Microsoft/DevDiv uses TFS-Chapter 8 (Tracking Quality Gates)

How Microsoft/Dev Div uses TFS - Chapter 9 (Transparency in Reporting)

Jeff Beehler and Brian Keller also put together a video of how Jeff uses the MPT & TFS to monitor progress of the release cycle.  Take a look on Channel 9:  https://channel9.msdn.com/Showpost.aspx?postid=391362

Organizations looking to go agile with Team Foundation Server often get the building blocks and infrastructure in place but struggle to achieve broad scale adoption across their enterprise.

The Scaled Agile Framework, abbreviated as “SAFe”, is a proven framework for implementing lean and agile methods at scale. SAFe provides prescriptive guidance for the individual roles, teams, activities, and artifacts necessary to scale agile and provide strategic alignment from the team to program to enterprise level.

The team of certified SAFe Program Consultants at Polaris Solutions have distilled the framework guidance into a custom process template that fully implements the Scaled Agile Framework within Team Foundation Server 2013.

In this free lunch time event we will provide an introduction to the SAFe, walk through the custom SAFe process template for TFS, and touch on best practices we have learned and applied while helping our clients leverage SAFe to take their agile teams to the next level.

Key Experiences:

• Introduction to the Scaled Agile Framework
• Overview of the SAFe Process Template for TFS
• Tips & tricks for getting the most value out of SAFe with TFS

Complimentary lunch will be provided to registered attendees.

Seating is limited. Register Now!

SAFe’s guidance is divided into three layers, each aligned to a level of abstraction matched to project scope within an enterprise. Actionable work is driven top down through cascading backlog queues and a simple, well defined taxonomy.

The Portfolio layer defines a framework for managing an enterprise project portfolio. The portfolio is implemented as a backlog of business and architectural “epics”, high level narratives aligned to strategic investment themes. Approved epics are delivered to the Program layer for further exposition and scheduling for implementation. 

The Program layer defines procedures for turning approved epics into proper product plans and is responsible for delivering a value stream to the organization. Activities include developing product visions, a backlog of high level “features” to be implemented, product roadmaps, and iterative release plans. Project features are batched up and delivered to the Team layer for implementation.

The Team layer prescribes a combination of Scrum management practices and XP technical practices to empower agile development teams to turn features into “user stories” and deliver working, valuable software in two weeks sprints.

Why You Really Should Care

So why am I raving about this? Agile has become the first choice for development teams building software, but true enterprise agile transformations are still rare. Adoption inside many enterprises has stalled due conflict with traditional waterfall business planning and budgeting processes. Here’s why I think SAFe can succeed at driving full scale enterprise agile adoption:

Simple. The epic–feature–user story taxonomy is the heart of this framework and the key to tracing efforts through these layers to achieve synchronization, collaboration and business value delivery. Its simple to learn and easy to teach – a key ingredient to cultural transformation.

Comprehensive. The layered abstractions chosen for SAFe provide the just the right amount of focus at the executive, product management, and development team levels. The roles and procedures are well defined and cover the complete set of activities needed to manage a portfolio of enterprise IT projects. SAFe will educate and push agile up into the very heart of enterprise.

Actionable. SAFe provides concrete procedures and detailed steps on how to get each layer up and running. It’s very real, very approachable, and very doable.

Well Documented. Leffingwell’s Agile Software Requirements book is in truth a playbook for enterprise agile transformation. It describes every detail of the SAFe framework and is one of the best written technical books I’ve read in years. Dean and his associates have also done an outstanding job documenting and “open sourcing” the framework through it’s public website – scaledagileframework.com.

Proven in the Field. The framework has been through numerous iterations, and has evolved through a number of large scale adoptions by real world enterprises, large and mall. The latest version published on the web site (v2.5 as of this blog post) has been validated by these field implementations and all the major ALM software vendors have either adopted it directly or facilitate an implementation of SAFe within their product.

I honestly haven’t been this excited about a SDLC methodology in years (I read Dean’s book cover to cover in two days – a rarity for a technical book). I see SAFe as a natural and necessary evolution of Agile upwards into the enterprise to fill a missing void. It is quickly becoming the foundation for many of our client engagements.

Note: Scaled Agile Framework and SAFe are trademarks of Leffingwell, LLC.

Here are the slides and downloads from my sessions:

Application Architecture Jumpstart

Document download: Patterns & Practices Application Architecture Guide 2.0.

Advanced OOP – Laws, Principles, Idioms

Source code download: Advanced OOP Samples.

I also wanted to thank my awesome team at Polaris Solutions (Josh Gillespie, Brian Yuan, Angela Dugan, Landan Rotter, Dave Seng, and Chris Kadel) for their hard work at the conference as well. Great job everyone!

I Want My Mummy is a 70 levels of rock breaking, TNT exploding physics puzzle fun. You tap on rocks to destroy them and try to get your mummy on the black landing platforms. Along the way, exploding bombs will launch your mummy through the air, knocking over walls and triggering more explosives and mayhem. You'll also have to deal with rocks that defy the laws of gravity and float away.

Pig Out Productions is a game studio based in Rolla, Missouri founded by William Garrett. Not your typical software developer, William’s preferred tools of choice are GameSalad and Photoshop. He’s completely self taught and specializes in casual, family oriented games with broad appeal. He works with a local artists and musicians to develop and refine his game concepts. As each game crystalizes, his children become his test audience. If sees them picking them up and playing over and over again, he knows has hit on his hands.

Over the last few years, Pig Out Productions has published a solid collection of great games for the iOS and Android platforms. William and his talented team are working feverishly to bring them to Windows 8 for us to enjoy. Look for them in the Windows 8 store in the coming weeks.

As always, stay tuned to my twitter feed for Windows 8, Windows Azure and other Microsoft developer announcements, updates, and links: @clinted

Core Objects

The diagram below shows the core objects common to all store applications:

An App class derived from the framework’s Application base class is the starting point. It represents the running process for the application and exposes basic events for startup and shutdown, as well as several other special events triggered by the operating system.

The sealed Window class represents the core container window created by the operating system to host the application’s user interface. It exposes several properties and events related to visibility and sizing. It acts as the host for the visual controls that compose the application.

The Frame class is a visual content container. It is attached to and completely fills the core Window object. It hosts and manages the lifetimes of the individual Page objects that form the user experience of an application. It provides a navigation framework with full backward and forward history stacks to allow movement between pages using a familiar browsing metaphor.

You can see an expanded view of these objects with their attributes and methods here:

Application Launch

The sequence diagram below shows the basic launch steps for a simple store application with a single Main page:

When a user launches the app, it triggers a call to the overloaded OnLaunched() event in the App class. This method instantiates a new root Frame object and attaches it to the framework’s current Window (there’s only one for the newly launched application).

Once the Frame is attached, a call to Navigate( typeof(MainPage) ) triggers the creation of the first page, fills the frame with it, and places it in the navigation history stack. It’s important to point out that the Frame’s navigation framework takes care of instantiating the requested pages, optionally reusing them if desired.

After the Frame is set up and the first page has been primed, a final method call to Window.Current.Activate() brings the application window to the forefront and shows it to the user.

That’s a quick tour of the Windows Store app model to show the fundamental objects and how they interact with each other as the application starts up.

Note: These models are based on a C# + XAML based application. The core object model is fundamentally the same for JavaScript + HTML5, but there are some differences in event names and object interactions due to language and runtime differences. I’ll show the JavaScript + HTML 5 versions of these same models in a future article.

As always, stay tuned to my twitter feed for Windows 8, Windows Azure and other Microsoft developer announcements, updates, and links: @clinted

This isn’t meant as disappointment with Orcs, but lately I’ve noticed my site throwing a lot of 503 Service Unavailable messages.  Orcs was always incredibly prompt at fixing the issue (I was told the app pool was stopping for some reason), but I always felt guilty pinging support.  Frankly, my blog is too important to me, so it seemed time to take responsibility for it.

WAWS allows you to host 10 sites for free, but if you want custom domain names, you need to upgrade to the shared plan at $10/mo.  This is a great deal for what you get, and offers great scalability options when needed.   My colleague, Andrew, recently had a great post on WebGL in IE11, and he got quite a bit of traction from that post as you can see from the green spike in his site traffic:

This is where the cloud shines: if you need multiple instances for redundancy/uptime, or simply to scale when needed, you can do it with a click of a button, or even automatically. 

Migrating the blog was a piece of cake.  You’ve got a couple of options with WAWS: you can either create a site from a gallery of images (like BlogEngine.net, Wordpress, et al.), as shown in red below, or simply create an empty website to which you can deploy your own code (shown in green).

Although I use BlogEngine, I already have all the code locally so instead of creating a site from the gallery, I created an empty website using Quick Create and then published the code.  If you’re starting a new blog, it’s certainly faster to select a blog of your choice from the gallery and you’re up and running in a minute.

After clicking Quick Create, you just need to enter a name (your site will be *.azurewebsites.net) and a region for your app to live:

Once your site is created (this should only take a few seconds) we’ll see something like this:

Since the site I’m going to be pushing up has already been created, all I need right now is the publish profile.  You can certainly publish from source control, but for the time being let’s assume we have a website in a directory we want to publish.  I saved that file in a convenient place.

There are two quick ways to bring up the Publish dialog in VS, either through Build – Publish Web Site, or right click on project and select Publish Web Site. 

The next step is to locate the publish profile:

Once imported, the connection details should be filled and the connection validated:

The first deploy can obviously take a little while depending on the size of the solution, and you can see what’s going on in the output window:

The website should launch automatically when done:

Easy, huh?  On the configure page, we can add our custom DNS names:

For example, on my blog, I’ve got a few domains that I’ve added:

When first trying to add a domain name, you may see something like this:

What the message is saying is that before the website will respond to that domain, we need to prove that we, in fact, own the domain name.  We can go about this two ways, either by creating an A record or CNAME.  A CNAME is technically the most appropriate, however, it’s often insufficient because many people try browse to a root domain, such as “https://structuretoobig.com” instead of “https://www.structuretoobig.com” or “https://blog.structuretoobig.com”.  In these cases, you need an A record, but that’s another topic entirely. 

Here’s an example of the somedomain CNAME for my blog on my DNS registrar (this is not something you do on Windows Azure – this is to be done by your domain registrar):

Once done, you might have to wait a short while for those changes to propagate the DNS cache.  (1 hour TTL is pretty low – typically you’d bump that a bit higher but when doing migrations, it’s best to keep this low so any changes you make are more immediate.)

Once done and after waiting about 2 minutes, the domain is verified in the Windows Azure DNS page:

In this case I created a CNAME over to this blog, so if we try it, here we are!  How cool is that … I’m writing about what’s on the screen.  Hmmm … this is kind of strange…

So what if we wanted to create something from the gallery, instead?  For example, setting up a new BlogEngine site instead of downloading the code and publishing it.  If we clicked on “From Gallery” when first creating our web site, we’ll see something like this:

The advantage of this approach is that it copies all of the files for you into your site.  You still have total access to those files, but this is perfect for new blogs and you know you’ll have a working configuration right away.  On the dashboard of the page, you’ll notice you have all the links you need to connect to your site, download a publish profile, set up source control, etc.  You can also configure an FTP password. 

If we open this in FileZilla, we can see it has the same directory structure as our code, as the gallery image happens to be using the same version.  If we wanted to, we could pull down this code and redeploy it as necessary with any changes:

The bottom line:  this post took a lot longer to write that it did for me to migrate my entire blog.  It’s easy to get going, and scalable to exactly what you need.  If you’re pulling in advertising or have critical uptime needs, you can have 2 or more instances for extra reliability and load capacity, or simply when needed.  If you don’t need a custom DNS name, the free tier gives you some great benefits and liberal usage. 

Want to get started with Azure?  Here’s a link to a free trial, and of course, the free stuff remains free after the trial.

Pricing and Making Money

Games are completely different than productivity apps, which are entirely different than entertainment apps, just to name a few broad categories.  In gaming, an upfront purchase is certainly the tried and true method, but as the market has saturated with $0.99 games, the most successful models have shifted to in-app purchases (IAPs) that extend the value of a free game.   These IAPs can be either for additional game content or levels, or for in-game items that enhance the value of playing the game.

There are exceptions.  Dan Russell-Pinson, the developer of the hugely popular Stack the States game available on iOS (often in the top 100 of top grossing apps) and Windows Phone, has discussed the monetization of kids games extensively in the Charlotte Game Meetup group.   (If you’re reasonably to the Charlotte, NC area, you really should make it out to this meetup!  Some app devs are amateurs, some are seasoned professionals!)  The challenge with educational and children’s games, according to Dan, is that most institutions (and, in many cases, parental controls) prevent in-app purchases, so to be successful, the purchasing has to be simple/upfront. 

Other games have more freedom.  John O’Neill, founder and chief wizard at Sparkplug Games, has discussed this at length at a number of the Raleigh-area meetups.  Effectively testing your app and gathering initial feedback by micro-launching an app can be a useful way to test a small market segment before going worldwide.

When it comes to pricing, however, starting at a high price point (within reason, of course, which is dictated by the current market) is usually the best approach.  Many apps are put on sale at regular intervals, and if you stick with the lowest possible price point you lock yourself out of promotion opportunities.  Besides, you can always lower the price of an app.  Raising it – while technically possible – is seldom helpful.

Advertising

Placing ads in apps is a great way to bring in revenue, as Kevin Ashley discusses in this post.  The key to make advertising successful, though, is that you need lots of users using your app for long periods of time.  If users are in and out of your app, the amount of revenue your app will bring in will be disappointing.

For Windows apps, check out the Microsoft pubCenter.  An SDK is available that makes it easy to plug into Windows 8 and Phone applications. 

Publishing

While it’s a good idea to consider how you can make money with your apps, it shouldn’t be the main focus.  The primary focus should be on creating a compelling application – and if that’s successful, the money will follow.

At our events we often rush the publishing process -- but in reality, this is something we should spend some time focusing on.  When publishing an app, you’re presented with the following portal:

By the time you get all the way down to description, all you want to do is hit publish and be done with it.  To further complicate the scenario, the Description section isn’t enabled until packages are uploaded (and, that’s not enabled until the previous steps are complete).  First suggestion: upload a package file that you are using for testing in order to enable the description section.  You won’t submit this for certification as you can simply upload the finished package when ready, but you want to start filling out the description section early:

Now that you’ve got the description field enabled, start filling it out.  Revise it.  Think about it.  Create compelling screenshots.  Create the promotional images.  Think about the keywords.  Have this section done ahead of time so when you are ready to submit your app for certification, this isn’t an afterthought.  The reason why this is critical is because this is the first interaction – the curb appeal – of your app.  This is your one chance to convince them to install your app.

Get the Word Out

You got the email:

Now it’s time to get the word out.  Include a link to the app in your email signature.  Include it in your blog.  Send an email to your developer friends, local user group, or app dev club and ask, politely, for some peer reviews.  Post in the developer forums that you just completed the app.  Be proud of your work. 

Why is this important?   You want to hit the ground running.  A few days after launching Brew Finder, I was seeing pretty good traction:

Looking at the downloads, I noticed a spike shortly after launch:

When I opened the Food & Dining category on the store, I saw the reason for the nice uptick:

This was great to see!  The app is on its way – but a big part in making this happen is to get the word out early.  Drive as much usage to your app in as short a period of time as you can.  The other thing we want to do is encourage ratings.  One way to do this is to add a ‘nag’ screen in the app.  For example:

The above box shows up once every few launches and allows the user to permanently dismiss the box.  When I look at the number of ratings I’ve received (15 ratings, as you can see in the screenshot higher on the page), I’m getting a 1:30 rating to download ratio.   If I look at the apps where I did not ask for ratings:

That’s 1:192, 1:131, and 1:180 ratings to downloads.  There is no question that asking users – politely – to rate your app will drive your ratings to download ratio.  You can also add whatever logic you’d like into your rating reminder dialog.  For example, only ask after so many minutes of usage or after a certain number of app launches.

So what about making money on the app?  I ruled out charging for the app,  While visiting my dad and describing the app, he looked up a similar app on his phone that charged a measly $0.99, and he didn’t buy it.  I realized that this is a typical reaction – an up front purchase will turn away many users.  In-app advertising is also a possibility, but, because of the specific nature of the app (breweries, beer, etc.), using an ad platform is likely to be detrimental to the app – it will bring in a little revenue, but potentially discourage use.  The ultimately goal is to create a great app, encourage use, and find a way (perhaps through a partnership with breweries) to drive value and revenue. 

Is this information useful?  If so, let us know (comments, contact me, etc.).  We’re getting a lot of feedback lately that marketing, monetization, and similar topics are really helpful.   Good luck on your app, and if you publish an app, post a link in the comments and I’ll check it out!