Word of the Day: LINQ-Y

LINQ-y, what a great word!!

Getting More LINQ-y

To checkout later: Lambdas & LINQ in C# 

Web API 2 to MVC 6

Transitioning from ASP.NET Web API 2 to ASP.NET MVC 6

Well, isn't this interesting.  Redmond is insisting on keeping us on our toes!  My two favorite projects have been Web API 2 projects.  I'm looking forward to doing my first MVC 6 project!  :-)

No Estimates

No Estimates with Woody Zuill on .NET Rocks!

NDC 2014: No Estimates, Let's Explore the Possibilities - Woody Zuill

As my thinking has been leading me for the past few years.  What makes Agile truly successful is short iteration cycles, and business involvement.  Not project plans, but open, supportive, bi-directional communication.  And to this end the shorter you can make an iteration, the better.  Make a feature, show a feature, iterate on a feature, and deploy a feature. There is rarely a reason to group multiple changes in a release.  Pick the smallest feature possible, do it, iterate on it, deploy it.  Deploy daily, deploy multiple times a day!

Agile Culture

Today I made a series of Agile related re-tweets:

If you are not demoing at least once or twice a sprint... https://t.co/DJMgunP649

— Michael Randall (@mwrandall) July 1, 2015

If you are not doing meaningful retrospectives every single sprint... https://t.co/DJMgunP649

— Michael Randall (@mwrandall) July 1, 2015

If your burndowns and process prevents you from changing the length of your sprints or your team make-up... https://t.co/DJMgunP649

— Michael Randall (@mwrandall) July 1, 2015

I strongly believe that any step, and new attempted use of an Agile (or Lean) tool is a good thing. One gets better by thinking and trying, and then thinking and trying again.  So my thoughts on this are not a slam on anyone working on improving themselves or their team.  Instead, I'm just pointing out that "Agile" will only work to partial efficiency without these things.

In addition to the above thoughts, Design, Code, Release has another excellent post on Agile.

Each small change and evaluation of said change is a good thing.  Each small improvement should be celebrated and bring pride to your team.  However, no matter how Agile a development team (or even development department) is there will always be pain, there will always be a sense of beating a dead horse, unless the entire company is also Lean and Agile. This doesn't mean your first, or even twentieth thought, should be to bail on your company.  Instead one should always be working with their business contacts outside of IT to help them become more Agile.