The Land that Scrum Forgot

14 December 2010

Forward by Mike Cohn

Scrum is a starting point. In fact, it’s a great starting point. But, as a framework rather than a full-blown methodology, Scrum is deliberately incomplete. Some things—such as the best technical practices to use—are left for individual teams to determine. This allows a team to create the best fit between their project and environment and an assortment of technical practices.

While that selection of practices should belong to the team or organization rather than to a group of methodologists, the benefits of some practices are becoming so compellingly obvious that they warrant consideration by any Scrum team. But, too many Scrum teams become complacent after achieving some early productivity gains with Scrum. And they stop seeking ways to improve. Many fail to try the technical practices necessary for long-term success. In the following article, Robert Martin (perhaps better known as "Uncle Bob") tells us why so many Scrum teams fail to sustain the promise of their early successes.

Bob’s article is the first in a series of articles we will publish in this newsletter. Because Scrum is a starting point with deliberate gaps to be filled by knowledgeable teams, we are looking to those outside the core Scrum community to provide advice to those of us within it. What do leading agile thinkers from outside the Scrum world think our teams need to know or do? I’ve asked a few to share their thoughts with us. And who better to start with than Bob Martin?

 

The Land that Scrum Forgot
By Bob Martin

What goes wrong with so many Scrum projects?  Why does the velocity start out high, but then precipitously decline?  Why do some Scrum teams eventually give up on Scrum?  What’s going wrong?

As someone who has been called in to rescue Scrum teams from this kind of demise, I can tell you that the problem is not that the teams are losing motivation.  Often the problem is that the software that the teams are producing is getting harder and harder to work with.

Scrum makes you go fast!  That’s a good thing.  Often the first sprint concludes with some working features.  Managers and customers are happy.  The team has worked a miracle and is happy too.  Everybody is happy, and Scrum is seen as a great success.

The same thing happens the next sprint, and the sprint after that.  Velocity is high.  The system is coming together.  Feature after feature is working.  Expectations have been set.  Plans are made.  Enthusiasm for Scrum soars.  Hyper-productivity has been achieved!

One of the reasons for this hyper-productivity is the smallness of the code base.  Small code bases are easy to manage.  Changes are easy to make; and new features are easy to add. 

But the code is growing fast; and when a code base gets large, it can be very difficult to maintain.  Programmers can be significantly slowed down by bad code.  Teams can be reduced to near immobility by the sheer weight of a badly written system  If care is not taken soon, the hyper-productive scrum team will succumb to the disease that kills so many software projects.  They will have made a mess.

“Wait,” I hear you say.   “I thought Scrum was supposed to empower the team?  I thought the team would take all necessary measures to ensure quality.  I thought the an empowered Scrum team would not make a mess.”

That’s certainly the goal.  The problem is that empowered teams are still human, they do what they are incented to do.  Are they being rewarded for quality?  Or are they being rewarded for productivity?  How much recognition is the team getting for good code quality?  How much are they getting for delivering working features?

There’s your answer.  The reason scrum teams make messes is because they have been empowered and incented to make one.  And a Scrum team can make a mess really, really fast!  A Scrum team is hyper-productive at making messes.  Before you know it the mess will be “so big and so deep and so tall, you can not clean it up. There is no way at all.”

And when that happens, productivity declines.  Morale goes down.  Customers and managers get angry.  Life is bad. 

So how can you incent a Scrum team to not make a mess?  Can you simply tell them not to make a mess?  We’ve tried that.  It doesn’t work.  The incentives for going fast are based on tangible deliverables.  But it’s hard to reward a team for good code If we don’t have some way to objectively measure it.  Without an unambiguous way to measure the mess; the mess will be made.

We need to go fast, and we need to stay clean so we can keep going fast.  How can we incent the team to achieve both goals?  Simple.  We measure both and reward them equally.  If the team goes fast but makes a mess, then there is no reward.  If the team stays clean but goes slow, then again, there is no reward.  If the team goes fast and stays clean, then there is a reward!

