Tear It Down to Build it up

Transcription

1 Tear It Down to Build it up Case study in progress Arjay Hinek Red Hat Global Agile Coach April 5, 2018

2 I need your help INSERT DESIGNATOR, IF NEEDED

3 I need your help INSERT DESIGNATOR, IF NEEDED

4 I need your help INSERT DESIGNATOR, IF NEEDED

5 I need your help INSERT DESIGNATOR, IF NEEDED

6 A tale of two teams

7 What do you do? Run, run away, fast ASk them why they think they want to be Agile Ask them what problem they really want to solve Ask them what their actual product is Ask them who their customer is Start re-orienting the way you are looking at the problem INSERT DESIGNATOR, IF NEEDED

8 What are the problems? symptoms? Communication gaps not being closed Each team starting the project independently We already held the kickoff. We have the funds. Don t you?

9 Projects needed to be started in a way that was conducive to Agile thinking We grabbed a room and here s what happened next while mapping: The teams spotted gaps. The teams spotted dependencies. The teams discovered sequencing issues. We stopped and asked-- So what are we looking at? Created a shared mental model Created Shared Ownership in the project Yaaayyyyyyy. Little Victories

10 OK, You got them started. Now What? Help us do this with every project In every region. In a model that scales INSERT DESIGNATOR, IF NEEDED

11 What Gave us pause? We aren t delivering software Regular and frequent releases needs to be re-framed in a construction model We do not have the luxury of refactoring Different kind of customer-- I need an office. External dependencies slow the tempo on nearly all tasks Our teams are never collocated Our customer need is often based on lease expiration

12 Here s how it unfolded... I had an ambiguous problem to solve I knew Agile Could help, but was not a great fit I knew Mental Modeling would get them on the Same Page I knew Construction daily huddles would fit I knew the answer would have to evolve Therefore, we would need to expand Agile s boundaries to other systems. Which means-john Boyd INSERT DESIGNATOR, IF NEEDED I needed to re-orient

13 Always Be Orienting John Boyd More specifically If we don t communicate with the outside world to gain information for knowledge and understanding we die out to become a non-discerning and uninteresting part of that world. John Boyd INSERT DESIGNATOR, IF NEEDED

14

15 With Agile, it s all or nothing, man! Kevin, a guy I don t like OODA the heck out of things--non-software (and even many software) teams fail because... they fear failure or starting something new they focus on mechanics rather than principles they have been intimidated by a dogmatic approach they treat the principles like an a la carte menu they do not understand what they are modifying they lack discipline INSERT DESIGNATOR, IF NEEDED

16 Start At The Beginning We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: We are continuously improving on ways to deliver completed and integratable project work by doing it and helping others do it. Through this work we value:

17 A Very Good Place To Start Individuals and interactions over processes and tools Individuals and interactions over processes and tools Working software over comprehensive documentation Adaptive, Customer-centric delivery over fixed, chart-centric management Customer collaboration over contract negotiation Responding to change over following a plan Completed and integrated work over comprehensive documentation Decentralized team member planning over centralized planning

18 Finding balance in the whole continuous improvement Self organizing teams deliver what the customer values embrace change Keep it simple deliver value regularly daily comms sustainable pace technical excellence deliver working software provide space for motivated teams face to face

19 Finding balance in the whole continuous improvement Self organizing teams deliver what the customer values embrace change Keep it simple deliver value regularly daily comms sustainable pace technical excellence deliver working software provide space for motivated teams face to face

20 The Principle Differences "identify" : Our customers come to us with a high-level need (I need a floor), and then we have to identify what can fit, and the negotiation begins. Agile Software Principle Pragmatic Delivery Principle Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Our highest priority is to identify and satisfy customer needs through early and regular delivery of completed and integratable work.

21 The Principle Differences Changing requirements are exponentially more expensive in construction, so our focus is on early identification and transparency of impact. Agile Software Principle Pragmatic Delivery Principle Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. We fully acknowledge that change in a project is inevitable; however, we choose to respond to it in a manner that is the least disruptive to the customer and the project.

