Indeed, the most *productive* software team I have ever been a part of (with happy Product Owners being the measure) was a “lightweight methodology” shop. It was around 1995-1996 and the Developers took place in JAD sessions, delivered every week, and did an on-the-spot JAD session that was integrated at once and the project backlog recompiled to see where things stood. The office had cubes and was nothing like the “Agile Development Rooms” that you see today, but somehow that was not insurmountable. Imagine that. We had common areas, and people spent a lot of time in them. Tons of whiteboards. Tons.
Everyone was constantly talking. Resources *had to be* dedicated because we were too small and aggressive to keep track of things in a transferable manner.
Here’s the thing though: if we told a Client that we practiced a lightweight methodology that leveraged Rapid Iterative Prototyping (or worse, RIP), their eyes would glaze over. If we told them we would be there every week to work *with* them, their eyes would light up. The DEVELOPMENT BLACK BOX is scarier than tech lingo, which is scary enough that it elicits pretty strong emotion.
The point here is not the obvious point (avoid making things more complicated than they need to be). The point is that communication is the most important ingredient of any project. By communication, I mean dialog.
Now the “lightweight methods” have been sucked into the Agile Manifesto and the Manifesto has become the blessed vessel from which methodologies are ladled, branded, and sold. If you have ever played a game of checkers, been on a sports team, or been part of a club you have a good Agile foundation and IMO, can skip the whole Manifesto once you give it a good solid read and understand that there is a particular way of utilizing skills you learned in kindergarten that will let you be accepted among those who claim they detest process yet yearn for guidance.
From utility came formality came handcuffs with traditional IT PM. Let’s do all we can to avoid this and maybe stop calling it Agile. Just call it building software.
I am on a project now where if I were to try to inject full-blown Scrum, I would fail miserably – and not because of the Team. I would fail because what they do work well enough and the adoption of a new method is often seen as pure overhead with associated risk by the people who give the nod. In many cases, this is not incorrect or erroneous or due to lack of education. It is audacious to assume anyone knows a business better than the business owner who has dialog with people he or she trusts (domain experts) within the organization.
Still, day to day we are Agile. And we are getting things done because of the communication and the dialogs between the people who actually even go up and down stairs to get face time. We have become lazy in IT. We want frameworks for everything. Technical debt is not limited to hardware or code. It also applies to behavior.
Best,
Josh Milane