We're very much in the final stages of our preparations for Cairo- Thushara has even started to find the total mental calmness needed to do the totally cool performance I know she will eventually put on, once there. Exilesoft's hard-core Scrum Project management work is turning into a stage show for 2,000 P2P participants.
I think we've actually learned a lot in this process. Sometimes you just need to take a serious walk through the total logic of everything you do to get the right picture. Even redefine the way you do certain things to be able to get it really right! We've spent endless hours discussing the weight points, challenges, and joint experiences in projects from the past years to see how it all fits in with what we do every day and WHY we're doing what we're doing the way we do..
I'd say that even if Cairo and P2P was cancelled tomorrow our effort would have been worthwhile! Our ESPM (Exile Scrum Project Management) has been reborn :)
One subject that seems to become an eternal one in Scrum discussions is related to Scrum and documentation.
I believe this is a very important discussion as there are so many people out there that seem to think there's a basic conflict between running scrum (targeting early delivery and "speed to market") and still documenting the system and what you do, and we'll face that question in Cairo - for sure.
Considering WHY you want the documentation in the first place may be a good way to get off on the right foot. Some would need it to get off the hook if anything goes wrong, or just to feel that they have control that everything has been done. Checklist.
As offshore development is often driven by the desire of having a massive (but temporary) development effort, the final piece of software will often be passed back to an internal IT department for maintenance and modifications, once the offshore project is completed. This will require good system documentation to guide and manage the maintenance work, but probably stop short of a full set of UseCases.
Others would need comprehensive documentation as part of a future Due Diligence or IPO if the software in question makes up an important part of the corporate balance sheet or represents a key shareholder value. In this scenario the documentation would soon move into the RUP sized structure and seriously tie down any attempt of Scrum / agile strategy in development.
In several of these situations where the more heavy documentation is required, it may be a good idea to separate the actual documentation effort from the main development team and run it as a separate project or sub-project. As there are as many approaches and different motives as there are projects, getting this right should be given proper attention.
The delivered result is finally what matters - even in documentation.
Recent Comments