I am hoping to start leading a new (really old... but soon-to-be revived) open source health IT project very soon. The good news is that it's appearing that the project will be well-supported, and that we will be able to staff the project team up to a very good size. I'm also planning on continuing to embrace an agile project management process using scrum.
One of the key benefits to having a successful agile process has been the shared situational awareness of the members of the project which allows the team to self-organize. If I am needed less on the small but blocking minute-to-minute decision making, there's a higher probability of exceeding the expected outcomes of our sponsor while simultaneously growing new leaders for the future. Additionally, I am happy to perform less tactical work and focus more on strategy.
With the right project team (talented... responsible... multi-domain... passionate) it is remarkably easy to be successful on any project; from a project that is technology-heavy software development activity, to one that is primary focused on steering or influencing federal policy.
After originally being a software engineer, have been leading software projects for about 7 years, and my largest projects have been right around 5-8 Full Time Equivalent (FTE). I am now facing the prospect of leading a 14 FTE project... this is a first for me.
One concern of leading a project of this size is the increasing number of individual communication links that would be needed for everyone on the team to know what everyone else on the team is working on to maintain shared situational awareness on the project.
To illustrate this, you can see how the communication links will continue to increase non-linearly with more and more staff. L = number of communication links, T = number of members of the team.
Additionally about half of the 14 Full Time Equivalent (FTE) project team are co-located in an agile bullpen room, while the other half are geographically distributed across the East Coast... from Massachusetts, New Jersey, Virginia, all the way down to Florida. The good news with this distributed team is that the entire roster will be based in Eastern Standard Time. At least we will not be depriving individuals of sleep with meetings that span numerous time zones!
My thoughts of dealing with this if/when this new project starts, and try the Scum Alliance model of hosting a "Scrum of Scrums". My current plan is to have co-located team maintain their agile "bullpen" and have one scrum, and have the geographically-distributed team scrum either after or before them. The two team would have a size of approximately 7 FTE each. They should both be able to maintain a cross-domain roster of engineers, healthcare informaticists, clinicians, policy leaders, and Clinical Quality Measure SMEs.
To follow the "Scrum of Scrums" process, I plan to identify a scrum master from each team, and after the daily scrums, the scrum masters, product owner and stakeholders will host a second scrum. Again following the Scrum Alliance variant on the "Scrum of Scrums" meeting, the agenda for that meeting will deviate a little by addressing the following questions:
Because the "Scrum of Scrums" meetings may not be daily and because one person is there representing his or her entire team, these three questions need to be rephrased a bit to be "team-focused" and they suggest it's beneficial to add a fourth question, identifying if the two teams might be unintentionally stepping on each others' toes:
- What has each team done since yesterday?
- What will each team do today?
- Are there any impediments to the team's plan today?
- Are you about to put something in the other team’s way?
Fingers crossed...
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2013.
No comments:
Post a Comment