A perspective from two real-life project managers with Scrum Master, Advanced Scrum Master, PMP, and Agile Practitioner Certifications.
Agile software development has been around for years and everyone wants in. As a consulting company, Unicon works closely with clients to align our processes to match their internal practices and norms. We always recommend Agile development because iterative development with frequent check-ins and demonstrations ensures that everyone is on the same page with project requirements and associated outcomes. However, similar to any other standardized process, you have to assess the situation and determine what is going to work best for each new project and each new client. Unicon’s experienced project management team applies industry standard processes adjusted to client customs and norms to provide a flexible and nimble engagement model. But how can you manage projects in an agile fashion while still giving business teams what they need with respect to budget, deliverables, and timeline, when all of these items are at odds with and go against the core Agile philosophies? Here is a real-life perspective on Agile project management from two Scrum Master, PMP, and Agile Practitioner Certified project managers.
When kicking off a new project, typically you only have a small set of requirements documented along with a bunch of opinions and ideas you have to sift through. And almost immediately, everyone wants to know how much it will cost and when it can be delivered. If your organization is trying to adhere to Agile development processes, you know all too well that this is not in alignment and you can’t predict the future. However, this doesn’t change the fact that budgets have to be approved and commitments need to be made around when this will be available to sell and start generating revenue.
With all of these competing factors in mind, we like to start a new product development project with a two-day face-to-face business planning session. In this session, we facilitate a story mapping exercise that walks the team through each conceptual mock-up and/or workflow of the new product to be built, limiting participation to key lead developers, business stakeholders, and product owners. In this exercise, we systematically walk through and identify the features/functions of the new product for each user role. This is usually a very lively session using flip boards/ whiteboards, and helps level set the team on what the product/project is and isn’t. After your key business stakeholders have participated in the story mapping exercise, we have each stakeholder highlight the features that should be considered MVP. This exercise will give you a baseline that all product decisions can reference and allow you to begin analyzing the data to give the key business stakeholders what they need in reference to timelines and budgets in order to get the project funded and kicked off.
After the initial planning session, the group condenses to the key product owner and technical resources to sift through the details and generate the overall level of effort. Here are some of the things to consider while digging into the details.
- Continue to work at a high level and build a product backlog that represents high-level features/functions - work hard to not get bogged down in implementation details at this point. Focus only on what has been identified as MVP.
- Create a rubric for the team to follow and assign a level of effort to each feature set. We like to call this t-shirt sizing and use XS, S, M, L, XL. The rubric should specify the number of points allocated for each t-shirt size. We have yet to be successful on a project that uses only the Fibonacci scale to size stories based on relative complexity. People think in days and it turns out that it is much easier to explain.
- Identify any dependencies at this point and how this impacts the sequence of work.
- Group the project into meaningful releases based on feature function, business milestones, calendar constraints, etc.
At this point, you should have enough information to identify the team size and the skill sets needed to support delivery of your project and create an overall budget. After this analysis and planning phase is complete, we like to compile this information into a nice presentation format and bring the key stakeholders together to communicate the findings and answer any questions.
Once official approval has been reached and any adjustments have been made based on feedback, you can move forward with executing the day to day activities. Here are a few tips that we have found helpful in managing the day to day of Agile teams.
- Set a team kick-off meeting and go over the high-level plan, expectations, and team norms. In addition to reviewing these items with the team, document them and store them in a central repository so everyone has access and can review them later in the project. This is extremely helpful should you have to onboard new team members after the project has already started. The documentation should include Jira workflows, sprint cadence, team calendar, sprint meeting schedules, and other relevant items.
- Consider having a pre-planning session weekly with just your technical leads. This meeting should precede the normal team sprint planning session. You can set sprint goals, review the prioritized work, and fill any gaps while the other folks on the team continue with their development activity. This saves the team time and frustration.
- Be realistic about your team’s strengths and weaknesses and plan and distribute work accordingly. Not all resources are created equal. Look at your expected burndown with an eye for team members’ skill sets and task dependencies.
- Make sure you factor in vacations, holidays, and other non-related project work that needs to be done when you determine team velocity and overall capacity. You will eventually get a velocity metric that you can rely on; however, your project might not last that long! Look at capacity and velocity by groups of skills to ensure you have the right mix.
- Be aggressive in your use of the team’s time. Not everyone asks for more work, so keep an eye on the free time of folks finishing work mid-sprint. You can optimize what you get done if you make sure that the team stays busy.
- Create Jira filters for your project board. JIRA filters that present stories by person or other helpful views can be a life-saver. Consider using them.
- Schedule a cadence of meetings that DOES NOT CHANGE. This sets the right expectations with the team and folks can plan their schedule accordingly.
- For a new product release, consider having two project teams. The core project team is made up of developers writing code, while an extended project team does everything else that is needed to make the launch successful OUTSIDE of software development. This includes such things as developing marketing collateral, customer service training, environment set-up, etc. It’s naive to think the other stuff just happens. It doesn’t.
- Establish checkpoints and make adjustments along the way. How you envision the product when the project starts is not where it will end up. Constantly review budget, team mix, and skillsets needed--make adjustments to ensure success.
As your project gets underway, don’t forget about managing communication upward. Having regular monthly stakeholder meetings helps set and manage expectations, outline any risks and dependencies, and ensure the folks that are funding the effort are informed. It also squashes the rumor mill and allows you to tailor the message monthly to the information that is most important to communicate at that time. You can highlight team accomplishments, go over risks, and discuss any budgeting concerns. This quick 30 minute to 60-minute meeting has saved our projects too many times to count.
Between the two of us, we hold Scrum Master, Advance Scrum Master, Agile Practitioner, and PMP certifications. All of this training is extremely useful to understanding how projects should be run and executed. It makes great reference material as you are in the trenches doing the work. However, make sure you are making decisions and managing the project based on “what works.” Each company and project dynamic is different so don’t be afraid to ADAPT and apply a healthy dose of common sense.
