Published on March 6, 2014
flickr.com/photos/tprzechlewski Brief survey: • Who is working in a Scrum Team? • Who has visited a course, has read books or has studied the subject on its own? • Who thinks about Rugby or something else, but for sure not about your work as developer when hearing Scrum? Meaning of Scrum: Restarting the game or crowd of requirements Scrum is not an acronym and is not written capitalized (SCRUM is wrong) Picture under Creative Commons 2 from source: flickr.com/photos/tprzechlewski 2
One distinguishes between 1. Predictive Processes which try to pre-plan a project. 2. Adaptive Processes which regularly inspect the product and adapt during the process • In the beginning of SW Engineering, Software was work for single experts. They have created Software in close cooperation with Hardware development. • At the first SW Engineering Conference in 1969, the waterfall process was presented as an answer to the increasing size of Software projects. It is similar to building houses. • But Software development is unlike building houses: Software cannot be specified in the same exactness than a floor plan does for a building. Furthermore, Software has the possibility to be built, destroyed and re-built in a far higher frequency than a house. Early RUP based processes were focusing on an iterative approach which high customer involvement. • Unfortunately, RUP turned out to be very paper based and the early strengths of the process have been buried by pile of documents (literally). • The reaction to this heavy-weight RUP was the Agile Movements starting in the late 1990ies. RUP = Rational Unified Process, an iterative Software Development Process developed by Rational, later IBM 3
Early agile experts were called into projects which faced Analysis Paralysis: 3 years of writing documents, database schemas, designs, but no single line of working code. They have restarted the projects successfully by asking the Development Team to complete a concrete function within the next 30 days and presenting it to the management and customers. Scrum was first presented at the 1995 OOPSLA conference In 2001, several industry experts like Kent Beck, Alistair Cockburn, Martin Fowler, Robert C. Martin, Ken Schwaber, Jeff Sutherland met in a Lodge in Utah to talk over and sign the agile manifesto: • Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan www.agilemanifesto.org Many agile methodologies emerged , but today, Scrum and Kanban are the most used. 5
Let’s create a test system with LabVIEW: You receive a complete specification from your customer and answer in form of requirements which are reviewed and signed. You create an architecture and a design You define a project plan Picture from iStockPhoto, provided by Zühlke 6
…but in the middle of realization, the progress deviates from the plan. It needs a wonder in form of massive overtime, reduced test time and a lot of unmaintainable code to complete before the ultimate deadline. But the delivery meets the initial specification perfectly. You did it, you are happy. …but the customer is not happy from what he gets: Since writing the initial specification, he has learned a lot and changed his mind. And now, as he can see and operate it, he finds out that the initial specification was incomplete and full of inconsistencies. This phenomena is known as IKIWISI: I Know It When I See It. Welcome to reality! You might not face the above described effects in your project, but without regular inspection and adaptation the chances are high to observe one of the two effects. Picture under Creative Commons 2 from source: flickr.com/photos/tambako 8
Let’s create a test system with LabVIEW with another approach: You are about to receive a complete specification from your customer. But instead of waiting for him to complete them, you collaborate with him to UNDERSTAND the main goals/needs and features. Instead of detailing all requirements, you only do this for those with the most risks, the architecturally relevant ones, and those with most value for the stakeholders. You create an architecture, but no design. You now put the requirements and features into a Product Backlog. This is an ordered list. Ordered from the most risky and most wanted requirements down to the features which are wishes and maybe sometimes even dreams. The requirements on top are well understood meanwhile the wishes and dreams are just roughly sketched. 9
A Product Backlog is an ordered and estimated list of open work for a certain product. It is merely a todo list. It consists of so called Product Backlog item’s. Items are requirements, change requests, redesign work, bugs, etc. To describe items, the term 3C is often used: Card, Conversation, Confirmation. The card is a simple title to refer to the item. The conversation is the summary of all discussion taken place to detail this item: pictures of whiteboards, notes, references to requirements specifications. The confirmation summarizes how to test this item: sketch of test cases with real data. It serves as a checklist when accepting this feature before the Sprint Review. 10
Having a good understanding of the goals, the features and the most important requirements, you can invite for a first Sprint Review within the next 2..4 weeks. Select entries from the top of the Product Backlog and realize them with the Development Team. It is important to know that the Development Team has to organize their work on themselves. There is no project manager assigning work to single developers. This would lead to a team not feeling responsible for their work! Run the Increment (that is a working LabVIEW Software) on the test system (or a simulation, but as real as possible) and let the Stakeholders inspect it. Adapt the Product Backlog with the inputs of the Stakeholders and start with the second Sprint. • A Sprint is a time boxed event of max. 30 days where the Development Team works on defined goals to improve a product. The result of the Sprint is an Increment, an improved product. • At the Sprint Review, the stakeholders inspect the Increment • The Development Team is self-organizing and cross-functional: It contains all required resources to expand the product from Sprint to Sprint. • Stakeholders are sponsors, future users, domain experts, customers, etc. People that have a stake in the results of the project. • The feedback of the Sprint Review is added to the Product Backlog. This is an ordered list of all open work for the product. • Based on this Product Backlog, the Development Team plan the next Sprint in the Sprint Planning Meeting. The Sprint Planning Meeting starts just after the end of the last Sprint. 11
There is a lot of feedback from the 2nd Sprint’s Review. Who is ordering the Product Backlog? The Development Team is not involved in all management decisions and needs to focus on development, not on the politics of priorization. It is decided that the manager of operations is Product Owner: He is in charge of ordering the Product Backlog. All Stakeholders have to discuss the priority of their requests first with the Product Owner before approaching the Development Team. In the 3rd Sprint, the manager of support approaches a developer directly and asking him to implement a small little feature. The developer sees that this feature requires one day to realize and approaches the Product Owner whether he should implement it in this Sprint or not. The Product Owner has quick word with the head of support and decides that this feature IS NOT realized in this Sprint nor in the next Sprints since it has no priority in comparison to the other requirements. Without Product Owner, the developer would have implemented this request, would not have reached the goals of the current Sprints and would have been overwhelmed with new requests from the support team. This is not what we want… • The Product Owner is a single person that is responsible for the success of the product. He orders (prioritizes) the Product Backlog: He decides what the Development Team is working on next. • Based on this Product Backlog, the Product Owner and Development Team plan the next Sprint in the Sprint Planning Meeting. 13
Not just the Increment is inspected. Also the interactions of the Development Team, the Product Owner and Stakeholders, tools, and development are inspected. This is done in the Sprint Retrospective. The Scrum Master is responsible to introduce Scrum of the Development Team and also within the organization. He is responsible that the Sprint Retrospective, the Sprint Review and Sprint Planning are taking place and are effective. Product Owner, Development Team, and Scrum Master form the Scrum Team The improvements defined during the Sprint Retrospective are used to make the next Sprint more effective than the last one. Constant learning. 14
During the Sprint, the Development Team meets to a Daily Scrum meeting. Within this 15 minutes time boxed meeting, the developers tell what they have done, plan to do next and what problems they have. They inspect their daily work and adapt the plan for the next day. Discussions which are not of interest to all developers are postponed to directly after the Daily Scrum. This assures the interest of all developers within the timebox and is the trick to keep the meeting short. Standing is another trick to keep the meeting short, but this is not a must. 16
That was the description of Scrum. It is not more and not less. Scrum is described in the Scrum Guide on 16 pages. The Scrum Guide is frequently adapted by the inventors of Scrum, Jeff Sutherland and Ken Schwaber, and inspected by a large community. 17
Scrum is… • Not a process that defines every aspect of development! Scrum focusses on the really important aspect of process management and interactions between people. There are additional engineering practices like Test-Driven-Design, Pair Programming, Collective Code Ownership, Agile Estimation and Planning, etc. that work perfectly together with Scrum. But they are not part of Scrum. • Rather a framework to address complex problems, very lightweight (Scrum requires 16 pages to describe, has 3 roles, 5 meetings and 3 artifacts. RUP requires 1 DVD for its description, has 20+ roles, many more meetings and hundreds of artifacts (documents) ) • Extremely simple to understand, like chess. • Extremely difficult to master, like chess. Picture from iStockPhoto, provided by Zühlke 18
One more thing to add: At the Sprint 4’s Review, a Stakeholder asks how much this is going to cost and when it will be finished. The Development Team and Scrum Master have prepared for this question. They have estimated the content of the Product Backlog, recording what they have done and what is open each Sprint and drawn a Release Burnup based on this data. Thanks to their focus on getting features done, ready for usage, they are able to provide a reasonable forecast. This forecast bases on real data and is ways more precise than any other traditional approach! 19
• After Sprint 5, a dedicated production step could already make use of the new solution. • At the Sprint Review of Sprint 6, support came with massive new requests • It took the Product Owner two Sprints to convince management and support to postpone those requests to another release (with separate funding). The Release Burnup helped him to visualize the negative effect of those new requests. • After Sprint 10, the budget was used. The Development Team has developed a nearly complete solution. Thanks to their focus on important things first and on completing features rather than starting everything, the missing two items are of low importance and production can live without them for the time being. 20
Picture under Creative Commons 2 from source: flickr.com/photos/tprzechlewski 21
Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...
In this presentation we will describe our experience developing with a highly dyna...
Presentation to the LITA Forum 7th November 2014 Albuquerque, NM
Un recorrido por los cambios que nos generará el wearabletech en el futuro
Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...
Scrum Overview for Agile Software Development Scrum is an agile process most commonly used for product ... Introduction to Scrum Agile Trainer, ...
... Schwaber worked with Mike Beedle to describe the method in the book Agile Software Development with Scrum ... of the development team, and developer ...
Within agile development, Scrum teams are supported by two specific roles. The first is a ScrumMaster, ... In Scrum project management, ...
Our Certified Scrum Developer Lab equips you with the ... Driven Development ... to understand applied Scrum and Agile engineering practices and ...
Strengthen your technical skills in Agile software development Certified Scrum ... of Scrum. By earning a Certified Scrum Developer ...
The Professional Scrum Developer course ... Scrum and Agile Webcasts; ... Modern Tooling and Practices for Scrum Development Teams.
Das Kursprogramm des „Certified Scrum Developer“ (CSD) ... Inhalte des Kurses "Agile Developer Skills" Architektur und Design; Zusammenarbeit;
2001 veröffentlichten Ken Schwaber und Mike Beedle mit Agile Software Development with Scrum ... Professional Scrum Developer ... Scrum Development ...
What is the difference between Scrum and Agile Development? ... How does Scrum fit into Agile Development? ... developers can’t go back to a previous ...