Not too long ago, in a galaxy far, far away... there was the promise of a utopia where tooling and automation would eliminate the need for all those time consuming meetings.
However, even when you close your eyes and wish really hard communication is usually at the root of most of the challenges associated with software development at scale. In some instances 'scale' may mean more than a single author!
Communication problems can and will include:
- Outsourced suppliers incorrectly interpret requirements
- Internal team members don't review their own interpretation of requirements
- Insufficiently detailed investigation and review of feature requests
- The classic 'yes, but we haven't agreed exactly HOW to do that yet'
- Being unable to easily 'see' where the project/development is in relation to a release
- Different project participants working to different release dates
- External stakeholders not appreciating what is in a release
- Contributors doing the 'easy' stuff first rather than delivering the commercially valuable requirements
Note that the examples above have some things in common. They are all issues that can occur relatively early on in a project. Quite a lot of them are to do with expectation management.
Get the most senior members of the team to buy into what you're trying to achieve and you can (usually) solve these two issues by making sure everyone know's what's required and then managing expectations as you go.
That looks easy written down but it's harder to implement of course. The iceberg really arrives when multiple people are working on close/overlapping bits of the codebase and making changes as they go. Now communication becomes very important because those involved are in danger of colliding with each other.
They're going to collide because decisions which might affect the collective aren't necessarily real-time so one person could decide that a button is called 'Bert'
Similarly - if you can't measure it then you must assume it won't work or there's way more effort involved that has not been accounted for.
As un-exciting as it seems if there's no framework to help all parties visualise the status of a project or deliverable then it's highly unlikely it will be delivered on time
This view of the world has to be available to all. This requires honesty on the part of all parties
- How much work is actually left?
- How much time is each item likely to take realistically?
- How much validation/checking is required - how long will it take?
So the point of this post is whatever tool you're using (and there are many) it matters not if you're unable to communicate or see where you are on the map
Get everyone in a room, make sure everyone knows where they are, what's left to do and you'll find out soon enough whether you're the only one with a sense of optimism
Three fifteen minute reviews a week on a rolling basis are infinitely preferable to one two hour meeting after three weeks when panic sets in ;)