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. 

I had the pleasure to work with The Braintrust Group and review their book to provide feedback and editorial comments. It has now been published up on Amazon. I definitely would recommend this book for anyone new or experienced with Scrum. It has a lot of interesting tips and real world problems/solutions as well as pitfalls to look out for....The great thing about the book is that the word "software" isn't used once.