We can measure messes by implementing engineering disciplines and practices like Test Driven Development (TDD), Continuous Integration, Pair Programming, Collective Ownership, and Refactoring; i.e. the engineering practices of eXtreme Programming (XP).

It is usually best to start with TDD simply because a code base without tests is a mess no matter how clean it might otherwise be.  This is a bold claim, but it is based on a solid rationale from a much older and more respected discipline: accounting.  It is just as easy for an accountant to make a mistake on a spreadsheet as it is for a programmer to make a mistake in a program.  So how do accountants prevent errors?   They enter everything twice. 

Accountants practice Dual Entry Bookkeeping as part of the GAAP1 (Generally Accepted Accounting Principles).  Accountants who don’t hold to the GAAP tend to wind up in another profession, or behind bars.  Dual Entry Bookkeeping is the simple practice of entering every transaction twice; once on the debit side, and once on the credit side.  These two entries follow separate mathematical pathways until a final subtraction on the balance sheet yields a zero.  A set of books that is not supported with dual entries would be considered a mess by the accounting community, no matter how accurate and clean those books were.

TDD is Dual Entry Bookkeeping for software, and it ought to be part of the GAPP (Generally Accepted Programming Practices).  The symbols manipulated by the accountants are no less important to the company than the symbols manipulated by the programmers.  So how can programmers do less than accountants to safeguard those symbols?

Programmers who practice TDD create a vast number of automated tests that they keep together and run as a regression suite.  This is something you can measure!  Measure the coverage.  Measure the number of tests.  Measure the number of new tests per sprint.  Measure the amount of defects reported after each sprint, and use that to determine the adequacy of the test coverage.

The goal is to increase your trust in that suite of tests until you can deploy the product based solely on whether that suite passes.  So measure the number of “other” tests you feel you need perform, and make shrinking that number a priority; especially if they are manual tests!

A suite of tests that you trust so much gives you an immense amount of power.  With it, you can refactor the code without fear.  You can make changes to the code without worrying about breaking it.   If someone sees something they think is unclear or messy, they can clean it on the spot without worrying about unintended consequences.

Undocumented systems, or systems where the documentation has gotten out-of-sync with the production code, are messy.  The unit tests produced by TDD are documents that describe the low level design of the system.  Any programmer needing to know how some part of the system works can reliably read the unit tests for an unambiguous and accurate description.  These documents can never get out of sync so long as they are passing.

Measure the size of your tests.  Test methods should be on the order of five to twenty lines of code.  The total amount of test code should be roughly the same as the amount of production code. 

Measure test speed.  The tests should run quickly; in minutes, not hours.  Reward fast test times. 

Measure test breakage.  Tests should be designed so that changes to the production code have a small impact on the tests.  If a large fraction of the tests break when the production code is changed, the test design needs improving.

Measure Cyclomatic Complexity.  Functions that are too complex (e.g. cc > 6 or so) should be refactored.  Use a tool like Crap4J2 to pinpoint the methods and functions that are the worst offenders and that have the least test coverage.

Measure function and class size.  Average function size should be less than 10 lines.  Functions longer than 20 lines should be shrunk.   Classes longer than about 500 lines should be split into two or more classes.   Measure your Brathwaite Correlation3, You’d like it to be greater than 2. 

Measure dependency metrics.  Ensure there are no dependency cycles.  Ensure that dependencies flow in the direction of abstraction according to the Dependency Inversion Principle4, and the Stable Abstractions Principle5. 

Use a static analysis tool like FindBugs6 or Checkstyl37 to locate obvious programming flaws and weaknesses.  These tools can also find and measure the amount of duplicate code.  

Implement Continuous Integration.  Set up a build server like Hudson8, Team City9, or Bamboo10.  Have that server build the system every time a developer commits some code.  Run all the tests on that build and address any failures immediately.

