Before I share the final pictures from the event, I’d like to THANK the hosts (Robert and Candice) for a phenomenal event and the speakers & attendees for great sessions and more importantly great discussions. Let’s keep the awesome chats going!

The event in Cape Town was my personal favourite for a number of reasons:

• The day started with an energetic Lean Coffee event – missed the one in Johannesburg as I was in Zombie mode
• It was a smaller and cozier event – only three sessions to chose from at a time
• We had a lot more discussions on DevOps and VSTS in the hallways  
• We brought the rain to drought-stricken Cape Town

OK, here are a few more pictures:

Last traces of devconf.co.za in Cape Town

My favourite water shortage sign

The event hotel in Cape Town was an oasis

Stunning Cape Town

Sorry for the delay in this final post … the 25 hour trek (journey) from Cape Town to Vancouver really took it out of me.

If you have any questions or feedback on my Moving 65000 Microsofties to DevOps with Visual Studio Team Services talk, please add a comment below, or tweet me on @wpschaub.

See you next time!

Here are a few pictures to give you a snippet of the Capetonian event.

Speaker dinner – “Was zum Geier?”, why is our German Marco drinking tea, not beer?

Snippet of the hotel … Cape charm

We started the day with lean coffee, a great way to collaborate

Pictures across the event

Oh, we had lightning, thunder, and rain last night. Good news for the drought stricken region.

OK, gotta run … off to Mohamed Saif’s session – Continuously build, test, release, and monitor apps for every platform.

Watch the space!

Part of the mental preparation is to practice the session and ensure the 60-75min talk can be delivered in the 45min DevConf slot. I focused on grounding my feet to create the foundation of a relaxed, automated, and passionate session that delivers value. Recognise the practice of “continuous learning and improving”?

Here are a few pictures to give visual context:

Conference centre without the rain.

It’s called the RED cross for a reason – I give up!
 

Enjoyed a long catch-up lunch with my good old friend at Mandela Square.

Only South-Africans will understand me enjoying a Spur Goodie Burger, Black Label, and Biltong

Enjoyed a great dinner and chat with Robert, who’s one of the pivotal organizers of the DevConf event. A few photos from the DevConf presentation rooms. Notice the lack of a bowtie?
 

T-2 sleeps until the event begins

After a 23.9167-hour trip from Vancouver to Johannesburg I arrived at the hotel at midnight … followed by 24hours of no sleep, resulting in a few frazzled days. What I really enjoyed for the first two days was the downpour of large rain drops, lightening, and thunder … something we seldom experience in Vancouver.

Here are a few pictures to share the experience:

Flight from Vancouver to Calgary.

Connecting flight at my favourite Schiphol Airport. Noticed a strange plane in the background.

A bit of swag I packed – VSTS and DevOps stickers and a handful of quick reference posters that summarize key themes of our DevOps journey. My suitcase will never be the same again, after one of the Maple Syrup bottles imploded during the flight. 

It’s a sunny Saturday morning at the Birchwood conference centre, started with a healthy breakfast.

Plans for the weekend – meet with my good old friend Peter, with Robert MacLean who’s running the conference, and locate and secure some Biltong.  

At our Microsoft Vancouver office we have an area where engineers, working for remote teams, are gathered. We used to refer to ourselves as the "orphans", but recently pushed for a team identity.

We suggested and picked Ravens for two reasons:

1. “Raven symbolizes creation, knowledge, prestige as well as the complexity of nature and the subtlety of truth. He also symbolizes the unknown and is there to show that every person sees the world in a different way as another. The Raven is a long distance healer.” -  The Raven

2. Ravens == Remote and Virtual Engineers

Here are a few pictures of our area. Spot the Build Light monitor

Please visit our area and chat to us!

I’m Willy Schaub, I’m one of the Ravens, and sitting standing at #7L45.

I’m a senior program manager, responsible for the Visual Studio ALM Ranger program.