22 The Principle Differences We have a broader set of diverse skill sets included in every project Agile Software Principle Pragmatic Delivery Principle Business people and developers must Team members, along with Architects, work together daily throughout the Designers, and Stakeholders, must project. work together nearly daily throughout the project.

23 The Principle Differences We felt we needed to be more emphatic about being collaborative because this was such a big divergence from the way things were done before. Agile Software Principle Pragmatic Delivery Principle Build projects around motivated We build projects around motivated individuals. Give them the teams of collaborative individuals. We environment and support they need, give them the environment and and trust them to get the job done. support they need, and trust them to get the job done.

24 The Principle Differences Co-location is a luxury that few can afford. Rather than throwing everything out, we felt the spirit of the message is that we try as much as possible to be face to face. Agile Software Principle Pragmatic Delivery Principle Build projects around motivated Effective communication to and within a individuals. Give them the environment team should be immediate and and support they need, and trust them to conversational to every extent possible; get the job done. where face-to-face conversations are the ideal, depersonalized blanket s should be seen as throwing it over-the-wall behavior.

25 Here are the things we are doing that seem insane from a mechanical point of view We do not estimate story size We do not predict velocity based on historical throughput-sort of We work with an external PMO that insists on using waterfall Stories often have a single owner of all story tasks We do not use burndown charts--yet We are applying Agile principles to work that physically requires linearity Should Agile be an All-or-nothing approach? Kevin? Should it?

26 FREQUENTLY ASKED QUESTIONS--time permitting

27 How do you work without sizing? The teams are very focused on thinking through what they can accomplish by the end of each iteration. It definitely causes stress. They are still figuring out what their version of INVEST is (PLVRSI)

28 How do you predict velocity or provide estimates? Velocity gives us predictability, but if every project is different if projects often use different vendors if team membership often fluctuates (for now) We have a false sense of predictability Instead, we find ourselves determining which components take a set amount of time or have fixed lead times..

29 Could you just have standups? standups certainly help with the rapid turn-around of information, but they do not stand on their own in terms of providing a shared sense of ownership and camaraderie.

30 Can t we just plan like we do in waterfall and use Agile mechanics to be agile? What problem are you trying to solve by doing that? Just going through the motions? Don t. Centralized planning? Iteration planning and ownership breaks down. Anything is better than nothing, but build something that you can sustain.

31 Doesn t individual ownership of stories kind of ruin everything? It does make it harder to keep people engaged with one another, but many pieces of a project puzzle are sequential and, therefore, have built in dependencies. We miss out on team refinement of stories, but we do get good group thinking at the project level.

32 How do you track burndown? One of the hardest things for me to let go. We don t use a burndown-- at least not yet. If we did use a burndown, we would use a story burndown.

33 Are we getting the most out of Agile? It depends on how you define "the most." If you start with nothing, and you are getting something of value...

34 Doesn t this only apply to a very specific type of team? r tome s u c t ur oduc w Yo Kno your pr uccess s w Kno ure your s Mea The practices of these teams only apply to a small subset of industry. The concept of reviewing the manifesto and its principles is wide open to all.

35 Doesn t this only apply to a very specific type of team? I maintain that the following questions are agnostic to any team; therefore, the model will benefit, potentially, all teams: Who is our customer? What is our product? How can these be reflected in a manifesto and a full set of principles wholistically? What problem is this project solving? Can this project be mapped?

36 Fast Forward 1 year Here s what I hope I to be telling you about in a year Upper management and Project Finance fully support the Pragmatic Delivery team model and allow to staff projects accordingly If projects cannot adapt to Pragmatic Delivery, they go Waterfall--i.e., they do not water this model down We have regional teams that never work on more than 2 projects at a time. We have a someone acting as a Pragmatic Delivery Team coach for each region. We have a Global Pragmatic Delivery coach who keeps the practice consistent while ensuring it continuously improves. Members from all teams meet by role to ensure cross-team awareness and consistency in practice (a la the Spotify communications model) Managers have seen enough success that they allow teams to self organize and deliver

37

38 Questions