Measure the number of commits per day.  This number should be larger than the number of developers on the team.  Encourage frequent commits.

Measure the number of days per month that the continuous build fails.  Reward months with no failures.  Measure the amount of time failures remain unaddressed.   

Story tests are high level documents written by business analysts and testers. They describe the behavior of the system from the customer’s point of view.  These tests, written in a tool like FitNesse11 or Cucumber12, are requirements that execute.  When these tests pass the team knows that they are done with the stories that they describe.

Measure done-ness by running story tests in your Continuous Integration system and keeping track of the story tests that pass and fail.  Use that as the basis for velocity and the progress of the team.  Enforce the rule that stories are not done until their corresponding story tests are passing.  And never let passing story tests break. 

Practice Pair Programming.  Measure the time spent pairing vs. the time spent programming alone.  Teams that pair stay cleaner.  They make fewer messes.  They are able to cover for each other because they know each other’s domains.  They communicate with each other about designs and implementations.  They learn from each other. 

And after all this measuring, how do you reward?  You post big visible charts of the metrics in the lunchroom, or in the lobby, or in the project room.  You show the charts to customers and executives, and boast about the team’s focus on quality and productivity.  You have team parties to celebrate milestones.  You give little trophies or awards.  For example, one manager I know gave shirts to everyone on the team when they passed 1000 unit tests.  The shirts had the name of the project and the words “1,000 Unit Tests” embroidered on them.

How do you keep a Scrum Team from losing productivity?  How do you make sure that hyper-productivity doesn’t veer headlong into a quagmire?  You make sure that the team is not hyper-productively making a mess! You make sure they are practicing the disciplines that produce data that can be measured. You use that data to measure the quality of the code they are producing; and you provide incentives for keeping that code clean.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.7 (10 ratings)

Comments

Scott Griffith, CSP,CSM,CSPO, 1/18/2011 3:11:10 PM
Thanks a lot Bob (and Mike) for this informative article and the courage to admit that Scrum is not enough. I especially appreciate the comment that because Scrum teams are so fast they can make a mess faster and bigger than other teams! This has been my experience also with teams I've worked with over the last eleven years. Many managers and executives I've dealt with have blamed Scrum for the mess, so I had to show them that Scrum actually highlighted the mess better than a waterfall process does. Scrum is great for revealing organizational dysfunctions. Thanks again Uncle Bob for giving solid advice with links to tools are how to address the development dysfunctions.
Radu Davidescu, CSM, 1/26/2011 8:52:50 AM
Excellent article and a good collection of tools that help to sustain best practices. It is very handy for Scrum teams to review their practices and tools. It really fills a great gap in the "deliberately incomplete" parts of the Scrum.
Who will be invited to write about management in Scrum?! I have a good feeling and a good book that was just been delivered from Pearson.
Martin Alaimo, CST,CSC,CSP,CSM,CSD,CSPO,REP, 1/27/2011 10:43:30 AM
Great article Bob. I've found some Scrum teams blaming short iterations because they didn't give them enough time for regression testing. As the product became bigger they needed bigger regression efforts because the delivery of features breaking other features started showing out. The trend was leading one of those teams towards a "Testing Sprint" approach (ouch!). (A)TDD+Continuous Integration helped a lot in reducing this cases, and getting those teams re-embrace Scrum.
Rodrigo Alfonso, CSM, 2/9/2011 8:13:20 AM
This is a great article, you've put in words the one thing I always thought Scrum was missing. From a developer standpoint I feel that good quality code is as important as a timely delivery, even though many times it's perceived as something superfluous. Congratullations on a great article! :-)
James Peckham, CSP,CSM,CSPO, 2/12/2011 11:21:53 PM
Great article. I could not agree more. We all need to help pick good engineering practices to put in our definition of done at the start of projects and keep adding more as we can to hone in on the right level of quality for the expected lifetime and criticality of the software.
Mikkel Bo Rasmussen, CSM,CSPO, 2/18/2011 3:30:05 AM
This is brilliant! The accounting analogy is just what I needed for making the case for TDD. People, both managers and developers, sometimes think that now we are using Scrum everything will be fine. But there is still a lot of challenges and obstacles to overcome and TDD + CI help a ton. My challenge has always been to convince people of the value of TDD (and BDD for that matter).
Khushru Doctor, CSM, 2/23/2011 6:18:34 AM
Great Article. It made the understanding so easy. The article also brought out a very important fact that it is not just important to know and understand the salient features of a development methodology and implement it but it is equally important to find out the weak areas of a methodology the weakness and the breaking areas and to fix them as we proceed. Brilliant reading should be included in all SCRUM primers.
Khushru Doctor, CSM, 2/24/2011 12:43:42 AM
In in one of our projects (Project S) we have joint development being done by Cybage and an Offshore organization team. The product is currently being enhanced with new features. Three week sprint cycles have been implemented stringently for over 6 months. A well-defined prioritized product backlog is maintained by product owner in form of user stories. A joint planning meeting is held at the beginning of the sprint wherein team estimates the stories from the prioritized backlog by playing planning poker which works really well. We have a simple excel template that is used to create sprint backlog and monitor the burn down.

