Agile and lean methods for managing application development process

Transcription

1 Agile and lean methods for managing application development process Hannu Markkanen

2 Lifecycle model To support the planning and management of activities required in the production of e.g. goods, software, or information systems, various lifecycle models have been developed A lifecycle model establish the order in which a project specifies, prototypes, designs, implements, reviews, tests, i.e. performs its activities. Waterfall Code-and-Fix Prototyping 2

3 Generic Project Life Cycle Phase Defining (or Scoping) Planning Executing Monitoring/Controlling Closing Tasks Defining the high-level objectives and requirements of the project What, who, when? With what resources? Organising people Allocating resources Scheduling the work Tracking of progress Taking corrective actions Reflecting and improving continuously (lean) Evaluation of what was done Information for later projects 3

4 Waterfall model Strenghts The waterfall model performs well for projects in which you have a stable product definition Do such projects exist? Weaknesses The waterfall model is inflexible. Is it possible to specify the requirements at the beginning of the project? Is it possible to design and implement all parts of the application at the same pace? 4

5 Code-and-Fix Strenghts No planning and design overhead, time is spend on pure coding Requires no process management experience. Weaknesses Useful only for tiny applications. In case of real life projects, dangerous! 5

6 Prototyping Develop a prototype, show it to your customer, and refine it based on the feedback Strenghts Flexibility (with changing requirements) Reduced time and cost Weaknesses Can distract developers from properly analyzing the complete project Can easily result in the code-and-fix development. Good for applications with lots of user interaction Most Agile Methods rely heavily upon prototyping techniques. 6

7 Overview of lean and agile software development

8 Lean software development Lean software development is an adaptation of Lean manufacturing principles and practices Based on the Toyota Production System The core lean principles: Eliminate waste Extra features (unnecessary functionality) Partially done work Task switching Delays (waiting for work) Bureaucracy Defects Focus on learning and improvement Build quality in the process Decide as late as possible Deliver as fast as possible (customer value) Empower the team 8

9 Two Axioms of Lean Software Engineering (David Joyce) 1. It is possible to divide the work into small value adding increments, that can be independently scheduled 2. It is possible to develop any value adding increment in a continuous flow, from requirement to deployment 9

10 Dividing the work to small increments 10

11 Dividing the work to small increments Time on the job Client Time of getting the first batch Time of whole production 11

12 Agile software development A group of software development methodologies based on iterative and incremental development Requirements and solutions evolve through collaboration between self-organized cross-functional teams Agile Manifesto - values: 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a detailed plan Popular Agile methods Extreme Programming (XP) Scrum 12

13 Agile practices User stories Regular meetings Planning meeting Daily Stand-up meeting Retrospective meeting Refactoring of code Continuous integration 13

14 Scrum overview Short, time-boxed iterations 14

15 Kanban

16 Background of Kanban Kanban is a Japanese word that literally means signal card In a manufacturing environment, this card is used as a signal to tell an upstream stage in a process to produce more Kanban is a pull system New work is pulled into a stage in the system when there is capacity to handle it, rather than being pushed based on demand The workers at each stage in the process are not allowed to do work unless they are signaled from a downstream stage A pull system cannot be overloaded if the capacity of each step has been set appropriately The first kanban system for software engineering was implemented at Microsoft beginning in

17 Kanban as an Adaptive System to achieve Lean The Kanban Method is an adaptive system for catalyzing Lean behaviour (complex, adaptive, emergent behavior) Kanban core concepts Visualize workflow Limit Work-in-Process Help work to flow Kanban is not a software development methodology Does not provide methods for any particular development task, like testing or requirements Teams adopt practices e.g. from agile methods (such as pair programming in XP) 17

18 Implementing Kanban

19 Work Item Types Identify the types of work that will need to be limited. Typical work item types: Incoming work E.g. User Story, Use Case, functional requirement, feature, The incoming work type might be hierarchical, such as Epic, a collection of user stories. Bug Change Request Maintenance Refactoring Improvement Suggestion Infrastucture update Blocking Issue 19

20 Kanban workflow There is a queue of work, which goes through a number of stages until its done When work is completed in a stage, it is pulled downstream for the next stage 20

