bio:
Thijs de Hoop After my studie in IT I worked for Accenture for 2,5 years. These years I learned a lot. We used most of the time RUP as sta... Read More
Thijs de Hoop
After my studie in IT I worked for Accenture for 2,5 years. These years I learned a lot. We used most of the time RUP as standard of working.
I am working for Quintor since april 2008. The projects we do there are Scrum-projects. In march 2009 I certified as Scrummaster and started as scrummaster on april 2009. During this project I also coached the productowner in his role.
work:
Agile coach at VX Company
Baarn,
Netherlands
www.vxcompany.com
January 2011-Present
I work as Agile coach with VX Company. I cotrain different agile courses (Agile introduction/Scrum/Kanban) with my collegue and did one training on my own.
I started working on the project Soweto Care Systems as Scrummaster and scrumcoach for 4 months. We implemented Scrum within this project.
Another project I worked on is within ING and I work there within more small teams.
I worked as scrummaster, gave an introduction to Scrum for my department and advise on the scrumimplementation choosen for now.
----- Soweto Care Systems -----
Soweto Care System is database software, designed to facilitate the client administration of NGO’s, focussing on Home Based Care, Orphan & Vulnerable Children and Voluntary Counselling and Testing. But for any other organisation providing services to a client base, Soweto Care System can also be a very useful tool. Clients, employees, home-visits, client needs and programs can be entered and updated in Soweto Care System. Comprehensive reports for management and donors are easily generated. Management information is available at the click of a button.
Easy to Use
Soweto Care System is easy to use. Employees and clients can be entered in the system with all sorts of details. Of course name, address, gender, ID number, nationality, but also a client’s full medical history and details on their family, household, finance, school, immunization, housing and ‘needs’.
NGO’s using Soweto Care System can retrieve accurate client information at any time. It can be updated and on-screen analyses are easy to make.
Many fields only allow for drop-down box values, thus securing data quality. NGO’s customize the system by setting the drop-down values they need. Few fields are mandatory; NGO’s decide what fields are relevant for them.
Reporting
A number of reports can be generated at any time and for any reporting period. An NGO thus knows how many employees or clients they had in a reporting period; how many home visits were made, how many clients suffer a specific condition, are orphan, vulnerable, live in a specific area, etc.
The reports enable NGO management to analyse their performance and donors can be informed in great detail. Reports can be exported to Excel for further analysis. Reports with all details for a specific Client, Employee or Program can be generated and printed; enabling NGO’s to keep accurate hardcopy files on record at all time.
Technology
Soweto Care System was developed with open source technology: Java, Hibernate and MySQL, free of license fees. Soweto Care System runs stand-alone on a PC or can be used simultaneously by multiple users in a computer network. A PC with Microsoft XP or Vista is needed. A two day training by an experienced consultant is needed to help tailor Soweto Care System to their needs and train the employees.
2011-Present
Scrummaster at Quintor
Groningen,
Netherlands
www.nxpublisher.nl
May 2010-September 2010
I was working on a project called NX Publisher. I worked in a scrummaster and developer combination role on this project.
NxPublisher is an online editor for editing printed material, also known as Design-to-Print.
NxPublisher can be applied as a webshop, for printing offices or designers, as well as large organisations with specific guidelines for their corporate identity.
Because the editor works with Adobe's IDML-files, a seamless integration with Adobe InDesign is created. That way you can easily transfer your templates from Adobe InDesign to NxPublisher. After you edited your document in NxPublisher, you can also download the IDML again and open your document in InDesign. It's also possible to let NxPublisher generate a (hi-res and lo-res) PDF for you.
Your users can save, delete, edit and order their products.
2010-2010
Analist, Scrumcoach and Scrummaster at ABN AMRO Dialogues Technology
Amsterdam,
Netherlands
http://www.dialoguestechnology.nl/
August 2009-May 2010
Within this project I worked as an analist within multiple projects. The projects were all kinds of little startups and were very different from each other. I worked as analist and helping to implement the standard methodology (Scrum) within all the little projects. Sometimes by helping out as Scrummaster and other times with coaching the different people in their role.
2009-2010
Scrum developer at Van Gorcum
Amsterdam,
Netherlands
April 2009-August 2009
A project where we build a site for a closed user group where they could create a family tree with a lot of context around it.
2009-2009
Developer / Scrummaster at ABN AMRO Dialogues house
Amsterdam,
Netherlands
August 2008-April 2009
Developer and scrummaster on a scrum project. We worked in a team with 4 developers and 1 scrummaster/developer and a productowner.
The project consitst of a network site for ZZP-ers. We rebuild this site in a current framework using java and Flex
----
Applicant Information
Project-Related Questions
1. By answering the questions below, please describe one project during which you have used Scrum in the past year. Answer all that apply or enter NOT APPLICABLE for those that do not apply to your project.
1.1. What was the purpose of the project? What business goal was the project intended to deliver?
A social business network for starting entrepreneurs. Flametree delivers possibilities to build a network online and to search people based on their skills and interests. Flametree offered on and offline meeting possibilities and an easy way to keep your network up to date.
1.2. What was the duration of the project?
Half a year
1.3. What was the cost of the project? How did budgeted costs compare to actual costs?
The project costs were around €90000,- and the delivery was on time and on budget. This also due to the fact that the project had more features included during the process. So we delivered more for the expected costs.
1.4. Explain the value of the project. How did projected benefits compare to actual benefits?
The project was expected to be a big success but eventually there was not a good market for the product also because there were a lot of competitors on this market.
1.5. Describe the size of the project. How many people were on each of the project teams? How were they organized into teams?
4 developers from Quintor (1 is the scrummaster)
1 designer from a third party
2 testers from Flametree
1 productowner from Flametree
We had a development team (Quintor) and a team Flametree that were our business and the designer was not a full-time designer from a third company.
1.6. Describe the project’s teams. Were the teams cross-functional and self-organizing? Were the teams collocated in an open space? Were the teams physically separated within one location, or located in more than one physical location?
The developers were sitting in an open space and were cross-functional. We were Pair programming to spread knowledge. Every day we started with a standup together with the product owner and testers who were located at a different location.
1.7. Describe the project’s initiation. How was the project initiated? How were the teams trained to use the Scrum framework?
We had two certified Scrummaster and experienced developers at the start of the project. This grew during the project to four certified Scrummasters. For the Product owner and testers who were working for our customer we had a workshop organized to tell them the basics about scrum.
1.8. Describe project reporting. How did you report progress to management and to customers?
We used a general tool for issues/stories (Jira with Greenhopper) for communication between productowner, scrummaster, the team and the testers. Everyone was informed about the state of issues when they needed to do something using mail. The product owner informed users using a blog to inform them on some new features. Further we used the demo to inform stakeholders and the team, product owner and testers about the new features that were developed.
1.9. How was change handled? What difficulties surfaced by using the Scrum framework that had to be resolved? How were these difficulties resolved?
Change was managed by the scrummaster during the project. During the sprints changes were by default not allowed in the current sprint. This to keep the sprint closed and the commitment from the team unchanged. Only when a critical change was asked for by the productowner we tried to place the userstory, after we played the pokerplanning game for it, in the current sprint. But because the sprint was already closed for every story the same amount of storypoints have to leave the sprint, and the stories that were excluded must not have any work done on them. During the full project this occurred a few times and only on the end of the project. We were very happy with a productowner who also participated in achieving this.
1.10. Describe management of the project. What was the previous role of the ScrumMaster? Who took on the role of Product Owner? To what degree were they successful in fulfilling their roles?
The previous role of the scrummaster was developer on another team. He became scrummaster after seeing others do it and after doing the scrummaster training. The Productowner role was fulfilled by the manager of the company that gave the order to build the system. He was supported by an analyst from our company to help him and coach him in his task.
1.11. Describe engineering. What environmental factors or software engineering practices had to be changed?
We were used to using software using Scrum and had everything in place for this practice in the start of this project. We were to choose the methodology.
1.12. Explain stabilization. For how long did the software have to be stabilized before it could be released? How did you structure this stabilization process?
The software did not need any stabilization according to the productowner. We used a codefreeze for half a day were we could prepare for the release and make everything ready. During every sprint we had the productowner test all the issues and in an interval of approximately one week a team of testers would do a short regressiontest on the source and once per sprint a full regressiontest.
1.13. Describe the success of the project. To what degree was the project successful? To what degree was Scrum instrumental in the project’s success?
The project was a big success we delivered on time more functionality than was originally asked. The productowner was very busy with testing the issues. At first he thought it would be an easy job, but in the first sprint he discovered it was allot of testing work, after that the speed increased of the development and the work became much more. The developers were dedicated on delivering the job and enjoyed the process very much. The scrum instrumental was used as much as possible. We used demo, retrospective, sprintplanning, the steady sprints, the steady pace (2 week sprints). We used an extra “pre-sprintplanning” meeting to discuss the next sprint with the customer and to assign storypoints to the issues. We used a backlog for the productowner (500+ userstories with also ideas), a prioritized backlog(filled by the productowner and seen by the team) and the sprintbacklog during the process. We also used the burndown chart in greenhopper but for extra clearity also a physical one on the scrumboard. We tried to spread the knowledge through the team by pairing and code review where needed.
1.14. Describe how the Scrum framework was implemented on this project. To what degree was the Scrum framework implemented "out of the box?" To what degree did you have to modify the Scrum framework for this project? For each modification, how did you formulate it so that the basic inspect/adapt mechanisms continued to function? Which parts of Scrum could not be implemented or failed, and why?
We used Scrum out of the box, we used the daily standup, demo, Sprintplanning meeting and retrospective. We had a development team of 4 people and fulfilled the productowner and scrummaster roles.
We used steady sprint lengths throughout the project. The productowner was the manager of Flametree and he was a lot available for questions he functioned as productowner, tester and designer towards the team. He had a designer that delivered the images to him, and was first communicating to the productowner because that was the way the productowner and designer wanted to work. The productowner had also a team of testers on his site to help him with testing everything and to ensure stability to the team.
We had a daily standup to bring everyone up to speed on the progress. Next to that we had a physical taskboard on location to make changes in the state of stories visible. Later on in the project the team grew on the productowner side with the testers and we also introduced the designer in the team because he was more needed than we thought at first. All these people were also invited to join the standup, retrospective and demo meeting. We also introduced Greenhopper to make the taskboard available to all the different locations and teams.
The testers were testing every issue that was resolved by the development team directly. They received an automated mail about the issue that was ‘testable’ and the issue was generally tested within half an hour.
Every tester was also regressiontesting the application every week to prevent regression problems later on. This was also done in the sprint to have a deliverable product at the end of the sprint.
We used the demo for informing the stakeholders on the progress of the project if the productowner wanted this.
Every sprint was ending with a retrospective to try to improve the team and first look back but also try to define actionpoints for the coming sprints.
We started every sprint with a sprintplanning meeting where we tried to minimize the pokerplaning time and focus on committing to the sprint. We have done this by introducing a pokerplanning session every week and called this the ‘pre-sprintplanning’. The idea was to plan what we could plan. And for the other stories we delivered the questions to the productowner in combination with the analist. They would then spec the stories better. And we could try again to plan the story. Every story that was placed in the sprint needed to be ‘Ready’, so planned, specified, clear and with the needed graphics and designs.
General Questions
2. Answer all of the general questions about Scrum below:
2.1. How do you improve the accuracy of Product Backlog estimates? To what degree does their accuracy matter?
We used planning poker with the whole team in complexity point to make the estimates as accurate as possible. Complexity points and a reference story (one story that is used as reference for estimating the complexity of other stories) were a way to make the planning as loose from experience and the team as possible. What led to a good estimation of every story. During the project we saw that the experience in planning also helped a lot with making it precise.
2.2. How do you ensure that what a team commits to for a sprint is what the team actually delivers?
We tried to ensure this by keeping the sprints closed. The productowner had to tell us what to do for a short period of time (2 weeks/1 sprint). This short period of time made that the wishes do not change that much. Next to that every developer was responsible to not do extra work in a story. So when for example the productowner tries to slip in extra work in a story, the developer could ask him to create a new story or when he wants he could ask the scrummaster to talk to the productowner about this. The new story was placed in the backlog and was scheduled for the next sprint (generally)
2.3. Which metrics do you use to track the development process? Which metrics have been changed, removed, or newly implemented as a result of using Scrum?
We used the burndownchart to measure the progress during the sprint.
We had the taskboard physical and electronical to see in what state all the stories were and where the stories were piling up.
At the end of the sprint we would define the velocity of the team over the sprint.
We never allowed to talk about individual velocity to keep the team to use tooling as pairprogramming e.d. without worrying about the storypoints he/she did in the sprint or on that day.
2.4. What type of training, resources, or tools would best help you successfully implement Scrum in the future?
We have tooling right now that works quite well. (greenhopper, jira) to visualize the pregress and the scrum process.
2.5. Describe the largest impediments you have encountered in a project using Scrum and how you resolved them (or did not resolve them).
We had a designer that did not deliver the designs on time. This was due to his way of working and due to the productowner not accepting the designs.
We resolved this by letting the productowner accept smaller parts so he could give a go on some parts of the design so the developers could start working on it. This way the design was in a short time almost fully accepted excluding some small parts. So the team could continue and the design was delivered and accepted in the last sprint, so happy we did it like this.
2.6. Describe how you have worked with other ScrumMasters to advance the use of Scrum within an organization or within a community.
Within Quintor we work with multiple scrummasters together on projects and one person is the scrummaster for the project but others are in that project developers. This will give a lot of discussions on how to get our projects to a higher level. We try to offer the most optimum solution to our customers. We have a lot of discussion on what we should do and why we do things like we do them. One of the outcomes of these meetings/discussions is the pre-sprintplanning meeting.
Applicant Statement
With my signature below, I certify that the responses submitted in this application are my own work, ideas, and experiences using the Scrum framework and that work from other sources has been appropriately cited.
(Signature of Applicant)
(NOTE: A signature is required. If necessary, print, sign and scan your completed application form for submission.)
Submission Process
• Submit your completed application form via email to: practicingcertification@scrumalliance.org.
Thank you for your interest in renewing/applying for Certified Scrum Practitioner Certification.
2008-2009
activity:
No recent activity
events i’m attending
Thijs has no upcoming events.
events i've attended
groups i belong to
Thijs has no groups listed.
| Location: | Amsterdam |
|---|
Recommend Thijs