Agility and Fear of Failure

We’ve likely all heard the famous line from Gene Kranz of NASA:  “Failure is not an option” with respect to the Apollo 13 space mission, right?  Well, most of us aren’t in a position where we are needing to navigate 3 people in a tiny, crippled craft back to Earth from the moon.  Many of us are writing business software.  Totally different challenge. 

In an agile mindset, failure is an option.  In fact, we should embrace the fact that we will fail…and when we fail, we want to fail fast

However, it is human nature to fear failure.  We all fear failure, both in our professional and personal lives.  I know I do.  What it is important to work towards, especially when working within the boundaries of Scrum, is learning that without failure you remain stagnant and possibly regress.  Without taking risks or pushing yourself and the team to try something new and different, you aren’t getting better, and you aren’t being truly agile.  After all, true agility is, at its core, about continuing to change and refine the way we work to improve it on all fronts – and this means taking risks on occasion to experiment with new ways of working.  If we let the fear of failure keep us from taking risks to improve, we are missing out on what agile can bring to us and our customers. 


The value of small user stories

There are a lot of good reasons to try to break down user stories into smaller ones (think INVEST model!), but here is one really compelling one:  the smaller your stories are, the more likely you are to complete them!  Here’s an example on how to think about it:

Let’s say your team looks at the backlog and says they can complete 5 stories in a given sprint.  Let’s say those 5 stories are somewhat large.  We’ll visualize the stories like this:


The sprint starts, and let’s say disaster strikes and we are only able to complete half of every story.*  At the end of our sprint, our stories might look like this (with green indicating completed work):


At the end of our sprint, we delivered exactly no value – zero completed stories.

But what if we broke all these stories in half?  We’ll start with this:


Same amount of work to be done, but we’ve spilt our stories out a bit more to a finer grain of detail.

Let’s say we have the same situation – a sprint starts, then disaster strikes, and we only finish half our work.  Our stories might look like this:


In this scenario, we finished the exact same amount of work, but were able to get 5 of our stories to completely done – we actually added value.

*Granted, this example is slightly contrived – completing stories also largely depends on how many stories you get in progress at any given time – which should be a small number – but the point remains – smaller stories let you get to “done” quicker, and ensure that a sprint delivers value.

What makes Scrum teams different?

I was in a daily standup last week watching a team that is reasonably new to Scrum, and witnessed a team start the path towards self-organization and collective ownership.  The conversation went something like this:

Bob the Developer: I’m finishing up coding that feature, handing it over to Joe to test this afternoon, and then I think I’m done with all coding work for this sprint.

Sally the Scrum Master: What will you work on after you give that feature to Joe?

Bob: Hmmm…well, I think I’ll swarm with Joe on testing that feature, and work with him immediately on any issues.  We will make sure it’s wrapped up and the product owner sees it too to get their feedback.

This response from Bob was very different than what he would have said 3 months prior.  3 months prior, his response would have been something like “I’m going to go look at the next feature” or “I’m not sure, I guess I’ll wait for a bug to show up”.   Bob had radically transformed his view on his role on the team, and was understanding that he was part of a collaborative group whose collective responsibility was to deliver to his customers.  He wasn’t there just to write code.  His role was now bigger than that. 

It’s this type of maturity that makes Scrum (and more generally, any flavor of agile) teams special and different from traditional waterfall “teams”, which are usually a collection of people with different goals, responsibilities, and probably work in different departments.  They aren’t populated with people who only want to live in their world.  They are cross-functional teams, with a broad range of skills and capabilities – but these people understand the goal of a Scrum team.  The team works together to achieve, even if that means doing something outside their core skills.     

The Scrum Guide states this very clearly:

Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

I’ll repeat that: Accountability belongs to the team as a whole.

This simple, but immensely powerful, concept is one of the core tenets of Scrum, and what makes Scrum teams special.

My ideal wearable

There is a lot of noise lately about wearables, from Google Glass to the Samsung Gear watches to the upcoming Apple Watch.  So far though, nothing is what I would consider worth me plunking down hundreds of dollars.  With CES 2015 going on right now, wearables, and especially watch-form factors, are looking to be a large part of the new gadgets that are making their way into the market this year.  

The show isn’t over yet, but here’s what I’m personally looking for in a smart watch wearable:

  • Built-in GPS with Garmin-like functions, so I can use it as a running watch.  I have a Garmin 620 now, and love it.  A smartwatch that could fill this role would be great.  Integration with a heart rate monitor too.
  • Stylish but rugged – if it’s going to be something I wear all the time and for running, it needs to be able to take a bit of beating and be…
  • Waterproof, and most certainly sweat-proof.  I should be able to run in the rain or swim with it also.
  • Phone capability – without an accompanying smartphone!  Paired with a very small Bluetooth ear bud for communication so I don’t have to look like Dick Tracy talking into my wrist.
  • SMS/MMS capabilities – receive/send texts and picture texts.
  • Application store/platform – for 3rd parties to integrate with.
  • Payment feature – support for paying for things.  (Apple Watch will have Apple Pay, so something like this)
  • Lightweight – shouldn’t be big or clunky, and weigh no more than your average watch.
  • Touchscreen – obviously.

