Sharing Our Passion For Technology
& continuous learning
  • Asking the Right Questions

    In a previous blog post, Brenda Peshak discussed the “Definition of Done”. As a team, we ran through an exercise to understand requirements and determine Minimal Viable Product (MVP). This got me thinking about real life examples of software and how decisions made by product owners and product managers directly...
  • Node Reference - Koa

    Prerequisites This article builds on the prior article: Unit Testing. Shift Left DevOps Before we write code, we look at first principles. A key principle is: “shorten feedback loops”. We can acheive this by automating the steps leading up to validating what we’re building. This is one reason we focus...
  • Done The Game

    I recently presented on the topic of Definition of Done at our Monday Meetup. The purpose of the game was to help our teammates understand what “done” means. As a product owner, I hear a lot of keywords thrown around in the Agile Development process; Minimum Viable Product (MVP), Minimum...
  • Can You Use Agile Techniques with Non-Software Projects?

    As an Agile coach, I am always reflecting on my experiences and looking for ways to help others improve. Recently I hired a contractor to complete a home improvement project. It didn’t go very well. Let me share what went wrong and how I think using Agile techniques would have...
  • 7 Ways To Go Beyond Your Agile Process

    Now that Agile has become mainstream, teams are looking to go beyond their Agile process to find ways to improve. There has even been recent use of the term “Antifr-Agile”, where process is secondary to product validation and customer learning (AgileDayChicago, 2016). Here are 7 ways that your team can...
  • The Day-to-Day Proof of Concept

    In the software world, there are often new technologies coming to market, new fields to explore, new techniques to use, etc. Filtering through these in itself can be a challenge. Deciding when to move forward with one in practical applications can be even harder. Many times as developers, we will...
  • Feedback

    One of the tenets of the agile methodology is feedback. To provide value to your customer, you need to know that what you are delivering is correct. But as an agile coach, I often struggle with teams understanding the importance of getting feedback from the customer as soon as possible....
  • A Better Analogy for Agile Software Development?

    For years, like many of you, I have been comparing software development to construction. But ever since adopting the agile methodology a decade ago, I have been looking for a better analogy to help me explain agile software development. I recently came up with what I think is that analogy...
  • Pain Driven Learning

    I find that in software development, and also in life, people learn best within the context of painful experiences. I’m not suggesting that software development mentors go out of their way to create painful experiences for their teams. On the contrary, just start listening. It doesn’t take very long to identify...
  • Agile Iowa No Estimates Puzzle Experiment

    I facilitated my own rendition of the #NoEstimates Puzzle Experiment for the September 2013 Agile Iowa user group meeting. This experiment was created by Chris Chapman to generate critical thinking and conversation concerning whether estimates are necessary to produce quality software. The meeting had a great turnout, with around 40...
  • Pragmatic Application of Principles

    I was reminded of a profound truth as I was re-reading Robert C. Martin’s book “Agile Software Development, Principles, Patterns, and Practices”, in C# this time. It is not wise to apply (a) principle ... if there is no symptom. In this section Uncle Bob discusses the Single Responsibility Principle...
  • What you missed at Agile 2013

    I was able to attend the Agile 2013 conference in Nashville, TN earlier this month. I had previously attended Agile 2006 in Minneapolis, MN. There was a significant difference. At this year’s conference, the overall theme seemed to be that teams needed to focus on producing value rather than following...
  • Agile Manifesto - Responding to Change Over Following a Plan

    Is it really possible that intense planning and the ability to respond to change can co-exist within the same development process? If you are wondering this, then you are not alone. Partners regularly ask us if Agile software development teams follow any sort of plan or are they just feel...
  • Agile Manifesto - Customer Collaboration Over Contract Negotiation

    Do you ever wish that companies would trust their employees and business partners instead of insulating themselves with contracts and policies?  For many companies, each discipline operates out of its own department requiring other areas to document exactly what they want and what they are going to do.  This provides...
  • ThoughtWorks releases ebook on Agile Project Estimation

    ThoughWorks Studios has released an ebook titled “How do you estimate on an Agile project?” where they explore common approaches and their adaptions from real-world projects.  The book is comprised of several authors, most notably Martin Fowler. In this ebook they discuss why teams estimate, different methods that teams use...
  • Agile Manifesto - Working Software Over Comprehensive Documentation

    Do you sometimes feel like your team spends more time documenting your system than building it?  One of the biggest hindrances to progress in a software project is documentation. The Agile Manifesto prescribes that teams should value working software over comprehensive documentation. It doesn’t mean that you should not create documentation;...
  • Agile Manifesto - Value individuals and interactions over processes and tools

    One of the biggest hindrances to progress in software projects is bureaucracy. Rigorous processes that must be followed unswervingly, deliverables changing hands between independent groups and required approvals – hand-offs, sign-offs, and stand-offs – all get in the way of software projects making valuable progress. So how would you change...
  • Manifesto for Agile Software Development

    How many times have you been presented with a phone book-sized printout of ambiguous yet carefully crafted requirements?  How many times have you, swamped with remaining work and short of time, camped in your cubical to meet a looming deadline?  Or seen your customers paralyzed by an approval process out...
  • Next Step in Agility

    I often find that teams that have adopted Agile practices quickly plateau. They often start by scheduling a daily stand up, planning in iterations, take time for a retrospective, and modify their estimation process. These are common first steps in the agile adoption process. Teams have varied success and commitments...
  • Pair Programming 101

    Overview Pair programming is a technique where two programmers work at a single work station.  One person “drives” or has control of the mouse and keyboard.  The other person “navigates” or keeps track of where they are and where they are headed.  This is a perfect environment for teaching and...
  • Agile Teams: Unequal and Opposite Reactions

    Newton’s Third law of motion,“To every action there is always an equal and opposite reaction…” is a powerful standard in analyzing team dynamics. I have been leading agile teams for over five years. When I am asked to lead a new team I begin by looking for reactions that are...
  • Agile Conversations

    Everyone, especially project managers, is in love with Agile Development. And why wouldn’t they be? Under the old school system, you’d end up with developers either sitting around uselessly, or drafting up prototypes that will only be thrown away. Agile allows for parallel design and development, wasting less time and...