There is a clear mandate from the product owner that the focus is not to get high velocity but doing things right! They are happy to carry stories forward rather than pressurize team to complete stories within the sprint. Very well defined Definition of Done is in place that the team has to adhere religiously.

CruiseControl.Net is implemented for continuous integration ΓÇô a build is created every time a developer checks-in code and in case of failure a message is sent to target audience indicating the failure. CruiseControl.Net generates a report after every build providing various statistics like warning count, average code complexity, no. of complex and very complex methods, code comment ratio and list of most complex methods (that can be scheduled for refactoring). Team monitors the target measures for these metrics and celebrates achievements and warns in case there is a dip.

Unit tests are written along-with development and is monitored through test coverage covered in report generated by CruiseControl.Net.

TFS is configured for nightly build generation. Prioritized test cases are being automated using VSTS. Automated tests are executed on these builds. Going forward the plan is to integrate this with TFS lab manager which will allow automated scripts to be scheduled for execution of defined environments, send messages on build failures and logging of tickets.

This was shared with me by my Project Manager Anita Upadhyay who is also a CSM
Thomas Juli, CSM, 3/3/2011 1:24:29 AM
So much can be said: BobΓÇÖs article is convincing. It is important that we need to keep our teams go fast and stay clean. However, is measuring productivity and rewarding teams at the core of re-aligning flagging teams?! I donΓÇÖt think so. What I think causes declining productivity and a deteriorating team morale along with lower quality deliverables is often an imbalance of the factors that ensure project success. Let me tell you what these factors are and how you can find out if your own team fulfills these preconditions for success.
First, the team needs to have a common understanding of the project vision. A project vision goes beyond project objectives or in the case of Scrum it goes beyond the Sprint or Product Backlog. A vision defines the purpose of the project or product in the first place. We all know that requirements change throughout the lifecycle of a project. The vision is less prone to changes. The key is that the team understands and lives the vision. For this to happen they need to be able to relate to the vision in its daily project life. It needs to motivate and drive their activities.
Second, effective collaboration is not static. It needs to be nurtured. Just because you have a performing and hyper-productive team in one sprint doesnΓÇÖt guarantee that this will go on forever. Collaboration has to be nurtured on an ongoing basis for it to bear the desired fruits which is a high-performance team.
Third, performance is important and it needs to be promoted. This is where BobΓÇÖs list of engineering practices comes in very handy as they help promote performance on the individual and team level.
Fourth, ongoing productivity and performance require reflection and continuous improvement. Create a culture of learning in your team. Often teams neglect proper regular retrospectives or lessons learned sessions. The momentum and excitement of the beginning have flattened. In such a situation I recommend to bring in an outside person to facilitate a lessons learned workshop and review the work of the team. It is necessary and laudable that the team holds regular retrospectives. This is no substitute to conduct external project reviews. Provided they aim to identify ways and means to boost productivity and performance of the team.
Fifth, ensuring ongoing results should be a given in any Scrum team. But is it really? How tangible are our deliverables? And how much value to they add to the customer? Do they really delight the customer? Have we lost touch with the customer? Are the deliverables in sync with the overall vision of the project and/or product?
All of these 5 principles have to be balanced. It is not that there is one principle which is the most important one. They all have to be balanced. And it is up to the team to do so. If the team cannot see the trees in a forest, someone has to stand up to this task. It is a question of leadership and it is a question of success.
To learn more about what it takes to re-align a weary scrum team, read book ΓÇ£Leadership Principles for Project SuccessΓÇ¥ (CRC Press, 2011), my blog (www.thomasjuli.wordpress.com) or contact me directly.
Sriram Somayajula, CSM, 3/4/2011 12:32:26 AM
A great article and it is very important for the teams to go fast and yet stay clean! It explains the core reasoning behind following TDD and it's benefits.
Sachin Kundu, CSM, 3/4/2011 3:33:44 AM
Ah Robert,
I have been thinking about a model of successful software development and came up with

