Agile Development

Agile Development

The hottest word and most often used description for newer methods were the traditional waterfall methods are replaced with a more interaction and fluent working process. 

I really like this way of working: not only working in pairs most of the time (from XP), or having one to share the design and ideas with, but in this way (with Agile development phase) especially the  "design & program everything in MS Word first", has been replaced with a more smooth, interactive and customer pleased approach. 

I see a very smooth and tight controlled development flow, because problems (requiring decisions) can be handled at once. At least for the near future, (and this is perhaps a risk - working in this way, does postpone critical issues).
But if the team has made a thorough analysis on the main architecture/design, like performance, critical interfaces, most of it could be addressed up-front!

I also see some risk related to the overall project management - because it becomes less visual what the missing-parts are ... You only have a good look at the known parts (has been working on). Also in terms of planning SW releases, freezing specification and other interactions to eg. HW would be difficult to estimate.



Since COCOMO looks at 

  • capability, 
  • effort, 
  • knowledge, 
  • knowhow, 
  • skills, 
  • complexity of design, 
  • functional behavior and 
  • lines of code ... 

in a huge mathematic formula, you can pull out many types of calculations. Estimates all based on your code expectations, people skills, speed and quality etc...   And this is good for making estimations on the primary items in the project.



Where Agile development (my point of view) has its strength with the 

  • 'Drop of the month/week' (architecture & design solution frozen, hole-through & beta releases ...)
  • Keep it simple approach - (though this can be by-passed)
  • Near-future planning, 
  • Better just-in-time activities
  • SW relationships and demands are exposed and review possible at an early stage
  • Elaborating current activity, progress, problems, ideas etc
  • Team sharing activities (and the can kick-in with ideas, you-must-remember ...bla bla)
  • Should/Could lead to faster integrations phases. (CI need too)
  • in parallel teams – smaller-steps means finding earlier point-of-problem (IF the teams are feature oriented, and actually uses what the other team delivers.)
  • Risk management (postponed and risky issues has to be recorded - for later action (evaluation))
  • pair activities possible (improved teamwork, knowledge sharing, general awareness in project)
  • Business people is directly involved in requirements – very early.
  • Reduce documentation to required/needed level!
  • Very good for upper or lower projects – not several in parallel!
    Upper à business à Feature focused (this must be technology independent!)
    Lower à Technology à Cheapest/fastest/highest power/? ... as possible


The 'dark' sides are (again my point of view):

  • Requirements tends to be more and more important,
  • Overall timing/planning is not known or its more floating due to small-step-at-the-time planning (Prj. Management),
  • Tuff customers can delay business (development flow) dramatically (if they interfere heavily),
  • Customers 'moods' can (easy) influence on already-made-decisions and work,
  • Compliance (customer's & system) and Requirements are often 'forgotten' (=not detailed written down), making it difficult at the test- & delivery stage,
  • Missing long term focus - The just-in-time could lead to locking situations that holds everything back ()
  • Only working on & focusing on 'what’s in scope' becomes risky ...
  • Multi-teams – missing same focus, postpones acceptance on delivers activities.
  • Business people involvement could delay initial work, discussing technical stuff and not features) as well as if they are not aware of their higher/changed responsibilities,
  • Some organization level are mixing business/feature requirements (what shall it do) with technology requirements (how is it done/impl) – typically unclear roles too.
  • Some project/product needs detailed development process & registrations (like in medico, automotive, mass-transportation, sitcom …) here documentation (only as we need) is not an option. You still need the full documentation!
  • Missing overview of technical areas – could lead to same but different development. (re-inventing the wheel). Making things twice …
  • Missing platform strategy leads to bad habits and difficult reuse of code base.
  • Platform strategy is mandatory for business – as well as for the technology!


On top of all this Agile development, one can chose many ways of testing & implementing. 
Unit testing with TDD (Test-Driven-Development), or other more traditional ways.


Generally lots of ways lead to Rom. I have been looking at SCRUM J Now working with for some years too. Not religious - but held daily and bi-weekly planning’s in teams. And I can tell you – if you are in a team where +30% of your activities is ‘customer’ related … forget about SCRUM and planning. That’ll only be waitsing your time. But its very good for keeping track, report to other in the team and ofcause make notes so people around you can see what your working on!

Today's most used tools are lacking performance and visibility for architecture & designing with agile methods. Most of the documentations are still written the traditional way (most companies using Word, more and more using UML etc). But for planning and keeping track of planning – link this to your actual work … well That is for sure to come … WE NEED IT!

I know RTC and CQ, ROOSE and other tools are now hiding that directions … nice J


Other interesting links - for Agile methods using Scrum:

Book: 'Feature Driven Development, Adaptive Project Management Using Scrum'

Adaptive Project Management Using Scrum - Part 1     Part 2     Part 3 



  1. Scrum: It’s About Common Sense and  more detailed   here
  2. Slide Deck accompanying this article:
  3. : Pay your £1, $1, €1 late-comer fee via this site!
  4. Software by Numbers: Low-Risk, High-Return Development, By Mark Denne, Jane Cleland-Huang. Prentice Hall PTR, 2003, ISBN 0131407287
  5. Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, 2004, ISBN 073561993X
  6. Agile Software Development with Scrum, Ken Schwaber, Mike Beedle, Prentice Hall, 2002, ISBN 0130676349

Another very important area is the SW re-usability - here defined as the re-usability value.


No Comments have been Posted.

Post Comment

Please Login to Post a Comment.

Articles Panel

  Article Posted By Date Reads
System-Of-Systems Ingineering
Process & Methods
31-10-2017 23:03488
IoT Start up
25-10-2017 10:25588
Unittesting - CPPUNIT
24-10-2017 20:26483
Things on the radar
24-10-2017 20:06547
WCET - Worst Case Execution Timings Calculator
28-06-2015 19:2914679
16-03-2015 18:222689
NuttX - Step-By-Step
30-12-2013 17:187578
Tools used
27-10-2013 12:134043
List of my robots
My robots
19-07-2013 08:443645
JoKaBot - Home build from scratch
My robots
19-07-2013 08:047044
C-Sharp (references and projects)
18-07-2013 19:194178
Home communications
18-07-2013 18:234312
Various links
My Collection
17-07-2013 09:048324
ARM - ARM7/9/11 + Cortex
17-07-2013 08:494257
17-07-2013 08:414474

Total Articles: 58 :: Total Article Categories: 16


My Collection (1) My robots (2)
Oldies (5)
Old Projects - very old
Process & Methods (8)
Projects (12) Robotics (1)
Technology (7) Testing (1)
Tools (14) Working on ... (7)
Projects Im currently working on
Render time: 0.15 seconds
874,010 unique visits