8
Copyright © 2009 Russell Pannone [email protected]. All rights reserved. 1 The Truth about Practices and “Being” Agile & Lean Vince Lombardi, one of, if not the greatest coach in football history, once said, “Practice does not make perfect. Only perfect practice makes perfect”. A misnomer is labeling a practice a “best” practice"; a practice is only best in the specific context in which it exists. My working definition of “practiceis: A practice is a common and adaptive approach for doing something with a specific purpose in mind. When we apply a practice we are focused on end and value-added not the means. Figure 1.0 depicts candidate practices applicable to “being” agile. Figure 1.0 - Candidate Practices When a team is “being” agile, one of the things they will do is self-organize & self-direct around practices; selecting one or more practice to apply to an iteration/sprint. The benefits of which are: Iterative & incremental adoption of “being” agile Gives team a context and narrow focus to rally around Provides a non-threatening easy way for team to learn together, “be” agile, apply an iterative and incremental approach, and get better at what they we do

The Truth About Practices And Being Agile

Embed Size (px)

DESCRIPTION

Vince Lombardi, one of, if not the greatest coach in football history, once said, “Practice does not make perfect. Only perfect practice makes perfect”. A misnomer is labeling a practice a “best” practice"; a practice is only best in the specific context in which it exists. My working definition of “practice” is: A practice is a common and adaptive approach for doing something with a specific purpose in mind. When we apply a practice we are focused on end and value-added not the means.

Citation preview

Page 1: The Truth About Practices And Being Agile

Copyright © 2009 Russell Pannone – [email protected]. All rights reserved.

1

The Truth about Practices and “Being” Agile & Lean

Vince Lombardi, one of, if not the greatest coach in football history, once said, “Practice does

not make perfect. Only perfect practice makes perfect”.

A misnomer is labeling a practice a “best” practice"; a practice is only best in the specific context

in which it exists.

My working definition of “practice” is: A practice is a common and adaptive approach for doing

something with a specific purpose in mind. When we apply a practice we are focused on end and

value-added not the means.

Figure 1.0 depicts candidate practices applicable to “being” agile.

Figure 1.0 - Candidate Practices

When a team is “being” agile, one of the things they will do is self-organize & self-direct around

practices; selecting one or more practice to apply to an iteration/sprint.

The benefits of which are:

Iterative & incremental adoption of “being” agile

Gives team a context and narrow focus to rally around

Provides a non-threatening easy way for team to learn together, “be” agile, apply an

iterative and incremental approach, and get better at what they we do

Page 2: The Truth About Practices And Being Agile

Copyright © 2009 Russell Pannone – [email protected]. All rights reserved.

2

So, let’s take a closer look at two of these practices.

Practice - Mastering the Iteration Figure 2.0, Figure 3.0 and Figure 4.0 depict an iterative and incremental cycle.

Figure 2.0 – William Deming’s Plan, Do, Check/Study, Act –

Quality Improvement Cycle

Figure 3.0

Page 3: The Truth About Practices And Being Agile

Copyright © 2009 Russell Pannone – [email protected]. All rights reserved.

3

Figure 4.0 – Scrum Framework

In all actuality William Deming’s quality improvement cycle of Plan, Do, Check/Study, Act is

embodied in Scrum.

When “being” agile, we work in sprints/iterations developing and delivering commercial or

operational value incrementally. Iterative and incremental is time-specific/activity-based and

product-specific/value-based. The term iteration is time-specific and activity-based while the

term increment is product-specific and value-based.

Being agile and applying iterative and incremental development puts the Product Owner (the

business or customer representative) in the driver’s seat; communicating and collaborating with

the team “what” is to be developed, delivered and deployed, with the Product Backlog serving

as their steering wheel.

This approach also puts the Development Team in the driver’s seat. While the Product Owner is

responsible for “what” is to be developed the development team is self-directing and self-

organizing around “how” to develop the system-software product; with the Iteration/Sprint

Backlog serving as their steering wheel.

Applying an iterative and incremental cycle is all about increasing the feedback loop, reducing

waste, effectively and efficiently responding to change and delivering often, commercial or

operational value.

Page 4: The Truth About Practices And Being Agile

Copyright © 2009 Russell Pannone – [email protected]. All rights reserved.

4

The bottom line: delivering commercial or operational value early and often, giving ourselves

the best opportunity to beat the competition to market, realize revenue and discover insights that

we can use to help us improve.

Practice - Three level planning

Page 5: The Truth About Practices And Being Agile

Copyright © 2009 Russell Pannone – [email protected]. All rights reserved.

5

Page 6: The Truth About Practices And Being Agile

Copyright © 2009 Russell Pannone – [email protected]. All rights reserved.

6

Page 7: The Truth About Practices And Being Agile

Copyright © 2009 Russell Pannone – [email protected]. All rights reserved.

7

Page 8: The Truth About Practices And Being Agile

Copyright © 2009 Russell Pannone – [email protected]. All rights reserved.

8

Bio

Russell Pannone is a systems-software development and delivery practitioner, facilitator, and

coach specializing in collaborative and adaptive product (systems-software) development and

delivery.

Russell’s passion is to help people succeed.

Russell has worked in the systems-software development and delivery industry for over 25 years

in a variety of roles including developer, team leader, object modeler, data modeler, project

manager, scrum master, process engineer, and instructor.

He has led agile/lean product development and delivery projects and worked with clients in a

variety of industries including state and local government, aerospace, mobile banking, insurance,

energy, and telecommunications.

Russell’s mantra is: “Do more listening and less talking while you plan a little, do a little,

check/study value-added and adapt”

Russell can be reached at [email protected]