Showing posts with label waterfall. Show all posts
Showing posts with label waterfall. Show all posts

@since Tuesday, December 7, 2010

When Scrum will meet its death?

@throws 0 exception(s)
Hopefully soon.

Last week I read “What killed waterfall could kill Agile” post on “The Clean Coder” blog by Robert C. Martin (a.k.a. Uncle Bob). To quickly summarize the article, from my point of view: Building authorities over a process devoted to team decision might lead to the same dissatisfaction as it existed in the Waterfall process. While XP clearly indicates the development disciplines, Scrum seems like a buzz word for Project Management but misses the development part. Scrum Masters are usually Project Managers or Team Leader and the Scrum discipline drifts towards: managers - manage, developers - stay overtime to meet requirements.
My previews work place and at my current one, Scrum Masters are the team leaders. It’s not that they don’t manage Scrum, but don’t really care for code quality when tasks take bit longer than planned (ever heard the phrases: “We’ll write unit tests next iteration” or “We’ll get to that refactoring in future stories”). From my knowledge and understanding, the cost of refactoring poorly written code increases over time and adding too many coding patches can end up killing your product. Even so, every Scrum Master (or PM/TL wannabes) I met always tried to deal with my quality concerns by opening a bug/ticket to “track necessary changes” to modules we’re currently working on - but just complete the task (please!). My last work place even got to the low point of declaring that “team decides” is just a way to promote the process but we won’t follow it since the management will decide everything. Yep, they actually called the entire development group just to say - Fuck Scrum, we’re managers - you’re servants. Leaving me with the feeling that Scrum is a management process, not development process. 

Personally, I’m not a huge fan of processes (Agile Manifesto also states preferring people over process), but writing software in a team requires clear, shared guidelines. Software Craftsmanship is Scrums’ missing development disciplines. As a software engineer I want to dedicate as much of my daily work hours to do actual development. As a developer I want to be able to focus on delivering working, maintainable and reliable code. 5-10 minutes of daily Scrum meetings is the adequate amount of time developers should invest on project or task management. Developers should focus on delivering professional code - managers should focus on assisting developers doing so. Continuous Integration and Continuous Deployment methodologies allows developers to focus on code quality and less on the process. Write code, test it (unit, integration, system, functional) and fulfill your tasks as a professional developer.

At its current form, Scrum shouldn’t be kept alive. At Scrums’ current form we are still delivering medium software and call it Agile. If managers only wants to add another title (Certified Scrum Master) to their resume - fine. But don’t call your organization agile when you force your team to cut corners and deliver unmaintainable code base just so you can say we have a working product. I do wish to find a magical methodology that truly fits the needs of both software developers and project managers. So far, I haven’t found any.