Tagged: Theory

Using Scrum to control complex software

Everything in Scrum…

  • is a time box (aka sprint), so things don’t go on forever
  • is done with cross functional teams who don’t need to be managed
  • has a constrained team size ( under 8 people )
  • has to achieve some form of a shippable product at the end of each time box / sprint
  • assumes that you are intelligent enough to come up with a solution to the problem at hand
  • requires minimal or no interruptions while sprinting

Additional points

  • Scrum goes hand in hand with Extreme Programming practices.
  • Working more hours does not equal better code quality. Code will likely become exponentially worse as a result of quick fixes and ideas that haven’t been adequately thought through. The cost to fix these issues even outweigh the cost that would have been saved by keeping normal work hours. As a result, overworking is not a good way to increase project velocity.
  • Unexpected features can harm project velocity in such a way that if not adjusted in time for quality control will cause future iterations to gradually worsen as you build upon a flawed code base. This continues until eventually you have a “design dead” product.
  • Over 65% of all functionality that is delivered (which must be maintained) is rarely or never used.
  • 35% of all requirements change during the life of a project.
  • Using a prioritized list of features, overtime the items will begin to loose value and at some point the time may be better spent elsewhere.


The Innovators Delima


Extreme Programming Tidbits

Extreme programming is a language-independent approach to project planning and quality control which aims to lower the cost of changes in development.  There is little to no up-front documentation which allows for a more flexible approach to tackle software problems.  With that said there is controversy which surrounds the subject matter as these practices don’t come without its drawbacks.

Over the last few days I’ve been getting into some of the Extreme programming concepts in the book eXtreme .NET.  The first chapter gives a concise overview of how XP fits into common day business needs.  Here are some key concepts that I took from it:

  1. Whole Team: the customer is always available to discuss and resolve issues.
  2. Planning Game: where developers sit down with the customer to discuss features of the software which are brainstormed and given priorities.
  3. Pair Programming: is the practice of having two developers working alongside one another solving a single problem.  Both programmers learn from each other and send along the knowledge to the next person who they pair with.
  4. Test-Driven Development: writing your test cases before beginning to code your solution not only helps you stay focused on the task at hand, it essentially acts as a safety net against breaking existing logic.
  5. Constant Refactoring: the process of optimizing your code without loosing functionality.
  6. Spiking: making the effort to experiment and drive your efforts in such a way to learn a new skill which pertains to the project development.  It is often done by solo developers who need a break from pairing.
  7. Continuous Integration: code gets integrated with the solution after each tasks allowing for the team to ship early and often.
  8. Stand-Up Meetings: team members meet every day to discuss progress made as well as spread knowledge to the team.


The Four Five Key Values of XP



A person’s work environment can persuade his or her empowerment to communicate freely.  It is likely there there will be problems if communication is not done properly and frequently.  Even worse, a newcomer to the project could be left out on some important piece of information that would cause a delay in development.


Doing the simplest thing possible to move the project forward.  By writing simple code, it is more likely to work.  Only begin to rewrite a more complex solution when the business need calls for it.


Constant feedback from the customer is essential so you can understand exactly what needs to be done and should be done in small iterations.  This is especially true when priorities change while deadlines need to be met.  Your unit tests provide immediate feedback if your test fails when modifying code.


By working more intensely for a shorter length of time, you are using your time more efficiently as well as allowing yourself more time to be out enjoying life.  Additionally, you must also have the courage to throw away unneeded parts of your code as needs change.


Having respect for fellow team members by not doing anything which will break the XP practices put in place.  Always striving to produce high quality code throughout the project lifecycle.