We provide professional guidance and gap-filling solutions to the developer community for Visual Studio.

Come directly to me if you need help with missing guidance or features for Visual Studio Team Services, or the internal Microsoft Ready event.]]> https://docs.microsoft.com/archive/blogs/willy-peter_schaub/turning-on-the-cold-for-tiago-welcome-to-a-vancouver Mon, 06 Mar 2017 07:32:06 GMT https://blogs.msdn.microsoft.com/willy-peter_schaub/?p=14885 We caught up with Tiago Pascoal (MVP, ALM Ranger) in Redmond, where he was recording Application Insight sessions and having lots of fun in the studio

It was an honour to welcome him in Vancouver for the weekend before he returned home. We started with a trip to Vancouver Island, enjoying the cruise, the fresh Salmon burger, followed by more food in the evening.

We should have realised that something was up, when we endured a strong, frisky, and freezing wind on the deck of the ferry.

It hardly ever snows in Vancouver, but on Sunday morning we had a surprise for Tiago.

We even crossed the harbour by sea bus across to North Vancouver, to present a stunning panoramic view of Vancouver to Tiago …

If all else fails, revert to food.

Tiago, THANK YOU for visiting the Schaub family on your way home. I hope you got a glimpse of Vancouver and enjoyed your weekend

Derek and I were hooked! We organised copies of the game for our Garage (a place for engineers to come together and experiment), started working through the game, and preparing to host games for our teams and the community.

Our first game after Ewald’s event

We agreed to these rules:

1. No changes to any of the work in progress (WIP) limits
2. Encourage DevOps 
3. Cleanup the board at the start of each new day

Here’s a snapshot at the start of our game day 10:

We encountered a few interesting events, which we’ll discuss later, and quickly realised that our first rule had a negative, and the second a positive side-effect. The third rule simplified the game by promoting consistency. It’s up to you to organise the board before, during, or after each day, just keep it consistent. 

Our cumulative flow diagram shows the flow of work over time. It highlights that we started (1) with far more work in progress (WIP), than we ended (2) with, one of the side-effects of not adjusting the work in progress limit.

And we achieved the following financial summary, which landed us in 29th position on Edwards list of game results:

We’ll definitely play the game again, fine tune our rules, and observe the side-effects.

Topics to discuss

Here’s a few topics we discussed during the game. What are your thoughts? 

Is it important to observe and adjust the work in progress (WIP) limits?

During the game we observed bottlenecks and resource wastage in our Analysis column, which resulted in the development and test resources sitting idle. We were unable to sustain the flow of work, as we intentionally did not adjust any of the WIP limits. It became painfully obvious to us during the game that we should be adjusting our WIP limits to sustain the overall flow of work. So, YES, it’s important to observe and adjust the WIP limits.

Interesting related reads:

• Work in Progress limits
• Kanban WIP Limits – The Fine Art of Focus

Should we care about blocked items?

During the game one of the work items was blocked and we had a vibrant discussion whether to unblock or simply ignore the blocked item. s the blockage occurred late in the game, affecting a medium value and ageing item, we agreed that to focus on the other work items and ignore the blockage. Had we not agreed not to adjust WIP limits, we would have increased the associated WIP limit to maintain the overall flow. Again this speaks in favour of monitoring and adjusting your WIP limits. In our case, we were unable to adjust the WIP limit, creating another bottleneck in the Test column.

So, YES, we should care about locked items. How we deal with the item depends on it’s value, our ability to resolve the blocker, and whether there are dependencies.

Interesting related reads:

• Moving Items Backwards on a Kanban Board … especially the “… tear up the card and reconsider the value and approach.  After that, the team can try putting it through again …” part.
• Dealing With Blocked Work Items In Kanban

Would you take a risk when you assign resources?

We had the scenario as shown above.

1. Item E1 was in the expedite lane, with five development units of work left.
2. Item S28 was a high value item, with six development units of work left.

