Print

Letters to the Editor: What kind of Scrum?



Email
January 15, 2012 —  (Page 1 of 2)
(Re: "Agile processes adopted widely; Scrum leads the way," December 2011, p. 20), many of the organizations I visit use "Scrum" as the catchall term for any Agile practices or approaches they've adopted. It usually means most (though not always all) of the 3-4-3 Scrum roles-meetings-artifacts, plus 10-90% unit test coverage and TDD, continuous integration, and other XP engineering practices, plus a variety of other practices to fit, e.g. ATDD, DDD, lean for managers, etc. I don't think you can draw the conclusion from survey responses about methods in use at all, particularly if you don't include an option of an agile "blended, home-grown" approach.
Diana Larsen
United States

Point/counter-point over functional programming
In the December 2011 issue, in response to Larry O'Brien's column, reader Dev declared that there was no functional programming bandwagon. "For more than 50 years, mainstream programmers always prefer a non-functional language. If you have tried to write non-academic programs in a functional language, you'll know why they present all kinds of hassles when dealing with simple things like files and file systems," he said.

Another reader, Mark, added this:
"The 21st century's signature contribution to mainstream programming: unit testing." What? Unit testing has been around forever (or at least for the 40 years I have been in the business).

Larry responds to Dev: It seems to me that there is a functional programming (FP) bandwagon: The influence in the .NET world is clear, with LINQ being a prime driver of the evolution of the .NET languages. In the Java world, I feel that there is industry motion toward Scala as the best "next Java."

As to whether FP is "superior" to object-oriented programming when it comes to mainstream enterprise development, or only excels in the algorithmic realms, I think that's a huge debate that the industry needs to have. My old construction was, "LISP has been touted in academia for 40 years, and everyone abandons it when they move into industry. Maybe that has some significance?"



Related Search Term(s): agile, John McCarthy, Scrum

Pages 1 2 


Share this link: http://sdt.bz/36286
 


Comments


02/29/2012 08:35:36 PM EST

Agile is not awalys implemented in a good way or at the point in the life of an application/product where it can be useful and not disruptive.Agile is chaos when it is implemented with the following being taken away:1. Complete requirements2. Use Cases (solely relying on 2-3 sentence user stories and NOTHING else)3. Documented architecture (which means it has not been through through thoroughly)4. Any kind of POC for brand new applications being started from the ground up5. Solution design (documented or not it is just gone start coding with that you have)6. Project Management: no milestones, no due dates, nothing7. Test Plans8. Test Cases (all adhoc testing)9. Scoping meetingsI work in chaos. Agile was implemented in the following manner:1. The people doing the work do NOT manage the work or the process. It is directed from the top down (meaning Director/VP is the scrum master).2. Retrospectives are a joke. No one talks about the elephant in the room because management is present in the meetings. All suggestions give that would actually help fall of deaf ears. Retrospectives are a way for management to communicate the changes in the process they feel will help but the decision was made without non-management team members input. Retrospectives are a way for the scrum master to ask leading questions to try and convince those who are doing the work to believe in the way he thinks it should be done.3. The management of the defect tracking process moved from the QA Manager to the Dev Manager.4. Scrum Master believes that one day programmers will develop code without defects and pays no attention to the increasing number of defects. Scrum Master only watches the burn down chart created off of story points from features and enhancements and does not take into consideration the number of outstanding defects.5. What has been developed during an iteration has NEVER been something that could have been released. Over 200 sprints on one product and the code has never been releasable.The result is releases have NEVER been on time (or even close) in three years. Working on a team that could succeed but have their hands tied by a so-called Agile methodology makes for increasing turn over rates, aggravated employees and generally un-happy people. And, by the way, no revenue is being generated!

Marshall IslandsSerdinia


close
NEXT ARTICLE
Agile leaders reconvene at Snowbird
Gathering will mark anniversary of signing as leaders review how far they've come and what needs to be done next Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
APRIL 2014 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?