I get often asked when I work with people or teach a class how to show real progress on an Agile project. Roadmaps, Release Burnup's, Velocity, how to answer questions on delivery. We build products for external clients using Scrum and will show people how we visualize progress sprint by sprint for our customers. Showing how velocity changes, roadmap, release plan changes and most importantly how customer feedback has affected the release date. This isn't hypothetical talk but real world experiences and conversations.

However, first I will start out with showing the old ways of doing things with Gantt charts. Why the traditional way doesn't work. Comparing the Green, Yellow, Red method and how it doesn't work. The roll that into the better, agile mindset of delivering questions like when will be done, what will we get and how we communicate good and bad news to our clients.

Pulling latest, performing a rebase but something goes wrong!  Where are my local commits?!? They are gone!!!  Use this guide to recover those local commits and save your day!

We've know it for a long time but if you were not aware, Ybor City in Tampa, FL is a great place to start and grow an IT business.

By using NSubstitute, we can easily test if a method is called even with complex parameters.

We often get asked what the differences are between a native mobile application and a hybrid one. I was starting to put down some notes on the topic when I came across an article that summed up my thoughts.  So I wanted to go through it and mention some key points.

Avoid all the Hyper-V nonsense when developing Android apps using Android Studio in Windows.

Recently, GitLab suffered a major outage (over 20+ hours) because of an accidental production metadata deletion by one of their developers.  An embarrassing situation for the developer responsible and the company as a whole.

Scrum isn't easy, but it's effective. One of the things that teams struggle with is a way to automate their testing and learning techniques like Test-Drive Development or Behaviour-Driven Development.  Both which can be implemented in both the back-end and the front-end code.

One team, I work with also automates the UI testing. One tool they use and they include as part of their Definition of Done for each feature is building a test automation using...

I just recently updated my Mac to Sierra and Xcode 8.2.1 and right away had issues connecting to the Mac using the Xamarin Mac Agent from my Windows PC.  I made sure that the versions of Xamarin on the Mac and Visual Studio on the PC were the same version but kept getting the error "Xcode license must be accepted in order to be connected and working against the Mac"

This is my second real world BDD examples that we use here at Clearly Agile. I've been given permission to share this piece of code from the client.

In this example, we have a scenario where a user can create something called a "Project" and it has to have a correct "Open Date". Which is when the Project is complete.

Over at toggl, they have a great infographic showing how you might build a car using waterfall vs. scrum vs. kanban vs. lean. We liked it a lot that we wanted to share... One of the best software development infographics around.

I thought I would share some of the real world examples of Behavior Driven Development patterns, or BDD. 

In my last post I talked about Estimating, and how I don't believe in the #noestimates movement for most situations. As previously stated, for my team, not estimating is not an option.Here you'll find some "What If" scenarios - demonstrating the clear advantages for estimating. 

What's with this whole #noestimates movement? It's a group of Agile enthusiasts advocating not to estimate and not 'plan out' work. Their reasoning: 'because the estimates are always wrong anyway'. I find this concept of not planning or estimating disturbing and unrealistic in most situations.

The Professionals are organized, communicate regularly, and go above and beyond, Amateurs do not. Now, the term "Amateur" here sounds condescending, but it's not meant to be. It is a state based in two orders: the persons' mindset, and secondly, what they physically can or cannot do. This concept also extends to programming, where we encounter the two types: Amateurs and Professionals.

In addition to the Amateur and the Professional types, there is a third type, verbosely named 'the Amateur Who is Called a Professional'. This third type has four subsets that are worth mentioning.

I've linked some information for those that are interested in learning more about the ethos of Pair Programming. For this post we are assuming you, the reader,  are either familiar or already use this technique. This post will introduce some ideas to improve your Pair Programming environment.

I've started to notice a disturbing trend with some Certified Scrum Trainers and Agile Coaches; this phenomenon generally occurs when I join a Team as their new coach. I've found that the teams' previous CST's or Coaches have laid the groundwork to use their own personal methods as Scrum gospel. The CST or Agile Coach has established that their own personal opinion is a requirement, a must, and the only way. This way of thinking contradicts the fundamental purpose of the Scrum Guide.  The correct way of thinking employs a comprehensive understanding of the Scrum Guides. If there is no definitive answer to the query at hand, then the CST should offer up possible solutions, noting which solution they believe, based on their experience, is best.