Scrum Secret #2 - low tech rocks!
August 1, 2008
There are a number of elements to SCRUM that really work well for us. One of the most obvious features is our ‘SCRUM Wall’, where we ‘publish’ all the work items that form part of the current sprint to ‘The World’.
The Wall is primarily for the team, but it’s surprising how many ‘outsiders’ take a real interest. Initially there’s the comments about ‘nice wall - but a bit low-tech isn’t it’, to which we respond - ‘that’s the point’. The great thing about the Wall is that each card is a tangible thing, representing a tangible deliverable. Rather than being locked away in a spreadsheet or web app (though we do use TACKLE to track our tasks electronically to - more on that later) the cards can be accessed easily by everyone.
The cards typically begin life with a one-liner describing a deliverable, and estimate of how long it will take and the initials of one of the developers. However it doesn’t take long before the card has evolved with the scribblings of several members of the team as more information is discovered.
Quite often one card will become two or three as the iterative process of understanding more about the task unfolds. The pure simplicity of the wall means that things don’t get forgotten or fall off the radar - every thought and new discovery is captured quickly and easily.
The wall only represents 2 weeks of work at a time - a Sprint. This means that every 2 weeks the wall gets cleared. The completed tasks are archived. The items that are not complete or blocked are taken down and form the basis of the ‘Backlog’ for the next sprint, in addition to new scope items that we take from our ‘product Backlog’.
We are currently running a one-hour planning session with the whole team every 2 weeks, which gives us ample time to review where we are with the existing work items and allows us to estimate how much new scope we can bit off to keep us occupied for the next 2 weeks.
This process is incredibly tranparent and efficient. The constant replanning and course correction means that: we rarely build anything that is not part of the final solution; everyone on the team is cross skilled and across the big picture; we can easily slot in refactoring tasks to increase the robustness of components we have already built but need some ‘love’; reporting upwards to management on progress is easy due to the high visibility of the methodology (lets face it - who could miss our scrum wall!).
The best thing about this methodology is that the team is completely behind it. The core team members don’t want to work without it and new recruits accept and join in with the processes eagerly.
LONG LIVE SCRUM!
64 bit Windows: WTF: 64 bit dlls live in System32 dir, 32 bit dlls’s are in SysWow64
June 30, 2008
Here at Buildmasters, we have now moved all our development vm’s and other servers to 64 bit editions of Windows.
The 4GB memory limit is gone, and no more recycling IIS app pools and running out of virtual memory.
One thing to note however: The \System32 directory contains 64 bit dlls, and the legacy 32 bit emulation dll’s live in the \SysWow64 directory.
The is all done for backwards compatibilty, but it is very confusing.
Have a look at http://en.wikipedia.org/wiki/WOW64
for more info.
Eating the Elephant
June 12, 2008
Our current engagement with a funds management company in Sydney, Australia is a large and complex beast, involving more moving parts than a swiss chronometer, an incredibly demanding business and the Eagle PACE Operational Data Store. The entire program will run for approximately 4 years, involve over 100 consultants, vendors and staff, and burn over $100 Million. We are interfacing with 3 front office trading systems (Charles River, Imagine and Blackrock Alladin), several downstream systems (Smartstream TLM, CoAcs and StatPro) and exchanging market data with Bloomberg, Reuters, Factset and S&P - Phew!
It’s taken nearly a year to truly appreciate the size of our ‘Elephant’ and learn that there’s only one way to eat it…one small piece at a time. Short term, realistic goals are the key to success, which fits beautifully into our development methodology - SCRUM. Read more
“The dates can’t change but the scope can and will”
June 5, 2008
It’s the age old problem of managing change effectively on an IT project. The business have expectations of what functionality will be delivered, the joint testing with external parties has been locked in and the go-live weekend has been booked BUT the detailed requirements are incomplete and the functional designs are only half finished (at best).
Of course some contingency was built into the original schedule, but that was 3 months ago and the world has changed alot since then.
The same thing happens every time, just to different degrees, it’s just the nature of our business. The key to success in my view is not to get too bogged down and stay ‘Agile’. The fact is that no one is really to blame, the project plan is just a guide. If the dates can’t change and the scope creeps then the inevitable result is that what gets delivered on the ‘immovable’ date is not quite ready, a little under-cooked. Is this a problem? in some cases yes, but how big a problem can be managed.
At the end of the day the business is the one that gets affected - but remember, the immovable dates and incomplete requirements are ultimately down to the nature of THE BUSINESS and the ability of THE BUSINESS to be able to state their requirements accurately in the first place.
We’re all in it together, business and IT. When things don’t go to plan we make a new plan. It’s as simple as that!
Release 2 Mayhem
May 29, 2008
Another crazy week is coming to an end with one of Australia’s biggest funds management companies. Our project plan is finally level and we are about to go full steam into developing a series of new interfaces between our Eagle PACE database and the new derivatives trading system (Imagine).
Our plan to refactor our ETL layer from R1 is also well under way with only a few components still using the old design - putting us in an excellent position to decommision ‘ETL1′ by the end of June.
Our SCRUM development methodology is keeping us focussed and well organised. Sprint 5 started on Monday, running for two weeks until 13th June (when we make another delivery of R1 warranty fixes to Production). The juggling of R1 waranty work and new R2 development is continuing to keep us on our toes and further reinforcing our decision to go with a very agile approach to running the team.
