The Rockefeller Foundation is considered a private Foundation. We are a nonprofit, but rather than raising funds from the public or government, which

Transcription

1

2 The Rockefeller Foundation is considered a private Foundation. We are a nonprofit, but rather than raising funds from the public or government, which is typical for a non profit, we have the money in the bank, and then we make payments to other organizations who are working to solve the global problems we think are important, in the form of grants. As a grant making organization, our primary business system is our grants management system. It tracks all of our grantees and all of the details of the grants that we make, including contacts, payments, and documentation, among many other things. This system was the focus of our initial scrum projects, which you will hear more about.

3 John D Rockefeller started the Foundation back in 1913 with an endowment of his own funds, and the money has been re invested over the years, with just 5% spent each year. This allows the Foundation to continue to do good work in perpetuity. Our mission, unchanged since 1913, is to Promote the Well being of humanity throughout the world.

4 We see this as an internal innovation, appropriate for our centennial year where we celebrate past innovations and look toward our centennial slogan of Innovation for the next 100 years

5 We are a global organization. Our headquarters is in New York City, we have regional offices in southeast Asia in Bangkok and in sub Saharan Africa in Nairobi. We also run a conference center in Bellagio, Italy.

6 We ve seen an incredible shift in the way we work over the last year, and have found many opportunities to use Scrum in our organization, as well as other concepts like Kanban.

7 In our discussion with the COO, we compared the concept to the NYC subway repair program started in the last few years called Fast Track, where instead of working part time on subway repairs on a particular line over months, they completely shut the line down overnight for a week, allowing them to fully focus on the repair work and get it done faster. We felt that this was the same concept we would be getting with Scrum. We wouldn t be bringing our systems down to work on them, but what we would do is bring a team together to focus on the project every single day, allowing us to get the work done in a dedicated fashion, and therefore faster. Our COO loved the comparison and we decided to call the effort RF Fast Track.

8 Cross functional team Pulled together cross functional team including IT internal project manager, business analysts, and consultant developers, grants management, program staff. For program staff, we asked for a daily commitment, and up to 1 day per week. Scrum master from IT, Product owner from Grants Management, and we added formal QA role (new for us). Backlog team concept developed as way to use program staff We also came up with the concept of a backlog team, essentially to be filled by the staff who were representing the end users. Their role would be to work with the product owner to build the user stories that would go into the backlog. In classic scrum, everyone is allocated 100% to the project, which is not possible for us. Team work space Initially we used an empty office near the IT department, and when IT moved to a different floor, we moved to an available cube. This proved to be a great place to put our project visualizations, hold our stand up meetings, and meet with our product owner and key user stakeholders without needing to reserve conference rooms. Lync was used when team members were not in the office (consultants working remotely part of the week). Initial project management using SharePoint team site and Excel evolved into using Rally webbased software to allow Product Owner to develop the backlog and plan, and providing a virtual task board and other reports for the development team s use during sprints We started with a 2 day onsite training for the entire team including IT, grants management, and program staff. Then we engaged with agile coach twice per week to get the project started the week after training. The coach continued with us twice a week through early 2013, tapering to once a week as the year progressed and projects changed. 7

9 This is our Task Availability spreadsheet that we used to determine how many hours each development team member was available to work on sprint related tasks. For each team member we would track the full and half days they were available to work by indicating 0, 4, or 8 for each date of the 10 day sprint. Adding these numbers together would give us that team member s base availability. We would then calculate their project availability based on the estimated percentage of time they could work on the sprint related to other project work and production support. We would then subtract the hours spent in sprint related meetings to get their actual hours available to work on tasks. For this 10 day sprint we had 16.5 hours of meetings including planning, stand up, the review, and retrospective. Not all team members were required in all meetings so that was taken into account when calculating task availability.

10 Here is our Fast Track team work space. We still like to have the physical visual indicators out in the office. It is more impactful to watch than the web based progression and a good advertisement for the process to other staff. This cube is in a high traffic part of our department where other staff walk by to use our collaboration zone or the restroom.

11 Fast Track 1 & 2 These were the perfect pilot projects high visibility / low technical implementation risk / high value to organization. There was a hard deadline to deliver grant approval was 12/31. It seemed like an overwhelming amount of things to get done and our prior track record said would be a big challenge to do this. Sprint 0 was 1 week of transferring business requirements into user stories. This was a big shift from the way we used to do things projects were semi ready to go with waterfall style requirements documents. This was a big task for the product owner to do and team to understand stories and acceptance criteria with real examples.

12 Here s the actual timeline for our first Fast Track projects 6 sprints from mid October to mid January all components delivered by January we were able to include a workflow not originally planned BONUS workflow After training we were up and sprinting within less than 2 weeks Probably the worst time of year to start sprinting with holidays and year end processing Plus we lost a week due to our office being dark after Sandy and our main developer was out on paternity in January Using the scrum framework helped keep us on track We had our first release during sprint 2 and got the Grant Approval workflow in production by mid December, ahead of schedule

