Sprints are not important

Transcription

1 Sprints are not important Software development in a complex multi-disciplinary project Jan-Mathijs Wijnands Hot-or-Not Bites 8 February 2012

2 Adapting the default way of working to our specific needs This is a story about our experiences with an Agile approach in a complex multi-disciplinary project. It s about changing the default Agile way of working to better fit our project needs. Sioux Technologies

3 Our goal is to print etch resist layers on PCB inner layers Copper panels of 24 x 21 Tracks of 100 microns 60 panels / hour Sioux Technologies

4 : the world s first industrial PCB printer Sioux Technologies

5 is a highly complex machine Highly accurate motion control. Advanced data pre-processing for accurate droplet placement. Machine vision for calibration & panel inspection. Real-time data processing for jetting. Distributed machine control. Remote diagnostics. Sioux Technologies

6 The machine complexity requires T-shaped people* A good mix between generalist and specialist: Depth in a specific domain. Broad enough and willing to pick up other work. T-shaped people is mentioned by Tim Brown in Strategy by Design Sioux Technologies

7 The typical board structure assumes interchangeability FEATURES feature generic acceptance criteria TODO improvement from retrospective yet another Acceptance criteria more work Question to product owner TODAY today s FINISHED finished finished another feature Acceptance criteria more work yet another doing something Storypoints Days in sprint Sioux Technologies

8 We used swimlanes per person on a lineair timeline WEEK 1 WEEK 2 WEEK 3 WEEK 4 Person A yet another feature feature Person B feature Review design feature Person C Delivery from supplier feature Sioux Technologies

9 The project has an iterative approach on the top level Architectural design / Technology demonstrators FUMO s of critical technical concepts Demonstrate technical feasibility of key concepts Product demonstrator Alpha machine First prototype of complete machine Prove machine concept Fix showstoppers on the spot Product demonstrator Beta machines Fully engineered industrial machine Build according to TPD, no tweaking Used by first beta customers Sioux Technologies

10 But one level deeper, every discipline has it s own rhythm Architectural design Alpha machine Beta machines Hardware development has a more classical phasing design construction integration design construction integration design construction integration Software development is done in iterations Sioux Technologies

11 The delta in rhythm / approach requires easy configurability SW must be able to cope with different hardware setups: No hardware present. Hardware partly present. Different hardware present. All hardware present. Sioux Technologies

12 Our configuration mechanism offers great flexibility System and module level software Node config Allocates units to physical nodes unit device stub Unit behavior real device real device SW Config HW Config Which devices are stubbed, simulated or real Calibration values and different physical parameters device simulation HW device Sioux Technologies

13 The clash of the disciplines Hardware follows the V model: decompose and build up from the bottom. Units have capabilities that are all implemented at the same time. Software incrementally builds system behaviour (vertical slices) that uses multiple units, but only a part of a units capabilities. Sioux Technologies

14 Incremental development builds functionality in vertical slices UI layer Feature 1 Feature 2 Behavioural layers Feature 3 Unit 1 Unit 2 Unit 3 Generic SW SW simulation Unit 1 SW simulation Unit 2 SW simulation Unit 3 Sioux Technologies

15 But HW wants complete lower level software for acceptance testing UI layer TestUI Behavioral layers Generic SW Unit1 Unit 2 Unit 3 HW unit 1 Sioux Technologies

16 Prioritisation is a key principle in any Agile approach Cultural difference: SW explicitly wants to prioritise features. In HW it s all or nothing. Cost of rework / adding functionality is very high. Project managers want parallel paths to avoid blocking and reduce technical risk. Sioux Technologies

17 We started with a simple model for version control & status promotion Day 1 Day 2 Day 3 SVN archive \Trunk Daily update Daily update Daily update Commit After unit testing Developer workstation Sioux Technologies

18 The Trunk is tested automatically, red build is fixed with highest prio Continuous incr. build & smoke Nightly clean build & full regression SVN archive \Trunk Day N Daily update Commit After unit testing Developer workstation Sioux Technologies

19 At the end of the sprint the archive is frozen SPRINT Release SVN archive \Trunk testing Daily update Commit After unit testing Developer workstation CODE FREEZE Sioux Technologies

20 Every discipline has it s own rithme untill the integration In integration phase the disciplines (M, E, S) become truly inter dependant. Planned feature development interferes with integration activities. Machine time becomes a bottleneck and determines the daily activities. A working machine becomes more important than solving a red build. Integration phase is unpredictable. Sioux Technologies

21 In an integration phase the sprint model doesn t work Integration phase is unpredictable, but Scrum assumes scope changes only occur between sprints Daily priority setting with other disciplines Scrum of scrums How can we deliver important stuff fast without burden of other unfinished, planned stuff. Sioux Technologies

22 We needed feature branching for continuous delivery SVN archive \Trunk Commit policy: tested on Lunaris Daily updates SVN archive \Branch\feature Commit policy: Unit tested on WS Developer workstation Sioux Technologies

23 We changed to a standard board and added waiting for FEATURES feature Acceptance criteria TODO more work improvement from retrospective yet another WAITING FOR Task that s waiting for machine time TODAY today s FINISHED finished finished another feature yet another Task that s waiting for other discipline Fix broken nightly Acceptance criteria more work doing something Sioux Technologies

24 We adapted the typical Scrum approach for our needs During development phase: Generalising specialists Task board with swim lanes and time axis During integration phase: Scrum of scrums Task board with waiting for column Continuous delivery instead of fixed sprints Sioux Technologies

25 Agile is just a means to an end Sprints are not important Sioux Technologies

26 Our goal is a good print prints are Sioux Technologies

27 jmawijnands Sioux Technologies