|
My experience stems a relatively brief period (~8months) of managing a resource strapped team of 5 devs to deliver pretty complex and largely vaguely specd out products for my venture. (For reference this included a real estate platform, a client facing android app, plus an enterprise management system all complete with Data ingestion / Machine Learning pipelines, built from the ground up.)
Here are my learnings
1) chart your plan.
Sprints have feature groups, feature groups have features each with defined dependencies. and each feature has tasks. How clearly you map this dependency graph not just in terms of to-do items, but also in time, and by human resource required will define how on time your product gets shipped. 2) Rightfully Estimating Time
Overestimate keeping in mind shipping a feature is usually making it + testing it out a bit. 3) Know what features can be chopped off when push comes to shove. 4) communicate clearly and with as much supporting documentation as possible.
We still can't vulcan mind meld. So as a PM you need to convey your prioritised vision to your devs. motivation, how a feature fits on the roadmap, dependent features, Screenshots/ mocks, process flows, test cases to check against, all this will make sure features shipped don't need reiteration. 4) Architect for longevity
If you are working with an architect, he will probably be responsible for this. But remember, its ok to delay the initial stages of your product if you are spending time building up the core. Think build systems, continuous integration and deployment cycles, just the API layers and business logic, UI work happening totally independent as functional mocks etc etc. 5) Trying to stay away from the temptation of coding.
Code when you need to, assign tasks to yourself as and when required but not as a norm. It takes a lot to see the bigger picture and keep track of so many moving parts of a project. Doesn't help overloading your system with dev tasks too. These two worlds are pretty different beasts. PS: One tool which I relied heavily on over the last year was Omniplan. We not just tracked dev items, but also things like deployment timelines, adoption rate within the org, training schedules for employees and how all this tied up into the features which needed to be rolled at and at what time.
A sample of dev wise sprint plan which helps people plan their workload , keeps meetings to the point, and lets people take vacations when they are relatively less occupied :) http://imgur.com/a/1b2mH |