Would you (a) commit two resources (2xdice) on E1 and one on S28, as shown, or (b) commit one resource (1xdice) on E1 and two on S28 to prioritise the oldest item?

We opted for option (a), prioritising the expedite lane. It also felt like the safest route, allowing overflow to be assigned to S28.

What’s the value of the Lead Time Distribution and the Run charts?

We maintained both charts for only half the game. We felt that effort to maintain the charts was higher than the value we got from the visualizations.

BUT, with more players, or in real-life (not in a game) and with more historical data, there’s a definite value in both charts.

Interested?

If you’re interested to enjoy a game of Kanban, please contact us and we’ll make a plan!

But, I’m off topic, because I wanted to share three great books we’ve been referencing in recent community talks. The books, available in electronic and printed formats, cover important topics: DevOps, Continuous Delivery, and Team Foundation Server (TFS).

“Writing, to me, is simply thinking through my fingers” - Isaac Asimov

Enjoy reading, what Wouter de Kort, Mathias Olausson, Jakob Ehn, and Tarun Arora were thinking through their fingers

The three gems

 http://a.co/bYJ0Om6, by @wouterdekort

As a technical reviewer for this book, I was party to to the structure and content, as well as discussions and revisions as it evolved. Wouter created an easy to read book, that walks you through Donovan Browns definition of “DevOps is the union of people, process, and products to enable continuous delivery of value to our end users”. It covers the basics of DevOps, planning, version control, testing, continuous integration, continuous delivery, monitoring, and much more. Its packed with concepts and practical exercises that enable you to embrace DevOps on the Microsoft Stack. Whether you have dabbled with DevOps, Azure or Visual Studio Team Services, or not, it’s a reference guide you’ll enjoy! – Willy

 http://a.co/2O4V8oa, by @molausson and @jakobehn  

This book is the authoritative source on implementing Continuous Delivery practices using Microsoft’s Visual Studio and TFS 2015. Microsoft MVP authors Mathias Olausson and Jakob Ehn translate the theory behind this methodology and show step by step how to implement Continuous Delivery in a real world environment. – Amazon

 http://a.co/agGjvrC, by @arora_tarun

This is a great book for people who want to introduce DevOps practices into their daily work, but don't have much time to dig all the details of how to do it; with the recipes delivered on this book you can quickly start using TFS/VSTS ranging from how to setup a team project, managing source code repositories, tracking work and building , deploying and testing your apps all in an integrated and cohesive manner. If you want to go beyond it will also help in managing TFS and extending it to integrate with other tools. Let's be clear this is not a reference book or a tutorial, but a great practical how to; even if you are new to TFS/VSTS you can use this book to learn in a practical how to get most of TFS/VSTS and how you can managed your process with it end to end. – Tiago Pascoal

“Honey, I shrunk the case”

At the MVP Global Summit I received another case from Anthony. We compared the two identically printed cases, which were definitely no longer identical, as shown.

Hypothesis - A shrink-wrapped 3D-printed gadget, stored in the luggage compartment of a trans-Atlantic flight, may result in deformation.You may have noticed that plastic water bottles are crushed after a long flight. When you open a bottle mid-flight to enjoy the content, air will replace the liquid. When you return to sea level the pressure surrounding the sealed bottle will increase. The plastic bottle, or in our case, the air-filled 3D-printed gadget may collapse as a result of the pressure imbalance.

Recommendation – Exchange 3D print files and avoid transporting 3D printed covers in the cargo hold. Most importantly, avoid shrink wrapping the cases, which appears to promote the ’'shrinkage”

Reference information - How Things Work: Cabin Pressure, Cabin air pressure

Raspberry Pi2 VSTS Build Light in its fancy new pyjama

Back in Microsoft Vancouver, the Raspberry Pi2 VSTS Build Light is back in operation, dressed up in its new case.

OK, now I have to figure out how to get the second case to Derrick Cawthon without it shrinking … and yes, how to turn our build status to green again.