|
If you've found a system that delivers a great product on time, then keep going. But formalize it, and get complete buy in from those running the show. We are talking about a repeatable and trackable process. With a well defined system, you simultaneously get visibility and accountability (for both the developers and product owner). Compare that to a software framework, where people have found enough commonality and repeatability to simplify and streamline how things get done. Why put in the effort required to learn a framework? It cuts down on time to market, cuts down on your lines of code (seems to be a debate about LOC benefits), and gives the team a single, well understood frame of reference. Having a process that is transferable between teams and companies makes the lives of everyone better, and gets us to past a lot of the overhead that leads to unfulfilled goals and unrealistic deadlines. What if your team grows to 4 people, and they all have their own idea of how to get stuff done? Without some formality, it becomes the wild west. What if you decide to leave, will you leave chaos in your wake? What if management keeps bugging you about getting stuff done sooner? If there is no well defined process, then management may be left believing the software team just isn't 'professional' enough to get things done. With a well defined and understood process, everything can be tracked and people can be made accountable for their choices. We aren't talking about a witch hunt, it will allow the company as a whole to grow and get better at defining what can be accomplished in what timeframe. If everyone agrees to abide by the process, but continually subvert it (1 + 2 = 4), then you can either suffer now (work 50+ hours a week), suffer later (build up of technical debt), or find somewhere to work values building really great software in a coherent manner. So what is Scrum? It's a process, as are Waterfall, RUP, and XP. Those of us that willingly practice believe it's a great way to achieve maximum visibility and minimize scope creep, all while reducing artifacts and overhead. It allows us to deliver value early and often. It gives developers the tools and justification to point and say "It can't be done given our constraints". Scrum is great for team ownership, and encourages us to get early feedback on features. Regardless of how you decide to get stuff done, make sure you have 100% buy-in from the people cutting the checks. This whole topic reminds of the discussion on designer pricing (http://news.ycombinator.com/item?id=3042803). We assume non-technical team members (our customers in many cases) implicitly understand what it takes to get a product shipped. We must do our best to bridge the gap between expectation and reality. |