Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Velocity. Agility. Python. (Pycon APAC 2017)

311 views

Published on

Speaker Notes Edition.

Often there are conflicts of interest between velocity and agility of a project.

Some see velocity as mere time taken to complete a task, whilst some see agility which requires quick response to change in meeting objectives of a task as a significant contributing factor behind delays.

Being a python developer and an engineering process facilitator, I would like to share my journey in discovering the beauty of velocity and agility of continuous software delivery.

In the end of this talk, I wish to lead all attendees to reflect on the engineering process and organisation culture in their respective workplace, to delivery quality python projects with velocity and agility in mind.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Velocity. Agility. Python. (Pycon APAC 2017)

  1. 1. print("hello pycon") .
  2. 2. velocity
  3. 3. speed.
  4. 4. speed. too. :)
  5. 5. velocity [vuh-los-i-tee] rate of change of its position with respect to time. a specification of its speed and direction of motion. Source: https://en.wikipedia.org/wiki/Velocity
  6. 6. agility
  7. 7. ideal.
  8. 8. reality.
  9. 9. agility [uh-jil-i-tee] the ability to change the direction of the body in an efficient and effective manner which requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength, and endurance. Source: https://en.wikipedia.org/wiki/Agility
  10. 10. python
  11. 11. python [pahy-thon] a family of nonvenomous snakes. Source: https://en.wikipedia.org/wiki/Python
  12. 12. velocity. agility. python. PyCon APAC 2017
  13. 13. Speaker Notes Velocity. Agility. Python. Often there are conflicts of interest between velocity and agility of a project. Some see velocity as mere time taken to complete a task, whilst some see agility which requires quick response to change in meeting objectives of a task as a significant contributing factor behind delays. Being a python developer and an engineering process facilitator, I would like to share my journey in discovering the beauty of velocity and agility of continuous software delivery. In the end of this talk, I wish to lead all attendees to reflect on the engineering process and organisation culture in their respective workplace, to delivery quality python projects with velocity and agility in mind.
  14. 14. SIAN LERK LAU linkedin.com/in/sianlerk @kiawin
  15. 15. Speaker Notes This is me For this session, we will do the following - Agile methods - What’s next - Reflection - Velocity and Agility
  16. 16. a quick survey.
  17. 17. software delivery?
  18. 18. Speaker Notes Software delivery? How many of you involved in the software delivery pipeline? It can be from business, products, all the way to the devs, ops, sec, testers etc.
  19. 19. agile?
  20. 20. Speaker Notes agile? How many of you practices agile? Would you think agile is the way forward?
  21. 21. CI/CD?
  22. 22. Speaker Notes CI/CD? How many of you does continuous integration and/or deployment?
  23. 23. agile methods in essence
  24. 24. Speaker Notes Agile methodologies in essence shares several key characteristics. Yes. This summary may be controversial, but we’ll go in detail later why so.
  25. 25. processes | best practices i
  26. 26. Speaker Notes Processes and best practices This is the part where people uses keywords such as Scrum, Kanban, CI/CD etc. More? unit test, behavioral test, functional tests, deployment pipeline, pair programming, configuration management, etc.
  27. 27. coordination | communication ii
  28. 28. Speaker Notes Coordination and communication We don’t work in silo, and I hope you don’t. Even if you work alone, high chances you are using python libraries, which in returns there will be a certain minimal interaction through online platforms (e.g. stackoverflow, github, etc). We work in team to leverage on collective strengths and collective knowledge sets.
  29. 29. learning | experimentation iii
  30. 30. Speaker Notes It is all about life-long learning. Beyond that, it is also about fail safe, learn fast, and iterate. Experimentation is strongly encouraged, and we should chant by heart :)
  31. 31. emergence of continuous * Fitzgerald, B. and Stol, K.J., 2017. Continuous software engineering: A roadmap and agenda. Journal of Systems and Software, 123, pp.176-189.
  32. 32. continuous * business strategy and planning development operations support
  33. 33. Speaker Notes The continuous* movement took a holistic view on the entire software lifecycle, which includes business strategy and planning, development, and operations. (and support) Fitzgerald, B. and Stol, K.J., 2017. Continuous software engineering: A roadmap and agenda. Journal of Systems and Software, 123, pp.176-189.
  34. 34. “… every company is a technology company, whether they know it or not The DevOps Handbook Kim, G., Debois, P., Willis, J. and Humble, J., 2016. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution.
  35. 35. continuous value delivery Dingsøyr, T. and Lassenius, C., 2016. Emerging themes in agile software development: Introduction to the special section on continuous value delivery. Information and Software Technology, 77, pp.56-60.
  36. 36. Speaker Notes Value, a concept borrowed from lean can be viewed from two aspects, value to customers (and hence, business), and not forgetting value to the people who worked in the company! For example, job satisfaction, motivation, etc.
  37. 37. continuous * win the war, not the battles
  38. 38. Speaker Notes Continuous * Win the war, not the battles “...true continuous software engineering is more than adopting continuous delivery and continuous deployment. These are merely techniques, but the ultimate goal is to take a holistic view of a software production entity, whether this be a single software organization or an ecosystem where different organizations together deliver a final product.” “Rather than focusing on winning these battles (i.e. successfully implementing such techniques), the holistic view that we advocate is that of winning the war; in this case, to focus on pursuing the continuous * agenda and establish a holistic view from customer to delivery.“ Fitzgerald, B. and Stol, K.J., 2017. Continuous software engineering: A roadmap and agenda. Journal of Systems and Software, 123, pp.176-189.
  39. 39. continuous * the importance of culture and context
  40. 40. Speaker Notes Continuous * - the importance of culture and context For culture, “... there may also be a cultural tendency to assume that the status quo is the only possible way. Similar to what could be observed in some lean transformations, a disbelief that “this could work here” may result in considerable resistance to change within organizations. Womack and Jones have argued that a change agent is needed: “a leader—someone who will take personal responsibility for change—is essential” (Womack and Jones, 2003 , p. 313). This cultural change may very well be the most significant barrier to change.” For context, “There are numerous dimensions in which contexts vary, for instance the business domain in which organizations operate. The telecommunication sector is an example that depends on legacy systems that may be much less amenable to a continuous software engineering approach. In such systems, rapid delivery of new functionality is a major challenge, as there may be dozens of different interacting systems that together deliver hundreds of different services to both internal and external customers…. In such domains, technology may also prove to be less suitable for a continuous software engineering approach.“ “Software sourcing; the use of outsourcing of components or the use of commercial off-the-shelf (COTS) components are very common approaches in numerous domains. Such dependency on software components produced elsewhere may introduce additional challenges when aiming for delivering new software releases frequently.“
  41. 41. “Maybe … the problems of systems work are not so much technological as sociological Peopleware: Productive Projects and Teams DeMarco, T. and Lister, T., 1987. Peopleware: productive projects and teams. Addison-Wesley.
  42. 42. “We’re mostly in the human communication business. Peopleware: Productive Projects and Teams DeMarco, T. and Lister, T., 1987. Peopleware: productive projects and teams. Addison-Wesley.
  43. 43. continuous * misplaced focus on speed rather than continuity
  44. 44. Speaker Notes From the entire technology value stream, we can observe that speed is not the only consideration we should focus upon but also the continuity of the features and products we produced. To extend this concept, even the continuity of the business is also a significant focal point in software development.
  45. 45. “A slower but more consistent tortoise causes less waste and is much more desirable than the speedy hare who races ahead and then stops occasionally to doze. Taiichi Ohno
  46. 46. Speaker Notes Taiichi Ohno (1988) once said this, “A slower but more consistent tortoise causes less waste and is much more desirable than the speedy hare who races ahead and then stops occasionally to doze.” He argued that only if all workers become tortoises, and referred here to the term ‘high-performance.’ His point was, “speed is meaningless without continuity.” Likewise for software engineering, we argue that achieving flow and continuity is much more important in first instance than speed. Fitzgerald, B. and Stol, K.J., 2017. Continuous software engineering: A roadmap and agenda. Journal of Systems and Software, 123, pp.176-189.
  47. 47. continuous * the need of discontinuous software engineering
  48. 48. Speaker Notes Continuous * the need of discontinuous software engineering is about the need of rapid change “The point being made is that creativity and innovation require discontinuous thinking—in some cases an abrupt, discontinuous change is needed rather than a gradual change; in lean terms: kaikaku, not kaizen. Undoubtedly, additional value is often delivered through a series of incremental improvements, a path that can be compared to ‘kaizen.’ However, there are cases where this path is no longer sustainable and more significant, abrupt changes are needed, very much comparable to the ‘kaikaku’ phenomenon of radical change. Thus we see that while continuous * is a necessary evolution in the software development field, it is not the only way that progress can be achieved.” Fitzgerald, B. and Stol, K.J., 2017. Continuous software engineering: A roadmap and agenda. Journal of Systems and Software, 123, pp.176-189.
  49. 49. reflection in velocity
  50. 50. lead time.
  51. 51. Speaker Notes Lead time. The structuring of the development based on multiple small phases, with one or more development tickets (with each ticket up to maximum of 3 man days) allowing us to shorten the lead time and time to market. However, looking back the greater emphasis of features development causes reduced focus on tools and instrumentations. It bit us. We played Kanban board game, and tools and infrastructure tickets are joked as intangible tickets. By definition, hard to quantify economic value and hence often ignored. In reality the definition of intangibles, Describes work items whose short-term economic value is hard to quantify but whose presence in the system is vital to its health and performance in the longer term. Often applied to preventive maintenance, experiments, system improvements, and so on. (Source: http://edu.leankanban.com/kanban-glossary-terms)
  52. 52. stability.
  53. 53. Speaker Notes Stability. Half baked CI/CD with little thoughts about minimal risk deployment. We should have considered and implemented release strategies (or change management) that minimizes deployment risks, e.g. Canary release, blue green deployment, feature toggle, etc. Read more at https://martinfowler.com/tags/continuous%20delivery.html
  54. 54. “… roughly 70% of outages are due to changes in a live system. Site Reliability Engineering: How Google Runs Production Systems B. Beyer et al., 2016. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media.
  55. 55. “Quality is free, but only to those who are willing to pay heavily for it. Peopleware: Productive Projects and Teams DeMarco, T. and Lister, T., 1987. Peopleware: productive projects and teams. Addison-Wesley.
  56. 56. reflection in agility
  57. 57. process.
  58. 58. Speaker Notes Processes are the elephant in the room. However, if we use it based on culture and context, it makes lots of sense, and it helped us to be more productive.
  59. 59. “The manager’s function is not to make people work, but to make it possible for people to work. Peopleware: Productive Projects and Teams DeMarco, T. and Lister, T., 1987. Peopleware: productive projects and teams. Addison-Wesley.
  60. 60. design.
  61. 61. Speaker Notes design. Prototyping and technical document not only increase clarity in design, but also planning. This enables us to reduce lead time, avoid major redesign and reimplementation of the feature. Encourage accelerated discovery of major unanticipated issues. Encourage us to fail fast. On the contrary to popular belief, a proper drafted design does not contradict agility of the development. Constant communication with product owner, chief architect and feature owner is vital.
  62. 62. “Rule of thumb in scheduling tasks … ⅓ planning, ⅙ coding, ¼ component test, ¼ system test. The Mythical Man-Month Brooks Jr, F.P., 1975. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
  63. 63. Speaker Notes This is from an old book, dated 1975. However it is something worth to ponder upon. Perhaps not sequential, but the aggregated time spent is actually still pretty valid. Indeed, we spend most of the time on things other than coding.
  64. 64. coordination.
  65. 65. Speaker Notes coordination. It started with coordination. But we noticed it ended up to be task oriented instead of people oriented experience. Ironically, both agile and lean focuses on human instead of process.
  66. 66. collaboration.
  67. 67. Speaker Notes It is collaboration that we need to work on. A breakthrough is needed
  68. 68. mentorship.
  69. 69. Speaker Notes mentorship. One missing element from “collaboration”. Not exactly a “title” kind of mentorship, but it is about the natural choice of response to any question raised. Some guidelines through a discussion from my colleagues on mentorship. - we don't give direct answer - we guide and give tips - always answer "read code" as first response - we acknowledge time is an investment for both mentor and mentee - understanding is a collective responsibility, just mere mentor, or mere mentee.
  70. 70. “Train people well enough so they can leave, treat them well enough so they don’t want to. Richard Branson
  71. 71. @kiawin
  72. 72. print("thank you") .

×