And oh – battery life of at least a day.  I don’t mind recharging once a day – I take my watch off at night anyway – but even 8 hour battery life is too short. 

That’s all obviously a pretty tall order, and we are headed in that direction I believe, but we do have a ways to go before smart watch wearables are truly and incredibly useful.  Until then…we’ll be using multiple devices.     

Update: the Garmin Fenix 3 is getting close.

Broad range spectrum

One of the interesting parts about working in the software development industry is the simply massive range of tools, technologies, frameworks, components, etc that are available to do our jobs.  I did a quick survey, and at this given moment in time, we here at AgileThought have dozens of different items being used to deliver client service.  Here is a sampling – again, this is point in time snapshot – this is constantly changing, and in no particular order…(and I’m likely missing some too!)

  • .NET/C#
  • Visual Studio 2013
  • Java
  • Spring
  • Eclipse
  • Team Foundation Server 2013
  • Team Foundation Server 2013 Release Management
  • Specflow
  • xUnit
  • backbone.js
  • qUnit
  • SQL Server 2014
  • WS-Federation
  • Kendo
  • Windows Communication Foundation
  • AngularJS
  • SQL Server 2012 (including Analysis Services, Integration Services, Reporting Services)
  • SharePoint 2013
  • Entity Framework 6
  • Telerik components
  • Gradle
  • MySQL
  • Microsoft Azure (many different components both IaaS and PaaS)
  • Windows Service Bus
  • WebAPI
  • Foundation.js
  • Lineman.js
  • JSON.Net
  • StructureMap
  • AutoMapper
  • SlowCheetah
  • SeriLog
  • MSTest
  • NSubstitute
  • Xamarin.IOS
  • Xamarin.Android
  • Xamarin.Forms
  • MVVMLight
  • Sitefinity
  • Sitecore
  • Invision
  • Commerce Server
  • Knockout
  • Maven
  • Swing
  • JBoss
  • Apache
  • Grunt
  • Jasmine
  • Oracle
  • jQuery
  • PHP
  • Moq

Oh Windows Phone…

Dear Windows Phone,

I’ve been with you for a few years now…since the very beginning when you made the leap from Windows Mobile – version 7.0.  I’ve watched you grow up.  I’ve enjoyed your devices, and had 4 different models since 2010.  I am currently using a Nokia 1020, and absolutely love it, especially the camera, which is really the primary reason why I bought it.  I’ve taken some amazing photos and actually use the DSLR-level controls. 

I’ve upgraded my Nokia 1020 to Windows Phone 8.1, and Cortana…wow, you are amazing.  Your voice recognition is spot on, you answer my questions, do my bidding, and kick Siri’s butt every time and iPhone-using friend and I compare you two ladies.

For me, Kids Corner is indispensible…how have other platforms not adopted this type of feature?

And lastly, email and messaging (and Office docs) are where I live, and Windows Phone is an outstanding platform for those mobile interactions.

But what is killing me is apps.  I know, I know, the platform has nearly all the major mobile apps and popular games like Angry Birds and Words with Friends. (Although still a few big ones like Nook are missing that I could certainly use)  I’m not talking about those apps.  I’m talking about two other categories of apps: what I’ll call second tier apps and innovation apps.  Second tier apps are those apps you might get at a conference or maybe a franchise restaurant.  These are apps that are not intended for mass consumption by all, but targeted at a specific audience.  What I’m calling innovation apps are those that are doing something new and unique, but are often iOS only – for example an app like Pixotale.  These are the kinds of apps that are missing from this platform.  (In fact a few years ago I carried around an iPod touch just so I had an IOS device to run some missing apps on!)

I don’t know how to do solve this problem.  It’s not a problem of the platform not giving developers the right support.  I’d argue that for tooling and development support, Windows Phone is the industry technical leader. 

I don’t want to leave the platform, but the missing app problem is getting to me. 



What we do and don’t know about software development estimation

I am personally involved with software development estimation on almost a daily basis.  It’s a huge challenge that me and my team face.  We give the best possible expert opinion we can, and we often work with limited and fluctuating information.  We’ve learned a lot about estimating well, and we have a repeatable framework and guidelines established (which at their core rely on expert opinion).    

Given my experiences with software estimation, I believe that if you are involved with estimating software development projects, then you should read this new article from IEEE.  It very clearly and succinctly discusses the challenges and what we can do about them with respect to software estimation.  The bottom line is: it’s hard and we as an industry still aren’t great at it.  But we know what things we can do to make it better and we are working to continually improve.

If you aren’t doing some of the things that the article discusses, start doing them.  If you need help understanding these things – reach out to me – find me on Twitter or LinkedIn – I’d be happy to talk with you!