Lately I’ve been thinking about inconsistencies or ironies in things developers say. I realize that’s pretty unusual for me, and you’re probably surprised that I would write about irony, or even recognize it when I see it. I can’t explain it. It’s just one of those things, you know. In any case, I’m thinking about irony in the sense of a definition I found via Google: “a literary technique, originally used in Greek tragedy, by which the full significance of a character’s words or actions are clear to the audience or reader although unknown to the character.” So, a lot…

Technical teams who are building or supporting application software usually work from a prioritized list of improvements, new features, and ideas to try out. (Scrum calls the list the Product Backlog.) They have a plan for completing the items on the list. Except in cases when the totality of the work is completely understood in advance, contemporary practice involves rolling-wave planning or multi-horizon planning in some form, whereby teams pull a subset of items from the top of the list and work out the details, rather than specifying everything in the plan in detail up front. That way, they avoid…

The Talk, The Presentation, and The White Paper First, we’d like to thank all of you that were able to attend Mike’s talk at Agile 2018. We know that it was a lot of information to digest, so we wanted to send you home with a little something extra to make sure that all the ideas and concepts remain fresh in your mind. That’s why we’re giving you his deck to take with you, and a white paper that will continue to build the case that a systems-first Transformation is truly the only option. If you weren’t there for the…

If you conduct hands-on technical training classes or workshops, you may have experienced some delay at the start of the session in getting all the participants configured and connected so they can start working. In my experience, it’s common to burn half a day and sometimes more dealing with setup and connection issues on everyone’s workstation or laptop. Strangely, even when participants are using similar equipment the gremlins of software and networking find ways to give each person a unique problem. Often, we have to call in a local expert to diagnose network issues. Trainers and consultants address the issue…

Organizations that build and support software have many unique challenges. They also have quite a few common challenges. One of those is how to help new technical team members come up to speed on the technical environment, coding standards, naming conventions, code base, build and deploy tooling, version control standards and conventions, and so forth. Not long ago, someone posted a question on Twitter to start a discussion: People replied with a number of suggestions, including: Diagrams Flowcharts (and a tool recommendation) The C4 Model Source comments Commit messages Overview of the code Where to find things How to run…