(Model Storming)
Some notes on approaches I have found successful whilst working with distributed development teams
I work as a Senior Technical Architect (Consultant) @ Astadia.com, my role is to architect cloud based solutions for large blue chip clients and manage the build phase of the project from a technical perspective.
I work with distributed teams of Architects and Developers in multiple time zones, and the following post describes some techniques that work well for me and the team.
Typically the quicker we can demonstrate features/functionality to the business, the higher the quality of the end deliverable will be.
Following the Requirements Capture stage (typically in the form of User Stories), I take the following approach to kick off the Design:
I create an initial Model/Design to Support the requirement in question, this is typically done using standard modelling approaches such as Screen Mocks (Balsamiq), UML Artifacts (Sequence Diagrams for complex logic etc). This initial design is created before I collaborate with the team on the finer detail of the design and I always ensure the User Story is visible at the top of the design document for easy reference.
When I believe the High Level design contains enough content to convey the design concepts, I will set up a Model Storm session with those on the team responsible for taking the design and implementing it.
The Team will participate in these Model Storming sessions over Voice and Web from distributed locations.
These Model Storming sessions typically last around 30-45 minutes, and are iterative depending on the complexity of the solution being proposed. Simple solutions may only require a single Model Storm session, but more complex designs, will typically have multiple Model Storming sessions throughout the build phase as the design is refined.
The 'Glue' that allows me to collaborate with the team effectively, is primarily Google Docs.
I find this tool invaluable whilst working on a design with the team. It is effectively our team whiteboard!
It allows other members of the team to add questions to the initial design in real time at relevant points in the document, and these are then addressed as we progress the call. e.g.:
More can be read around Model Storming at Scott Amblers site - Agile Model Driven Development
Some notes on approaches I have found successful whilst working with distributed development teams
I work as a Senior Technical Architect (Consultant) @ Astadia.com, my role is to architect cloud based solutions for large blue chip clients and manage the build phase of the project from a technical perspective.
I work with distributed teams of Architects and Developers in multiple time zones, and the following post describes some techniques that work well for me and the team.
Typically the quicker we can demonstrate features/functionality to the business, the higher the quality of the end deliverable will be.
Following the Requirements Capture stage (typically in the form of User Stories), I take the following approach to kick off the Design:
I create an initial Model/Design to Support the requirement in question, this is typically done using standard modelling approaches such as Screen Mocks (Balsamiq), UML Artifacts (Sequence Diagrams for complex logic etc). This initial design is created before I collaborate with the team on the finer detail of the design and I always ensure the User Story is visible at the top of the design document for easy reference.
When I believe the High Level design contains enough content to convey the design concepts, I will set up a Model Storm session with those on the team responsible for taking the design and implementing it.
The Team will participate in these Model Storming sessions over Voice and Web from distributed locations.
These Model Storming sessions typically last around 30-45 minutes, and are iterative depending on the complexity of the solution being proposed. Simple solutions may only require a single Model Storm session, but more complex designs, will typically have multiple Model Storming sessions throughout the build phase as the design is refined.
The 'Glue' that allows me to collaborate with the team effectively, is primarily Google Docs.
I find this tool invaluable whilst working on a design with the team. It is effectively our team whiteboard!
It allows other members of the team to add questions to the initial design in real time at relevant points in the document, and these are then addressed as we progress the call. e.g.:
- Dev1: Should the Submit button provide validation before posting back to the server?
- TA1: Email Address and Tel. No. should be validated client side with a message back to the user if validation fails and an indicator on the fields that have failed validation.
These collaborative comments are added to the design artifact as we talk on the call, any concerns are raised immediately and visible to all participants and if a solution to the question is known this is also added in real time.
This design artifact becomes a living document through the build phase, and includes an audit of design decisions made.
I find this approach produces a really focused design for the User Story in question and ends up being a more accurate reflection of the actual Design/Implementation as it is frequently updated/living during the build phase.
It encourages collaboration, everyone on the team has a voice. It allows us to get a working solution in front of the business as soon as possible as it reduces any misunderstandings and therefore reduces re-work time.
It certainly has improved the quality and speed with which we can react to the Business!
More can be read around Model Storming at Scott Amblers site - Agile Model Driven Development