21 Kanban board Vertical columns for stages (phases) in the workflow, i.e. activities through which the work progresses Input queue ( Backlog ) Done stage ( RTS ) Work-In-Process (WIP) limits The max number of work items that can be in a stage at any moment Typically, the work-in-process limits are drawn on the board at the top of each column (or across a span of columns) Pull is signaled if the number of cards in a column is less than the indicated limit Why WIP is important? To deliver new value quickly, limit the amount of work done at one time Context switching costs 20% productivity 21

22 Setting the WIP limits WIP limits for work tasks should be set as an average number of items per person, developer pair, or small, collaborative team Typically, the limit should be in the range of one to three items per person, pair, or team Do not waste time in trying to determine the perfect WIP limit; simply pick a number based on best guess, and make progress Adjust the WIP limit empirically if necessary There is no magic formula for your choice. You can select a number and then observe whether it is working well. If not, adjust it up or down 22

23 It s a Mistake Not to Set a WIP Limit The tension created by imposing a WIP limit across the value-stream is positive tension This positive tension forces discussion about the organization s issues and dysfunctions The dysfunctions generate impediments to flow and result in sub-optimal productivity and quality The discussion and collaboration invoked by the positive tension of a WIP limit is the mechanism that enables the emergence of a continuous-improvement culture 23

24 Kanban card conventions Use text or color to communicate the work item type Write other necessary information on the card as well, e.g. assigned staff member start date electronic tracking number, status information (such as whether the item is late) 24

25 Kanban board examples 25

26 Kanban board with swim lane for urgent work 26

27 Electronic Kanban board For teams that are distributed geographically, or with members working from home In your project, use one of these free tools: (or 2.0 beta at: 27

28 Coordination within Kanban Issue management, escalation, and resolution is a core discipline in improving the performance of a team and should be addressed early in the development of the team Daily standup meetings should be used to discuss issues, impediments, and flow Holding regular meetings reduces the coordination cost for those meetings and improves attendance Daily standups are an essential part of the culture of continuous improvement Provide an opportunity for all stakeholders to suggest and discuss improvement opportunities The period immediately after the standup often develops into an informal process improvement discussion (After meeting) 28

29 Daily Standup Meetings The Kanban board contains all the information about who is working on what The project manager will walk the board The convention has developed to work backward from right to left (in the direction of pull) through the tickets on the board. The facilitator might solicit a status update on a ticket or simply ask if there is any additional information that is not on the board and may not be known to the team We will practise these during the project class sessions on Thu/Fri 29

30 The After Meeting The After Meeting consists of small groups of 2 or 3 people meeting after the standup To discuss something specific topics perhaps a blocking issue, perhaps a technical design or architecture issue, but more often, a process-related issue After Meetings generate improvement ideas and result in process tailoring and innovation The After Meeting is a vital element of the cultural transformation that emerges with Kanban We will have these during the class sessions with any group who indicated need in the standup meeting 30

31 Queue Replenishment Meetings Purpose is to fill the kanban system input queue ( ToDo ) for the project Features, user stories/epics etc. from the backlog (if in use) Prioritization of new work into the input queue for development At regular intervals Prioritization of new work involves coordination of many people from various functions Group of business representatives or product owners All interested members of the development team should be present 31

32 Retrospective meeting The whole team analyzes their own process At regular intervals 32

33 Issues = blocked work items A first-class work item type used to track problems causing other work to block. Usually indicated by a bright colour The issue will remain open until the impediment is removed and the original work item can progress through the system Issue management should be a strong focus of daily standup meetings 33

34 Writing user stories

35 Writing a user story Template: As a <some role>, I want <something>, [so that <some value>] Describe who wants, what wants [and what for] in one sentence. Do not define any details of the implementation in the user story. Examples: As an end user I want to be able to upload my picture to my profile page, so that people can easily identify me As a sales person, I want to see statistics of my performance in graphical charts, so that I monitor my performance As an administrator, I want to have database backups, so that I won t be in big trouble if something unexpected happens 35

36 Writing a user story Example of breaking down a story into smaller stories: Example of breaking down a story into tasks: Henrik Kniberg: Scrum and XP from the Trenches 36

37 Defining tasks Size of the tasks Practices vary, typically from one to few days of work Split too large tasks into smaller ones Writing too small tasks is a waste (defining takes more time than doing the tasks) Issues and critical tasks can be put on the board even if they are tiny not to forget Sizing is based on experience Write clear task descriptions Every team member must understand what will be done in the task Every team member can/should write tasks Team members pick the tasks, they are not assigned (e.g. by the project manager) 37