To be or Not To Be [Agile]?

Transcription

1 To be or Not To Be [Agile]? JULY 2013

2 Alon Linetzki 2 Development, Quality, Testing and product assurance coach and trainer since the last 28 years Vast experience in SW and embedded systems Keen on people, how we think, how well we work, how we can do better Train and coach internationally since 1995 Established the Israeli branch of ISTQB - ITCB (2004), serve as VP and marketing director, lead the ISTQB Partner Program w/w Established the SIGiST Israel Israeli Testing Forum (2000) Certified Scrum Master, Lead Quality Assessor (ISO), Assessor TMMi (CMMi), Certified System Analyst, Certified ISTQB Advanced

3 Best Car-Rental service in Norway 3

4 Best made statement bug in the world 4

5 The Discussion of Today 5 Challenges of the Agile Manifesto Cultural Change What to do next? Agile readiness & evaluation assessment model Reflection Questions

6 Challenges the Agile Manifesto can bring Agile values Individuals and Interactions over Processes and Tools Lack of detailed process + distributed teams challenge Team is spread over multiple locations, different time zones Unavailability for frequent interactions Consequences: limits the ability of Agile to provide high value, high quality software

7 Challenges the Agile Manifesto can bring Agile values working software over comprehensive documentation High level of communication and interaction is required Lack of documentation when team not stable High attrition knowledge is leaving the team Consequences: knowledge churn (key members) complete devastation of team knowledgebase and continuity of development

8 Challenges the Agile Manifesto can bring Agile values customer collaboration over contract negotiations Availability of customer is critical Customer guides by receiving feedback constantly Customer is required to lead the team in working on items with highest value to it s business Development manager crowned as PO Consequences: Customer availability is low or infrequent confusion within the team, leadership and prioritization mess

9 Challenges the Agile Manifesto can bring Agile values responding to change over following a plan Money from documented change requests and plan deviations Requirements rise (a lot) towards the end of the project, when customer sees the software almost ready Embracing change let [mature] customers get what they want Consequences: Customer flexibility project might be loosing it s way (you need a matured customer who understands the benefits and constraints in agile)

10 Summary so far Do not get me wrong - There is value on the rightside, but Agile prefers things on the left-side Agile implementation, should be considered carefully, evaluating: The team/organization state of mind, The maturity [of organization] to make the change, The solution and technology aspects Discussing and observing the organization culture, and if that culture can change

11 11 Agile is a cultural change Scrum [implementation] is much more about changing the way we think than it is a process Tobias Mayer

12 12 Agile is a cultural change Many companies have a Control culture while agile is all about Collaboration and Cultivation and to a lesser extent about Competence People implementing Agile, have to feel in-peace with it s culture requirements Fixation of the team on different cultures than Collaboration and Cultivation, will lead [eventually] into conflicts

13 13 Agile Assessment What to do next? Assessment Influence factors Assessment in practice

14 What to do next? Getting into Agile, requires assessment and evaluation of our ability to become agile (as an organization) Evaluate: Management influence Stakeholder influence Project team influence Technology influence Solution [nature] influence Suggested by: Peter Eeles, IBM, October 2012

15 Agile influence assessment 15 The model hereafter, was suggested by Peter Eeles, from IBM, on October I am enhancing it with more questions on each topic to become less subjective model for preparation and readiness assessment Final model version can be obtained in the future send me your /contact to alonl@sigist.org.il Thank you! July 2011

16 Agile influence assessment Assessment sheet data collection

17 Agile influence assessment Assessment sheet data collection

18 Agile influence assessment Example: SW Product development company named: We-Like- Stand-Up-meetings Manager Bob No-Chance Development Manager Charlie Big-Noise QA manager Dorothy WAD Product Virtual Markers + Board, WiFi, tablets/mobiles/laptops, Sketch board, painting tools, ready-made sketches, sharing, company pool

