The Agile Executive

Making Agile Work

Posts Tagged ‘Empirical Approach

Toward An Event Driven Scrum Process

with 10 comments

Recent posts in this blog and elsewhere recommended using technical debt (TD) criteria as an integral part of the build process. One could fail the build under conditions such as:

  • TD(current build) > TD(previous build)
  • TD per line of code > $1
  • TD as % of cost  > 50%
  • Many others…

If you follow this recommendation while integrating continuously, chances are some fixing might need to be done multiple times a day. This being the case, the relationship between the daily stand-up meeting and the build fail event needs to be examined. If the team anyway re-groups whenever the build fails, what is the value add of the daily stand-up meeting?

Figure 1 below, taken from Agile Software Development with Scrum, examines the feedback loop of Scrum from a process control perspective. It shows the daily stand-up meeting providing the process control function.

Figure 1: Process Control View of Scrum

Figure 2 below shows the feedback loop being driven by the build process instead of by the daily stand-up meeting. From a process control standpoint it is essentially identical to Figure 1. Control through the regularly scheduled daily stand-up meeting has simply been replaced by event-driven control. The team re-groups whenever the build fails.

Figure 2: Build Driven Process Control

Some groups, e.g. the Scrum/Kanban teams under Erik Huddleston and Stephen Chin at Inovis have been practicing Event Driven Scrum for some time now. A lot more data is needed in order to validate the premise that Event Driven Scrum is indeed an improvement over vanilla Scrum. Until the necessary data is collected and examined, two intuitive observations are worth mentioning:

  1. Event Driven Scrum preserves the nature of Scrum as an empirical process.
  2. A control unit that is triggered by events (build fail) is in the very spirit of adaptive Agile methods.
Advertisements

Definition: Agile Development

with 2 comments

The difficulty to concisely define the term Agile Development stems from the very nature of the Agile Manifesto:

  • The manifesto is a statement of values. By the very nature of values, people share them in a loose manner. Both definition and adherence (“But do they really practice Agile development?”) are qualitative and open to interpretation.
  • The manifesto values are relative. The manifesto is quite explicit in stating “… while there is value in the items on the right, we value the items on the left more:”

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiations

Responding to change over following a plan

Agile development is often described in terms of the software method in use. For example, in his foreword to Agile Software Development with Scrum, Bob Martin summarizes Agile methods as “… people oriented software processes that work without getting in the way,” Martin Fowler emphasizes another aspect of Agile methods in his own foreword to the very same book:

… a new breed of software processes which are based on an empirical approach to controlling a project.

A more detailed definition is given by authors Rico, Sayani and Sone in their October 2009 book The Business Value of Agile Software Methods: Maximizing ROI with Just-in-time Processes and Documentation:

Agile methods are contemporary approaches for creating new software based on customer collaboration, teamwork, iterative development, and response to change. Combining communication and interpersonal trust with a flexible management and development framework, they contain just enough process to capture customer needs in the form of user stories and to rapidly create working software. However, the key to Agile methods are rich, high-context communications with customers along with cohesive teamwork.

On the other hand, such an authority (and signatory to the Manifesto) as Jim Highsmith does not seem to define the term Agile Development per se in the second edition of Agile Project Management: Creating Innovative Products. Instead, Jim defines Agility through two statements:

Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.

Agility is the ability to balance flexibility and stability.

Likewise, in Agile Software Development, Alistair Cockburn focuses on discussing what is core to Agile, emphasizing the properties of Agility through the following citation:

Agility is dynamic, context specific, aggressively change-embracing and growth-oriented. It is not about improving efficiency, cutting costs or battening down the business hatches to ride out fearsome competitive ‘storms.’ It is about succeeding and about winning: about succeeding in emerging competitive arenas, and about winning profits, market share and customers in the very center of the competitive storms many companies now fear.

Rather than trying to reconcile all these worthy definitions, I would suggest five context-dependent approaches to the definition, as follows:

  • For the reader who tries to understand what Agile is all about: It is the mindset that really matters. Read the Agile Manifesto and the corresponding History.
  • For the reader who is anxious to put his/her hands around an Agile implementation: Pick a specific Agile method – any method – and study it with special emphasis on the roles, process and artifacts of the method. It could be Crystal, Extreme Programming (XP), Scrum, Dynamic Systems Development Method (DSDM), Kanban or any other method that shows promise as a good fit  for your specific environment. Consult 10 Steps for Starting an Agile Start-up for a down-to-earth blueprint for implementation.
  • For the reader who tries to assess whether a project team is really Agile: It is a maturity curve issue that manifests itself in quite a few disciplines. For example, see the various kinds of maturity models surveyed in the BSM Review blog. You will probably need to determine the maturity model that suits your environment and apply it to the method you are practicing.
  • For the reader who needs to explore Agile in a business context: You need not worry about the technical aspects of Agile. See the category Benefits of Agile in this blog.
  • For the reader interested in applying Agile beyond development: Extending Agile changes its definition. See the various posts on the subject by Eric Ries in Lessons Learned.

Please remember: when it comes to defining Agile Development, you have a problem of choosing, not of choice. It is the use to which you put the definition that determines the choosing.