1. Deliver value consistently or increasing.
2. Keep a low defect rate
3. Keep the motivation high

In this framework, I demand the two from my team and do everything under the sun to give them the third. works quite good.
Arijit Sarbagna, CSP,CSM, 3/5/2011 5:11:43 AM
Excellent article! I am part of an agile project - running successfully for over 3 years now & we save ourselves from the burnouts - mostly by using the followings:
(1) Multiple points of automation (e.g. testing/building)
(2) Number of team building activities
(3) Rotation amongst team members

As very correctly mentioned, we are also working in lines of putting some measuring tools - towards tracking defect density - which in turn will help us gauge how the development enthusiasm is going up/down. :D We are also planning towards studying the effectiveness of Peer Review. I will love to know if someone has already done so...as it may be really beneficial to put a base line on peer review effectiveness. An thoughts?

Thanks & regards
Rosa Rivas, CSM, 3/8/2011 3:38:45 AM
Arijit, in my organization Peer Review is a requirement for every done check-in. We use TFS where we specify stimated hours, remaining hours, programmer and code reviewer for each programming task. You can set out this from different points of view:
- Whether you "use" as code reviewer a very experimented programmer, so he/she will correct errors and even prevent bugs.
- Or you can do Peer Review within programmers "on same level", so they learn from each other (as someone else has already said) and let their programming-minds grow.

Great article and great comments!! Thanks a lot guys!
Rahul Guha, CSM, 3/9/2011 8:19:13 AM
Thanks Bob for such a truthful article. And I think each of us who ever practiced SCRUM/XP in our projects, faced each of these issues.
Fact is - there is NO "Silverbullet" which does the magic ... not even SCRUM - because it all depends on how do u practice it.

In my experience, CI helped tremendously to keep ourselves honest.
However as I think there is a fundamental problem on how we measure quality as it's measured as "failures" not as "success" - in other words, people are suppose to get punished for "defects" but no donut for right way of working. And we all know how difficult the "right way" is ...
I think it's a real challenge to create some metrics which will capture "right way" and simple enough to be understood by executives and management :)
Bottom line "how much quality" is good enough? How do we protect ourselves from "analysis paralysis" or huge "technical debt" ?
Cheers .... Rahul
Andreea TOMOIAGA, CSM, 5/30/2011 11:51:03 PM
Hi Bob and all, I enjoyed both the article and the comments. In any project regardless of its stage I do believe that XP technical practices are useful and help improve the quality of the projects. In my opinion the number of failures can be seen as a measure of success - if they really decrease in time, even at the expense of having a lower velocity for several consequent sprints. I am referring especially to larger projects which require adaptive maintainance on long term and where, at an initial stage, codebase is without tests at all. Bug tracking systems like JIRA are full with all sorts of bugs and even requests for festures and clarification in some cases. Starting from there and applying XP technical practices improve codebase quality, less bugs means even more motivation. In my experience so far I found the following software quality measurement tools effective, too:

PMD: http://pmd.sourceforge.net/
Sonar: http://www.sonarsource.org/

Best regards
Andreea
Douwe Attema, CSM, 7/13/2011 9:29:46 AM
At the end of the runway it is always bad. So do not land at the end of the runway where it is a mess. Or it is a hole or trees where you are landing. To not make a mess you should take your plane on the ground.

Great Article, but also true do not blame scrum for the mess, but there should be moments to constant improve the way teams work together most important on team communication and testing parts

Best Regards,

Douwe Attema
Randall Schmidt, CSP,CSM, 10/5/2011 12:15:56 PM
Awesome read, thank you for taking the time and effort to share.
Paul Mahoney, CSP,CSM, 10/28/2011 3:37:46 PM
Bob and Mike,
Thank you for making available a single location for the sharing of thoughts and ideas. This is a great article and a wonderful reminder to all of us that agile is a living philosophy that depends on the concept of continuous improvements. Agile is not a static process but one the continues to move and improve.
Paul
Anurag Kapur, CSM, 11/14/2011 6:04:44 PM
Wonderful read!
Lucas Videla, CSM, 12/8/2011 2:22:29 PM
That was a great article, Bob! Thank you for sharing these idease. We are going to implement some of them (but starting with one, of course)
Best regards, Lucas
Timothy Korson, CST,CSP,CSM,CSPO, 1/27/2012 2:34:38 PM
WARNING! Metrics are almost as dangerous as messy code. But as problematic as they are we unfortunately can't be professionals without some visibility and control of otherwise invisible properties of our systems. I would urge teams to collect and use whatever metrics they need (and I like many of Bob's), but I would caution against rewarding teams based on surrogate metrics. Everyone should keep an eye on the team metrics dashboard, but I would hate to incentivize a team to keep the needles within prescribed ranges.

Make sure that any team incentives are based on long term velocity - or better yet, use the least disruptive form of incentives - profit sharing.
David Osborne, CSM, 2/6/2012 1:12:38 PM
Very good real world article.

Unit testing is critical to keeping code clean and tight. Often the developer is ready to hand off his/her code too quickly before ensuring a comprehensive unit test has been completed. This impacts QA testing and eventually may compromise reaching sprint goals.

I like the idea of unit testing and paired programming as checking mechanisms for producing more accurate code. I believe this is an area that is sorely under-represented in the project life cycle.
David Osborne, CSM, 2/6/2012 1:14:51 PM
Very good real world article.

Unit testing is critical to keeping code clean and tight. Often the developer is ready to hand off his/her code too quickly before ensuring a comprehensive unit test has been completed. This impacts QA testing and eventually may compromise reaching sprint goals.

I like the idea of unit testing and paired programming as checking mechanisms for producing more accurate code. I believe this is an area that is sorely under-represented in the project life cycle.
Bikash Sahu, CSM, 2/17/2012 12:38:48 AM
Awesome
MVP Raviram Naidu PMP,CSM, CSM, 5/2/2012 8:50:26 PM
Great article and the tools mentioned really help to sustain best practices. It is very true that the scrum team lose the motivation sprit as the Sprint progress. But the mentioned tools are very handy for Scrum teams to review their health of the code and motivation index.
Kapil Dua, CSM, 5/10/2012 2:46:28 PM
Really useful article. The idea about establishing a quantifiable mechanism of rewarding right practices goes a long way in keeping scrum team motivated and hence successful. The author puts up a really strong case for use of extreme programming in a scrum team. Thanks for such useful insights.
Sanjit Tiwari, CSM, 5/12/2012 5:26:27 PM
I am new to Scrum. This article is like a note of cuation of what I should on the lookout for. Thankyou Bob.
Francois Herrault, CSM, 5/25/2012 3:12:49 AM
Very good article, but I am missing one important point in it. Even if TDD and unit tests are a good thing, having 100 unit tests for 10 different classes that should not be there in the first place, is useless.
Architecture and overall design work are not named in the article. Why not? As a stakeholder (who knows about software development), I would be skeptical to a team that produces a "working" function, on bad software code that would need to be thrown away right away, or worse, that developers would try to cop with for months ahead. And splitting large classes into small ones is not enough. Object Oriented design is much more than that.
 