19 Agile influence assessment Management influence Business Flexibility Management are willing to accept that business parameters, such as cost, schedule and intermediate milestones, are flexible Empowered Teams Management is willing to allow the team (including the product owner) to make key project decisions

20 Agile influence assessment Management influence Quality Quality Scope Scope Time Budget Time Budget So Far In Agile

21 Agile influence assessment Our Story Management influence Business Flexibility Bob No-Chance: No way we can flex the dates here Empowered Teams Charlie Big-Noise: I am the one who makes decisions!

22 Agile influence assessment Stakeholder Influences Acceptance of Agile Stakeholders understand and accept agile practices and the consequences of following these Number of Stakeholders The number and diversity of stakeholder relationships to be managed - is limited Stakeholder Responsiveness The business representative, end users and testers are committed to spending a good deal of time working with the team in an iterative fashion

23 Agile influence assessment Our Story Stakeholder Influences Acceptance of Agile Number of Stakeholders Stakeholder Responsiveness I like iterations. It makes others see less of my mistakes If it means more free time, count me in!

24 Agile influence assessment Project Team Influences Team skills Individuals on the team are team players, good communicators and are familiar with agile practices Embracing Change Team members expect and embrace frequent changes and iterative refinement of the solution Co-located Teams The project team will be co-located

25 Agile influence assessment Project Team Influences - continue Team Stability Individuals will be assigned to the team for the duration of the project Team Roles Team members are able (and willing) to take on multiple roles during the project and to take on new roles if/when needed Agile Disciplines Team members have proven ability in performing disciplines that are critical for agile development with short iterations (design, testing and configuration management)

26 Agile influence assessment Our Story Project Team Influences Team skills Embracing Change Co-located Teams Team Stability Team Roles Agile Discipline I have worked in short iterations all my life, switching 5 jobs a year I have been to the Agile course, and am telling you: we have to communicate! We should welcome Change. I know him, he is nice...

27 Agile influence assessment Technology Influences Development Environment The development environment (methodology, tools, training) will support an agile way of working - such as automated regression test, continuous integration and realtime dashboards - and is sufficiently mature Execution Environment The execution environment can support regular and frequent releases

28 Agile influence assessment Our Story Technology Influences Development Environment Execution Environment Of course: automated regression? No problemo!

29 Agile influence assessment Solution Influences Requirements Churn There is a strong likelihood that there will be significant changes to requirements (and the solution) during the project Solution Complexity The required solution is relatively-complex (e.g. requires the use of unfamiliar technologies) and/or there are many different solution options possible Time-to-market The deadline (time) is the most important factor for the solution while the scope of the solution is flexible

30 Agile influence assessment Solution Influences - continue Dependencies There are no (or only a few) dependencies on internal or external suppliers Release Frequency The solution can be subdivided in viable and meaningful business releases that can be delivered within a few months Demonstrability The solution can be easily demonstrated on an incremental basis (through a user interface, for example)

31 Agile influence assessment Our Story Solution Influences Requirements Churn Solution Complexity Time-to-market Dependencies Release Frequency Demonstrability Solution is complex, and TTM is very important but requirements change all the time we should accept that We can divide the product into small parts, and ship every 12 weeks in that case, we can demo the parts easily!

32 32 Agile Influence Assessment Assessment Data Collection Sheet Assessment Radar Graph

33 Agile influence assessment Assessment sheet data collection

34 Agile influence assessment

35 Reflection 35 We are required to assess: Are we ready to start implement Agile? Which considerations and efforts do we have to invest in order to be ready? We should be willing to invest, in order to be ready! Know, Acknowledge and Act upon the Agile implementation consequences. Iterate on readiness (re-assess) when preparations are Done, after a few moths implementation, after 1 year learn and improve

36 Questions? 36 Never Ever Give Up!!!

37 To be or Not To Be [Agile]? JULY 2013

38 38 References o_be_or_not_to_be_agile21?lang=en July 2011