On August 9, 2000, Joel Spolsky published the Joel Test, 12 yes-or-no questions used to score a software development team or organization. Joel described a score of 12 as “perfect”, 11 as “tolerable”, and 10 and lower as indicative of “serious problems” in the organization.
20 years later, how has the Joel Test aged? Is it still useful to assess development teams? Or has the passage of time caused the test to become irrelevant?
The 12 questions of the Joel Test are:
Do I need a software development life cycle? What are the stages, phases, or steps of the SDLC? What is the difference between SDLC and Waterfall? What is the difference between SDLC and Agile?
I’ve seen questions and answers about the software development lifecycle that are rooted in misconceptions and misunderstandings. Too often, software development happens within frameworks that come with roles, responsibilities, and activities. The frameworks get in the way of common abstractions and commonalities, and misconceptions about the software development life cycle make it challenging to have discussions about how organizations design, build, test, and deploy software systems.
Here, I try to dispel a few of the common misconceptions that I’ve seen. …
I entered the world of agile coaching from standards and compliance-based software process improvement. After reading several recommended books and articles, I noticed that a common theme in agile coaching is the use of different stances. Although the idea of using stances to guide the approach to interacting with individuals, teams, and organizations appealed to me, the books and articles were light on guidance on choosing a specific stance.
One paper, Choosing a Consulting Role: Principles and Dynamics of Matching Role to Situation, by Douglas P. Champion, David H. Kiel, and Jean A. McLendon provided the insight I wanted.
I saw parallels between the consultant-client relationship and the relationship between an agile coach and the employing organization. This paper also introduced the consulting role grid, a grid of roles, and representative statements of those roles. The x-axis is the responsibility for project results, and the y-axis is the responsibility for client growth. Throughout an engagement, the consultant may play several roles. The consultant considers factors including the characteristics of the client and consultant, the relationship between the client and consultant, and the organization’s needs when choosing a role. …