I don't want a heavy design phase as in the waterfall methodology, but some architecture and design work must be achieved from the beginning.
Rahul Joshi, CSM,CSD, 5/29/2012 8:55:23 AM
Very good article providing a word of caution for not getting into mess that can arise due to not tending to the most essenstial thing of development that is quality. I have one question pertaining to the mesaurement of unit test cases. How is it possible for one to track how many test cases(Not Test Classes) one has written in a sprint? Can it be automated ? Thank you Bob and congratulation on this wonderful article.
Sasi Marian, CSM, 7/13/2012 1:51:14 PM
Great article, thanks. You have given a good number of tools to monitor and reward. However, I have a use case that your article did not cover, I guess. Many projects go mess when programmers mishandle data in memory or in database or data store. If the unit of work isolates those data they are clean. When the new requirements come in without seeing the whole picture or due to pressure programmers do quick fix and start messing. My question is that is there any tool to find this? Further, all unit tests will pass, integrated tests will pass.
When many are working in parallel ie in production, it will fail. It could be due to design problem or implementation problem.
Prasadbabu Lagu, CSM, 9/29/2012 7:21:42 AM
Thanks Bob for nice article. I've implemented 'Pair Programming' with junior most resources in my team and it is giving me very good results.
Sriram Jagadeesan, CSM, 12/14/2012 3:21:06 AM
Read it early on 2011 and I read it again few days ago, Must say that it is an ever green article.
Vladimir Ignatev, CSM, 12/21/2012 8:53:26 AM
Добавил перевод топика на русский язык: http://joydevel.blogspot.ru/2012/12/the-land-that-scrum-forgot-scrum.html

На Хабре: http://habrahabr.ru/post/163413/
Yunfeng Bai, CSM, 12/26/2012 2:34:50 AM
A great article which helps Scrumers to learn about how to avoid Scrum practices failed in mess. Scrum provides powerful methodology to build up a hyper-productive team with continuous incremental product deliveries, but we still need to leverage other practices to achieve measurable and sustainable goals.
Praveen Prakash Pallakad, CSM, 1/10/2013 11:52:37 PM
Firstly a big thanks to Bob for sharing the article! It gave a whole new insight on some of the widely accepted practices in maintaining cleanliness of code while ensuring that productivity and morale of team in not compromised. Unit testing is a practice that we (my team) is putting in place and are trying to religiously follow the same. We are already feeling the difference and hope to keep improving on the same. Looking forward to more such insightful articles. Cheers!!
Andres Iglesias, CSM, 1/12/2013 11:55:24 AM
Nice article. It shows perfectly that Scrum by itself it's not the solution to everything and that it should be used together with other practices.
Dhamodharan Pandurangan, CSM, 1/13/2013 8:58:54 AM
That was an excellent article. It clearly shows the downsides of Scrum, if not handled properly. I completely agree on XP and continuous integration and their success metrics.



The bigger challenge I have faced is keeping the TDD in tact with all the scenarios. When complex flows are involved, programmers tend to miss/not cover them in TDD which would cause disaster, needed manual intervention once the code is grown big. Continuous integration and building the code twice a day to check who has committed a code with error, helped to raise big alert system within team.



Continuous review on test metrics and keeping the error count low helped improve the situation sprint after sprint.



I have even went ahead and put PENALTY to the developers for breaking the build :).



