Being Agile – A Practical Example

Bob Morris is a Project Manager and a Principle Scrum Master at ThreeWill. He has over 20 years of experience with successfully leading technology projects and teams in both project management and senior technical management positions. This experience includes delivery of software product development, enterprise software deployment and I/T infrastructure projects.

Agile Is Old Enough to Go to College

Do you think “Agile” is an “old” concept for technology projects? I was watching a recent agile conference presentation and heard someone say, “Agile is old enough to go to college” and I had to do a double take…but he was right, if you define the start of “Agile” as the 2001 creation of the Agile Manifesto then it is nearly 18 years old! There is also a groundswell of popular opinion that Agile is getting not just “old” but also “over-decorated” or “overdone”. Some think that Agile has been ruined by project management miscreants that have brought an abundance of process frameworks, tools, and metrics to this field. In fact, 2017 saw the publishing of the first edition of the “Agile Practice Guide” based on a joint effort by the Agile Alliance and (gasp!) the Project Management Institute. Now, even the venerable PMI PMBOK (Project Management Body of Knowledge) is bundled with an Agile Practice Guide. Say it ain’t so!

However, before lamenting the ruination of Agile, let’s consider a broader perspective. Is all of this hubbub more about “doing Agile” than “being Agile”? Dr. Ahmed Sidky, a well-known thought-leader in the Agile community, has described the idea of “being Agile” vs. “doing Agile” as indicated in the figure below. At its core, Agile is about a growth mindset (a more general term originally coined by Dr. Carol S. Dweck) that is based on the concept that improvement is a continual, ever-changing and ongoing process of growth based on fundamental values and principles. For “Agile”, these values and principles include concepts like “welcome change”, “fail early”, “build feedback loops”, “continuous delivery”, “value-driven development”, “learning and experimentation”, “transparency”, “respect and collaboration”, “maximize outcomes and minimize outputs”, and “continuous improvement”. According to Dr. Sidky, “being Agile” embodies the original vision of Agile and means internalizing an Agile mindset and leveraging Agile values & principles to continually develop and apply practices for maximum value. “Doing Agile”, on the other hand, is blindly learning/applying frameworks and practices without understanding (or caring) if they are appropriate for the needs of a given project. So, “experienced/effective” Agilests focus on “being Agile” and in the remainder of this blog post, I’d like to describe a practical example of a “being Agile” scenario at ThreeWill.

4 Va lues 12 principies Practiees S a Cuide-a a i ff«eM

Ref – Agile Practice Guide & Dr. Ahmed Sidky

Being Agile at ThreeWill

Coincidentally, ThreeWill was founded in 2001 around the time of development of the Agile Manifesto. We’ve been applying Agile practices to our projects (most commonly using SCRUM) since 2007. Experience has taught the ThreeWill team that effectiveness is most impacted by having an Agile mindset and related values/principles rather than fixating on practices (which could mean following the latest fads in practices or being rigidly fixed to a specific set of practices).

However, we also have to deal with the real-world realities of being a successful consulting business. This means that, ultimately, we do need to articulate a formal set of practices to our customers in order to sell and deliver our services. Despite a current recurring theme in the Agile community about the evils of formal processes & metrics, our clients still demand clear guidance and accountability and still need to be convinced that we can keep our commitments and demonstrate incremental progress towards our ultimate engagement deliverables.

Migration Project – Let’s be Agile!

So, how can we “be Agile” and apply appropriate practices for a particular project? Let me illustrate with an approach we’ve developed for a particular type of project in our migration practice.

One of our typical engagements involves migrating large volumes of highly structured and complex content between different corporate intranet platforms and content management systems (CMS). We’ve developed a set of software utilities to assist with the migration process. However, customers many times have at least some level of unique requirements that require updates and enhancements for these utilities. So, we need to leverage Agile concepts of “learning cycles” to demonstrate and fine-tune the migration approach to ensure stakeholder buy-in. However, we also typically have to contend with an inflexible deadline to migrate a specific volume of content by a specific date. Typically, this is based on a fixed decommissioning date for the source intranet/CMS.

Applying an Agile Mindset

Agilests often employ Agile values and principles using a traditional Japanese model for learning and skills acquisition called “Shu-Ha-Ri”. This model has 3 phases: Shu (obey – following existing rules), Ha (“digress” – deviate from traditional rules), Ri (“separate” – find a new path through practice and improvement). For Agile practices, The Agile Practice Guide describes the “Ha” and ultimately the “Ri” phases as something experienced practitioners can leverage via the concept of “tailoring”. In this context, “tailoring” means changing existing well-known practices or combining practices (both Agile and non-Agile) into an overall “tailored” project approach.

A word of caution. The Agile Practice Guide, as well as many members of the Agile community, have cautioned about the “being Agile” concept and “tailoring” (see Matthew Hodgson’s blog on Agile is a mindset. Agile is a behavior). This is something that should only be considered after establishing a track record of effective use of traditional Agile practices and frameworks lest you attempt to bend the “being Agile” concept to the justification for poor/ineffective practices.

