I recently taught a Certified ScrumMaster®(CSM) Class at Watermark Learning. Because our time in class is limited and our class backlog is full of activities, exercises and simulations, I rarely have enough time to address all of the questions raised. Blogging, while limited in space, does allows me the opportunity to address these questions while also sharing my perspective with the broader Scrum community.
In Part 1 of this blog, I addressed a couple of questions, one related to the use of Agile Tools, the other regarding how to use Agile in working with a vendor.
Let’s take a look at a few additional questions raised in a recent CSM.
Can Scrum be used when some of the people are onshore and some are offshore?
Scrum as an Agile method values “face-to-face” communication. While this principal is commonly seen as an argument for co-location, teams that are not geographically co-located can benefit from executing Scrum in a distributed model. Martin Fowler of ThoughtWorks wrote a blog containing a number of recommendations that teams can follow if they are working in such a model. However, a couple of important caveats are warranted.
First, working in a distributed environment is going to require a greater level of discipline than that required when executing Scrum with a co-located team. All of the geographies will need to ensure that they over-communicate, leverage collaboration technology such as WebCams and be flexible regarding when they conduct events like the Daily Scrum.
Additionally, fully-staffed Scrum teams should be formed in each geography. While not always possible, Scrum works best when a team, regardless of location, can self-organize and inspect and adapt together. Putting one specialty, such as testing or development, offshore and expecting to receive the benefits associated with Scrum – greater collaboration, innovation and value is a misplaced expectation.
Transitioning to Agile – Where’s my project plan? What will my team have done in two months?
Scrum has no project plan. Most project plans are overly precise attempts to predict an uncertain future. If someone requests a project plan for a Scrum-based effort, you can simply provide a plan that shows the start and end dates for each sprint. When they ask, “But, what will I get in each sprint?” Your answer is simple, “A potentially releasable product increment that includes what the Product Owner has deemed most valuable.”
While not an official part of Scrum, Release Planning and its associated output, a Release Plan, can help answer the questions such as “When will you be done?” Release Planning comes from another Agile method, Extreme Programming, and allows a team to use its velocity (the amount of work that it completes in a sprint) to plan what it may accomplish over the next few sprints. Notice the emphasis on “may” in the previous sentence. A Release Plan is not a contract. Scrum is an Agile method which means that it values “responding to change over following a plan”. This means that a Release Plan can and will change.
Additionally, in order for velocity to be used as a planning metric the following must be held constant: the scale used to measure it, sprint duration, and the team. Most organizations that are new to Scrum struggle with multi-tasking people and/or making team changes that prevent them from establishing a consistent velocity that can be used for planning.
Tracking Financials – How do I track a Scrum-based product development effort?
Tracking the financials of a product development effort using Scrum is simple. The first step is calculating the total cost of the effort which begins with calculating the cost of a sprint.
Scrum requires a dedicated team so calculating the cost of a sprint is as simple as taking the burdened labor rate per hour (ask your finance person for assistance with this data) and multiplying it by the number of people on the development team and the number of hours in the sprint.
For example, if the development team is executing 2-week sprints, is comprised of 6 people, and has an hourly burdened labor rate of $100/Hr, the Cost per Sprint can be calculated as follows:
6 people * 60 Hrs * $100/Hr = $36,000 Cost per Sprint
Once the cost per sprint is established, multiply it by the number of sprints planned for the effort to determine the overall labor cost for the effort (Note: Hardware, Travel, Meals, etc. need to be added to determine the total cost). The forecast number of sprints can be determined by either conducting Release Planning or by simply having a conversation with the Product Owner regarding the level of investment that he or she would like to make in the product.
With the cost per sprint and the total cost of the effort determined, the financials for the effort can be tracked on an incremental basis following each sprint.
Additional Questions or Comments? – Join us at a class
Have additional questions or comments on these responses? Please let me know by leaving a comment below or, better yet, attend our next Certified ScrumMaster® course at Watermark Learning.
And if you’re ready to take the agile philosophy to the next level, check out what we have to offer at agilityIRL to deepen your Scrum mastery, and to expand the agile philosophy by applying it at an organizational level.