You won't beleive, that really has improved the quality of build, more than reward system!! I agree that reward system should exist, it should be given to whole team instead of separating groups/Individuals, this avoids any split in the performing team. Also keeping reward competition for breaking their own record helped improving the situation. Individual rewards should be given at the end of project as long term rewards for a consistant performer. That reward should stand as his career achievement as promotion or anything of that sort. To limit the reward hunger for normal performers, it is always better to remind the team, that customer satisfaction and business fulfilment is the best reward to the team and the company.



It is true that tools like checkstyle and findbug helped to maintain the coding standards. Overall I liked the article and gives lot of safety tips to keep the scrum project as successful on a long term. Big thanks to Uncle Bob :)!
Nikos Georgosopoulos, CSM, 1/30/2013 2:47:35 AM
I like the article but I have a question. When you refer to the reader as "You" to which role in Scrum are you referring to? you expect the team to establish these practices? how would you suggest a team to reward itself for good quality?

Thanks again for taking the time to write down once more a list of very good suggestions as to how to measure quality of code, I'm only wandering (as I am new to scrum) which role is suggested to oversee the work of the team since it's supposed to be self empowered. I did find this "self empowerment" thing odd in scrum to tell the truth and it is one of the puzzling points in my implementation of the framework. Financial managers do not care to put quality goals nor measure them. Product owners on the other hand have too much work figuring out and maintaining the business behind the software, there is no time to measure code quality. All this I say it only as my opinion, waiting for debate.
Glen Wang, CSM, 2/18/2013 2:26:37 AM
The key word of agile is continuous learning, on people/process side and technical side, or Scrum + XP.

Thanks,
Glen Wang
Gagan Rana, CSM,CSPO, 2/25/2013 10:41:33 AM
Great insight even today.
It will be the ideal world when productivy and quality gets equal share. Specially many business needs to launch products which will serve certain specturm. Not sure it will be really practical to devote so much time in testing (keeping too long term mess into mind).... Scrum is known for productivity and resonable in quality.
Samta Sharma, CSM, 2/25/2013 1:08:41 PM
I completely agree to this. This is exactly what would help to keep it agile. It is essential to create engineering disciplines to not create "mess". And reward "quality" of work done as well.
-Samta
Hemanth KS, CSM, 3/13/2013 9:02:03 AM
Very good article - i completely agree as i faced this in my current project. As Glen highlighted it is continuous learning and improving in all areas - people/process/approaches.
Thanks, Hemanth.
Sandeep Bramhe, CSM, 3/20/2013 12:02:56 PM
Excellent article and thanks for url trinkets.

Got the clean part. Now, how do you draw a line between slow and just right speed?
Anurag Goel, CSM, 5/31/2013 9:04:00 AM
In my view due to time box sprint there would be time pressure on the team to make code work and pass against the test cases they have planned but sometimes they fail to consider all business scenarios and end up writing a code that just works for these test cases. As system grows it becomes difficult to modify the code which have implemented in previous sprint as business impact is high and also testing efforts would become a big sprint in itself. This could be one of the reason for making the system ΓÇ£messΓÇ¥.
Rakesh Kumar Bhagat, CSM, 7/29/2013 12:34:31 PM
Awesome Robert. Language too was simple and straight.
Sumith SP, CSM, 8/19/2013 7:05:40 AM
Its a great article, a lot of questions on the technical aspects are answered..
Vaibhava Kumar Pandey, CSM, 10/16/2013 2:54:50 PM
Very useful article.
Mohammad Asif, CSM, 10/24/2013 4:23:15 AM
Bob, thank you for putting in time to prepare this wonderful article. Going fast and still staying clean should be the goal of any team. I will take some of your points and try to implement them in our organization.
Kazeem Oyewumi, CSM, 12/30/2013 4:48:30 PM
Very interesting article, a real big exposure for some of us that have just adopted Agile/Scrum. Thanks Bob!

You must Login or Signup to comment.