Posts

Showing posts with the label great teams

Working Well Enough: the Four Questions

The question asked was "how do we know we need a coach?" The more general question is "how do we know if we need help?" The question seems to assume that the goal of coaching and training are rescue; that the team is in trouble or incapable of success. That's horsefeathers. I think that the more valid question is "are we working as well as we can?" Here are my criteria for teams that don't need anything: We deliver Delivering software keeps getting easier We are always learning We have fun If all four of those are true for a team, then that team probably doesn't need help. Of course if those are true, then the team is poised to provide a lot of help to other teams by describing how they work.

Linear and Radial Progress: Take The Next Step

Today we didn't make a lot of linear progress I think of quality in two ways.  One is the product quality that users perceive, and the other is the habitability of the code itself. One says whether the function points and UX are well-selected, and the other says whether it is worth your time to try to work in the code.  One can have crap code that seems great externally, and one can have beautiful code that doesn't do anything a user is interested in doing (the popularly presented dichotomy). Likewise one could have poor functionality written poorly, or great functionality written well.  Those who consider themselves professionals in software craft will desire great functionally written well. I often get to work in code that started out as good functionality badly written. I get to work on the teams that clean up the mess and make the system more useful, scalable, and performant. As we work, the code gathers external quality. It becomes increasingly virtuous .  S...