SCRUM Beyond: Names

Every agile developer knows the the sprint as the time period in SCRUM. The idea to have short iterations is good and right. But there is something wrong with the Spring and thats ... the name. 

If you compare software development with sport, I know the stereotype of unathlethic developers, then it should be clear that you have to a relaxation time after an sprint. Usain Bolt can't run 10 mile in the speed of 100m . But as software developer you have no relation time. Software development is not like a sprint - software development is more like running a marathon. You can't work with highest possible speed, if you try it more then once you will wear your development team. Keep this in mind and don't call it SCRUM Sprint, call it SCRUM Mile.

SCRUM Beyond: Nano Demo an efficent Technique

 Every agile developer knows the three long meeting at the Sprint change: Review, Retro and Planning. As an improvement to keep the development cycle short, shorter then the spring length is to introduce a so called Nano Demo. In the Nano Demo the developer presents the in the last days finished tasks to the product owner or to the users. You can do the Nano Demo periodic every two or the three days. The Pro of the Nano Demo is the meeting is realy short 5 to 10 minutes. The developers need no preparation time and the feedback loop is very close. That gives immedently feedback to developers without any delay. A second positve aspect of the Nano Demo is the better motivation of the developers by the close feedback.

Summary:

Nano Demo is a efficent Review technique used to improve SCRUM.

1. 5-10 minutes short
2. every two or three days or two time in a week
   

PRO:

1. Close feedback cycle
2. No Preparation from the developer side needed
3. Keep meeting effort short
   
4. Improve developers motivation
   

Reduce the code to the minimum

Reduce the code to the minimum but not less. This fundamental  principle of mechanical engineering fits also extremely well to software engineering and software resilience. Remove all unneeded wrapper, boiler plate code, indirections. 

1. Less code mean less bugs
2. Less code keeps your software side effect free
3. Less code means less hidden knowledge 
4. Less code - less dependencies
5. Less code means less code to read

But be careful. Be sure that your code is well-covered from tests. Every mature project came's into a phase where the software developer delete more lines than they are writing new.

Exception handling - resilience in small

On of the most discussed software development topics is the right exception handling. Exception handling is one of the basic building blocks of resilience and without any surprise the correct exception handling depends on your application.

But here some well working tips to keep exception handling easy:

1. Find out how important is this code place. If you compare it with a car, is it the breaker or is it the seat heating.
2. If your code is the "seat heating" category then:
1. Catch the exception
2. Log the exception as error.
3. Maybe count the errors as metric and put the metric on a dashboard.
3. If your code is in the "brake" category then
1. Maybe catch and log the exception with the context e.g. the related method parameter
2. Throw re-throw the exception and handle it on the presentation layer (front end)
4. If you can't clearly decide between the categories "seat heating" and "brake"
1. handle the exception like category "seat heating"
2. create an alert on the metric
5. If you have an fallback use the fallback and count the usage via log message or as metric