The idea of “tailoring” motived ThreeWill to consider a hybrid approach that would fit the natural characteristics of these projects. This means supporting dynamic requirements, repeated iterations, and customer value via feedback from frequent deliveries for the utility update portion of the project followed by “once and done” deliveries in frequent fixed increments and emphasis on speed of delivery for the migration portion of the project.

A Hybrid Agile/Incremental Approach

So, what does this look like? As indicated in the figure below, this approach relies upon two distinct project phases: 1) Agile Phase using a SCRUM framework followed by 2) an Incremental Phase with “once and done” incremental deliveries of migrated content. The focus of the Agile phase is the enhancement and fine-tuning of migration utilities and stakeholder buy-in for how content is surfaced in the destination intranet/CMS system. Phase 2 is focused on speedy delivery and validation of a fixed number of increments of migrated content designed to conclude prior to source system decommissioning. (The Equip, Inventory, Prepare items in the figure below to represent activities executed in parallel with utility update sprints that support the launch of the “Migrate” portion of the project. The sprint/increment durations mentioned in the figure are from an actual project. However, durations will vary from project to project).

2-Phase Hybrid Project Approach evelop Agile/Scrum) sprinE Sprint Cycles Migr ate (Pilot.fProduction) (Incrementao 161 1 -v.æk & content to during Migration Increment' O ThreeUJill Typæ:

Each phase has different characteristics and practices as summarized in the figure below.

2-Phase Hybrid Project Approach evelop Agile/Scrum) Lttilty Updatg,'Migration Prep Sprint Reviews R&luiran dits'Acceptance Criteria Progressively Elaboratal continuous involvemdlt of key stakeholdeB Change'phortizaton incorporated contnuousb' Deliver frequdtly Migr ate (Pilot.'Production) (Incrementao Pilot'ProcIution Migraton Welty Status Me&ings R&luiranents Periodic invovement of key stakeholdeB Change co nstrainal Deliver in fixed incremdlts O ThreeUJill

Are We Using Agile Values & Principles?

Yes. Even though we are employing a project approach (Incremental) that is not considered a “traditional” Agile approach, we can still use an Agile mindset. In fact, one way of “being Agile” means using an Agile mindset (and related values & principles) to influence traditionally “non-Agile” project approaches (for a good example of this, check out Robert Wood’s “Can a Waterfall project be run with Agility?” blog).

For example, some Agile influences on the Incremental portion of the above hybrid approach include:

  • fail early” – Increments are designed to expose any operational issues after migrating only a small subset of the overall content to be migrated
  • welcome change” – OK, maybe we shouldn’t say this is “welcome change” because we do typically have a fixed deadline. However, increments can be designed with some spare capacity to accommodate unplanned new content that needs to be migrated.
  • frequent delivery” – Increments provide the ability for “finished” chunks of content to be released to the customer on a frequent yet sustainable pace.
  • transparency”, “respect and collaboration” – Daily stand up meetings are conducted in both SCRUM and incremental project phases to promote transparency. Weekly planning meetings promote collaboration between ThreeWill and client Teams to ensure that maximum value is being delivered by the sequencing and priority of content in migration increments.
  • continuous improvement” – Learnings from early increments can (and often do) provide improvements that increase migration velocity in later increments.

Reality Check

As mentioned above, our clients ultimately require accountability on the delivery of features in our migration utilities and migration of actual content. So, we do provide periodic reports covering traditional metrics for cost, scope, and schedule. Cost and schedule metrics are expressed in consistent terms throughout both the Agile and Incremental portions of the project. However, the scope could be measured in multiple ways, including story points, migrated site counts or migrated content counts. We typically employ techniques to equate migrated content counts to story points so that we are able to show a consistent measure of scope completion (e.g., scope burn up, release burndown charts, % completion doughnut charts, etc.) through the full lifecycle of the project.

Before I catch too much heat from blog readers, let me say I’m very aware that the use of story points for representing velocity and scope completion is being challenged in some Agile circles because they were originally invented to be used only as capacity planning tools (See Ron Jeffries “The NoEstimates Movement” article). However, that discussion will need to wait for another blog post!

I always appreciate people taking the time to read my blogs. I hope you found your time investment worthwhile on this one. I’d love to hear from any readers about their “Shu-Ha-Ri” journeys and experiences with “being Agile” in solving real-world problems.

Additional References:

  1. Sidky, Dr. Ahmed. (2015). The secret to achieving sustainable Agility at scale [PowerPoint slides]. Retrieved from
  2. Project Management Institute and Agile Alliance. (2017). Agile Practice Guide. Newtown Square, PA: Project Management Institute, Inc.

Related Posts

Bob MorrisBeing Agile – A Practical Example