I am a firm believer in Lean processes aimed to maximize value while minimizing waste. When it comes to running projects in a Lean way, this goes far beyond the role of the Project Manager (or Scrum-master) thus requiring the right recipe of team, process, communication, work environment and pride. Often I am asked what are the typical practices I apply to projects which fall in the mobile/desktop application development context- this is my attempt to answer the question. Important disclaimer - this is not a prescription for how to run a project, nor does it guarantee success. The secret sauce is always the people NOT the process.
The Raw Materials
If any of these seem unreasonable, you need to take a hard look at your team and work environment. Any concessions made here will reduce team effectiveness.
- A team well-balanced in terms of seniority - Experience is contagious!
- Dedicated team members - not split across multiple projects
- Smaller teams (no more than 5-7) — Once you breach this team size communication complexity increases exponentially.
- Conduct retrospectives with full participation - Always seek to get better
- A knowledge management strategy ensures team members know where to store/post directional artifacts that other team members require to do their job (e.g. Wireframes, PSDs, Test Cases, Context Diagrams )
- Use of Information Radiators — Physical views into plans (e.g. Post-Its on a whiteboards) that may supplement a digital plan view
1) Breakdown the work
Decomposition of capabilities/features is a necessary and somewhat painful evil. However, you do not need to go to a painful level of detail to create this artifact. The importance is breadth not necessarily depth. The depth only needs to go as far as necessary for the team to directionally understand where a feature needs to go. If a team member is able to provide some form of time estimate (best and worst case) for one of those lower level items, you’re low level enough. If estimates are coming out to less than 1 day you have likely gone too far. Get the full team involved, apply the 80/20 rule in terms of completeness and time-box the activity.
2) Define a Path
Once you have step 1 in place, work with the team to derive a chronological execution of the work driven by perceived value and/or risk/complexity of a given feature. Front loading your risk/complexity (as long as it is somewhat high value) is a very acceptable and smart approach because impact of course correction early on is much less invasive than the alternative. Ensure a basic architecture for the overall solution is derived and communicated. This ensures that the team has a solid foundation to build upon.
3) Respect the Pyramid of constraint
Scope, Time and Cost — Fundamental variables applicable to any project context. Visibility and active monitoring of these variables is essential to ensure project success. First and foremost, ensure that a baseline is established for each of these variables before a team even start the project. Understand how your stakeholders rate the relative importance of each of these variables and uphold the “Rule” that trade-offs are the only way these baselines can/will adjust. Deferring this activity to after a project gets going can result in scope creep and cost/time over runs.
4) Hold up the mirror
As a PM, it’s your responsibility to hold up a mirror in front of your team that shows the good, the bad, and the ugly. This allows the team to maintain appreciation for the big picture while they do their best to work through the small one. I am huge advocate of a plan view that I have written about in the past (High and Mid-Level Plans — which shows time, features, tasks, distribution of work across team capability areas (Design, Backend, UXD, etc.), progress made, unplanned work and deferred work that will come in later releases. If you have this and revisit it often, consider your team informed and that those Triangle of Constraint variables are being monitored (for the most part.)
5) Create an environment of ownership and accountability
Everyone is a player. PM’s should be servant leaders, therefore any plan created needs to be the team’s plan not the PM’s (or Sr. Mgmt.) This way the team has accountability and ownership rights over whatever happens to the plan. If something is not going as planned the team can understand the implications of this and course correct and work to reveal why something may not be working out. Constant readjustment and calibration is required to keep things moving along. The project manager helps ensure these conversations happen.
No team member can slip into the shadows. To be successful every contributor needs to have a voice. A PM needs to put their “Facilitation” hats on and ensure they proactively encourage all to participate and chime in on team affairs. That’s the beauty of teams. They succeed together, not as individuals.
6) Demonstrate Progress
Demos encourage quality, because no one wants to demo something that works and looks subpar. Stakeholders can rest assured they did not buy snake oil and value is being delivered in some regular interval. Demonstrations affirm you’re heading in the right direction. Last but not least, demos allow the team to celebrate success in short bursts - It feels great to get something done especially when the road ahead is a long one!
Give it a go and let me know if this works for your team.
DockYard is a digital product agency offering exceptional user experience, design, full stack engineering, web app development, custom software, Ember, Elixir, and Phoenix services, consulting, and training.
