1.
print("hello pycon") .

2.
velocity

3.
speed.

4.
speed.
too.
:)

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.
agility

7.
ideal.

8.
reality.

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.
python

11.
python [pahy-thon]
a family of nonvenomous snakes.
Source: https://en.wikipedia.org/wiki/Python

12.
velocity. agility. python.
PyCon APAC 2017

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.
SIAN LERK LAU
linkedin.com/in/sianlerk
@kiawin

15.
Speaker Notes
This is me
For this session, we will do the following
- Agile methods
- What’s next
- Reflection - Velocity and Agility

16.
a quick survey.

17.
software delivery?

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.
agile?

20.
Speaker Notes
agile?
How many of you practices agile?
Would you think agile is the way forward?

21.
CI/CD?

22.
Speaker Notes
CI/CD?
How many of you does continuous integration and/or deployment?

23.
agile methods in essence

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.
processes |
best practices
i

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.
coordination |
communication
ii

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.
learning |
experimentation
iii

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.
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.
continuous *
business strategy and planning
development
operations
support

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.
“… 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.
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.
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.
continuous *
win the war, not the battles

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.
continuous *
the importance of culture and context

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.
“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.
“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.
continuous *
misplaced focus on speed
rather than continuity

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.
“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.
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.
continuous *
the need of discontinuous
software engineering

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.
reflection in velocity

50.
lead time.

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.
stability.

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.
“… 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.
“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.
reflection in agility

57.
process.

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.
“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.
design.

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.
“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.
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.
coordination.

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.
collaboration.

67.
Speaker Notes
It is collaboration that we need to work on. A breakthrough is needed

68.
mentorship.

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.
“Train people well enough so
they can leave, treat them well
enough so they don’t want to.
Richard Branson

71.
@kiawin

72.
print("thank you") .