13 Validating scrum/fast Track model Fast Track projects 3 and 4 were considerably more complex involving a lot more ambiguity of what the stakeholders wanted. This was a great opportunity for us to put the Scrum framework to the test to see if it would help us with more complicated projects. Projects gave us opportunity to refine the fast track model we were able to adjust and improve our execution using Scrum. Due to the nature of these projects, each project had a separate product owner. They worked together on the backlog with the same backlog team, as they were complementary products. Having separate product owners was a huge challenge for scheduling meetings and sprints. For Fast track projects 3 and 4 we scheduled a longer planning period (sprint 0), spanning a 3 months, when the product owners worked on stories for the backlog with backlog team members and met with the Scrum master and Agile coach periodically. Towards end of sprint 0, we went through roadmapping exercise, where we took the high level stories and mapped them against a timeline, including concepts such as resource availability, foundation wide meetings, and other internal processes like budget forecast and planning Started development sprints in April, and delivered virtually everything mapped out by August. We ended up switching back and forth between developing features for each project, instead of developing them simultaneously like Fast Track projects 1 and 2.

14 At the end of sprint 0, the product owners, Agile coach, and Scrum master met to plan our work on these projects from April to August To create the roadmap we used a swim lane diagram where we mapped users, key events and business dates against features, usability testing and training, and developed a tentative release schedule. Bottom depicts when the sprints occurred and what was delivered in each sprint. Color coded to project (blue for Planning Tool and green for Dashboards) so you can see when we were switching between projects in our sprints. Compared with using a waterfall approach to planning, our thoughts were often not documented in such a visually transparent way and with the different dimensions.

15 What went well Planning meetings extremely useful to get cycles going Estimating availability and time commitment. And there was a true commitment by all team members especially Product Owners compare when don t have the commitment just not as seamless, etc. What didn't go well Confusion around non IT staff involvement in the beginning as we learned how to use the cross functional team effectively. In the beginning, there was confusion around the role of the non IT staff on the team and how to use our cross functional team effectively. Even with the notion of a backlog team, we had a hard time articulating to management exactly what they were going to do and exactly what the time commitment would be. There were also too many meetings as we got used to the process. It took some time for us to figure out the right set of meetings, the time required, and who needed to be present. We also learned how to take all of the meetings into account as we planned our available hours for a sprint. Lessons learned Sprint 0 concept In Fast Track 1&2, we didn t build time for user story preparation and it constantly felt like we were playing from behind, whereas in the 2 nd set of projects, we built a lot of time up front for this process, and as a result it felt like the backlog was properly prepared for each sprint. Fail fast The style of working in short sprints, combined with periodically bringing users in for usability testing, allowed us to get great early feedback. There were a few features that were quickly modified and tweaked in the following sprint after we put them in front of users. The last lesson learned is around budgeting.

16 Budgeting in general We learned how to budget for these kinds of project, mostly by creating a cost per sprint, and put it together in a way we could share it with management. Working in an agile way is a great way to get things done faster, more correctly, and more in line with what the users want. However, it generally does not save you money, as the amount of work required is the same, but the work is done in a more dedicated way. For us, this work is expensive because we mostly rely on consulting resources. With that said though, because we are working smarter and more directly addressing the needs of the users, the value we get back for the money spent is significantly higher than what we got using the waterfall method. Classic Fast Track: In this model we utilized teams of 7, with 3 of the resources as consultants. After the initial sprints, we were able to determine an average cost per sprint for a project of that size. Expedited and Balanced Fast Track: Most of our projects are smaller scale though, so we also calculated the resource requirements for smaller projects, and the expected cost per sprint. These calculations allow us to better forecast how much a particular project would cost, or for a project with a particular budget, how many sprints we would be able to complete. One last point to note about budget is that in addition to budgeting for each sprint, you also need to factor in the time for sprint 0, as well as time for the final production rollout, which typically includes some training and technical support. Sprint 0 and 1 will typically have a higher cost, but after that, the cost for each sprint becomes very predictable.

17 In particular, as the Fast Track projects were large efforts for us, we needed to scale down the model to fit our more typical smaller projects. We experimented with the model on 2 particular development projects. We also used the retrospective meeting as a concept to perform informal mid year three sixty performance assessments in IT, with both staff and consultants. In those meetings, manager and employee (or consultant) would each discuss what went well and what didn t go so well and ideas for improvement, from their point of view. We found that this method led to a more open and constructive dialog, rather than a 1 way conversation.

18 KanBan literally means billboard or signboard in Japanese, and is known as a visual scheduling system for just in time production. It is based on the principals of visualizing a workflow and limiting the work done at each step based on the capacity of the team members, where the highest priority items are the ones pulled from the backlog when the team member has availability to work. The tool we use for Kanban tracking is a web based tool called Leankit.

19 You should be able to tell by now that we love working with Agile! The next step for us is to figure out how to introduce it to the rest of the organization. We are trying to propose a working group for next year to explore further. The thing that we find notable about our story is that may not be a traditional kind of agile shop. We are not a software company, and we are also not a big organization with lots of IT resources where we can fully dedicate a team to a project, but we ve found a way to make it useful.

20