Service Oriented Scrum Sprint Planning

Scrum works well. when its only one project and sprint planning is really focused to that one projects. However the reality in most companies is that many of them are going towards a some kind of service based architecture.

In these cases or in cases where a number of projects are being developed at the same time, scrum planning gets confusing. Since each team is so focused on the current sprint and back log only, it becomes very tough to build dependencies between systems or services at the same time.

Enterprise SOA Sprint planning – ESOP just a fancy name conceived is based on restructuring projects and run dependent projects on the same sprint time line.

All projects will go to sprint planning the same day. The dependent stories are discussed in a common spring planning meeting where both teams are present and then the teams split to plan other stories.

This brings in awareness in all teams and they are aware of the service contract they need to fulfill as a part of this sprint. At the end of the sprint these contracts get fulfilled.

The product owners of each project are typically so focused on thier own project that often they tend to put cross service stories at a lesser priority than thier own stories. The parallel sprint planning would allow them to look at the big picture and plan the stories well.

This also is a fun event. At the end of the sprint the two systems are indeed talking to each other instead of building them in some kind of step approach.

Another fun thing to do is for the scrum masters to switch as moderators of the two teams in the planning meeting. Especially after a few sprints these planning meetings become fairly boring exercise. Switching scrum masters for the spring planning brings about a fresh breadth of air.

Powered by ScribeFire.

Agile Programmer toolkit

If you are into XP practices and wonder what are some tools that can make your agility grow, here is a starter kit.

 
1) You need a tool to code – Eclipse or if you are a .NET dev, some version of VS
2) You need a good refactoring tool – Eclipse has a very decent refactoring tool. If is VS land try resharper.
3) If you are a command line person, you can customize anything you repeat. Programmers are lazy by choice. Automate any command you do often
4) You need to get NotePad ++ or some such intelligent editor
5) If you are into webservice development you  have to get Soap UI
6) You need a sql generator so that you can script out database. If using SQL server , try
7) Dont forget a code generator – Try mygeneration or codesmith
8) You need a code repository. Nothing beats subversion
9) You need a way to get to the code repository – Try tortoise SVN
10) You have to do continous integration – Use Cruise Control
11) You will need cctray ( This is a small notifier that notifies build status, get this from your Cruise control install
12) If you do TDD – you need Junit or NUNIt
13) If you want to acceptance test – Try fitnesse
14) For Load test  – try JMeter
15) A tool to view database – Try webyog for MySQL or in the Microsoft world, SQL management studio works well
16) A place to store requirements – Run to walmart and get some index cards

 

Powered by ScribeFire.

An interesting article on Build automation

A good friend of mine Geoff has a very interesting take on Build automation .

The biggest benefit i see of automation is that you can catch issues before it they start becoming expensive both in time wise and cost wise to fix.

The feedback loop provided by tools like cctray when things break is enough reasons to just do it. Its also the fun part of programming. To catch others when they lazily check in code without testing the impact.

Another very important aspect of automation is the ability to always demonstrate to the folks who foot the bill, whats cooking in the oven.

What better way to show off than actually showing code that works. Nothing can get you closer to this than automation.

Unit tests are the heart beat of your system. don’t let the beat stop!

So whats the hardest part of writing unit tests beyong writing the first test.

Writing the second, third, fourth …

Another important factor is that if there are not enough tests, the developers are not having the comfort zone to make changes, refactor etc. When the trust factor on unit tests goes down, developers don,t keep it up to date and soon unit tests are just dead code never to be run again. This is seen quite often in projects today. This translates to more hours debugging, wasted down times , more cost and slip in schedules.

HEre are some symptoms that your code is dying and there is not enough active healthy test coverage. I say healthy because its not enough to just check for null values and collections, its going beyond the basics, using it as a tool to write the code that make all the difference. The code is only as good as the tests are.

Symptoms

1) It takes for ever getting even small pieces of funtionality out of the door

2) Bugs that were fixed few releases ago, keep crawling up

3) There is a resistance from developers to make any kind to change to major parts of the system.

4) Your developers work crazy hours on code and have no idea when they will get finished . The only thing they know is that they are working hard.

5) There is a blame game between QC and development. Sort of a throw it over the wall mentality. Where developers ship code to QC , QC starts finding silly defects which could have been easily found during development. The stress levels are high between the two groups. Development has the big brother mentality.

Avoiding all these are quite easy if developers are motivated and unit test culture is built into the culture of your organization. Critical to this is management support and an understanding that it takes time and money to produce good tests. This is not something that can be done in as much time as just writing code. It pays of in the long run for a health y product and goes a long way during maintenance.

It is very important to keep these tests running on every build. Continuous test integration. Running all tests every check in. ( It does not take much if the tests are structured correctly)

Unit test Category tags in NUNIT ( for example ) provide a great way to seperate unit test , integration test, long running tests and so on.

The # 1 Mantra of writing tests is Test independence. Test in every layer should run without depending on the other layer. Mock objects, Object databases, in memory databases, Test driven development can really help this cause. This process actually makes the design better and allows for better encapsulated systems that are not interdependent.

Test independence means

1) Every class / component should be testable by itself

2) When you test a class, lets say in the business layer, (that calls the database layer) , you should be able to test the business layer without the database being there ie Mock the database. These may be part of your test category Unit Test

3) The database layer ( if you are unfortunate to use a relational database) should also be unit tested. This becomes part of you Integration Category.

4) You could use a mock or a stub( Look on Fowler’s site for an excellent discussion on the difference) to test dependent layers.

5) Anything that touches a physical system like a database, file system, external systems are all Unit tests but could be treated as a different category. Many time developers treat this as integration test and dont think they have to run it at all times. its your code your team is responsible for its test health and code quality.

6) Follow the 15 – 30 minute agile coding cycle .

• Get code from repository,

• Work on one task at a time ( Most men are really bad at multitasking, if you are a women then may be you can work on a few at a time)

• Write few Tests from a list of tests that you have planned to write for that task,

• Write the Code,

• Make the Tests pass,

• Update code again from code repository,

• Build and Run all the tests ( build database if needed – if it takes too much time) then run all unit tests at category Unit Test,

• Checkin code

• Start again

It is very tough to start walking this road of writing tests and code to support it. Its like a new years resolution to lose weight and be healthy.Not many do it, but those who do, Do live longer:)

Do you need Something refreshing

I listened today to this two year old IT Conversations piece by Joel Spolsky.

http://www.itconversations.com/shows/detail207.html

If you are having some time, an MP3 player or a headset, listen to this.

Excellent thoughts. It is very different. Seems honest and has some great insights if you are trying to build a software product.