The Blank Stares of a Product Owner: or How I Learned to Stop Worrying and Love Drupal in an Agile Environment

Speakers: 

Question: How well can Drupal be leveraged in an Agile development environment?

Answer: Very well!

In a traditional agile environment, content creators are taught, from an Agile best practices perspective, to make the content creation tasks a part of the main story so that the story is really "done done" instead of mostly done. If the content creation work is independent enough you can make a separate story. If it's big and needs to be done before the story is really ready for prime time you can make it a sibling story so that the epic (parent story) cannot be accepted until all the key items are complete. Content creators are also taught, as much as possible, to make their work, tasks for the story. It can also help to attach a document directly to the task or link to a google site, so you have a single source of record for the delivery team to use.

More and more development teams are moving towards a more extreme side of Agile involving what's called "continuous flow".

The engineering team that I work with is one of those "more aggressive" teams and has a "multiple times a week" release cadence. This has led our Drupal content creation team to adopt a more "continuous flow" style of kanban delivery. Meaning that when a piece of content or a new Drupal system feature is complete, we want to deliver it to the customer the second it's ready. To accommodate for this need, we use Drupal because it allows for instant end-user delivery. This allows us to keep our instance of Drupal completely outside of the engineering product. Because our CMS (Drupal) is in it's own completely independent environment, we can push out a new build to the customer at any time without the need to push a new build of our parent product. This is a technique that will need to be adopted more and more as teams become "agile mature".

Our content creation team does all of its writing collaboration in Drupal. Once a topic is complete, it is then switched to “published” and a new version of the help site is pushed out to customers. We also have a "versioning" module installed in Drupal that allows us to create future topics (and sections of existing topics) without exposing them to customers before they are ready. It also allows us to schedule a date and time in the future for content to be published automatically. Text is written directly in Drupal, or if preferred, crafted in Dreamweaver (or some other html authoring tool) and then copied over.

Don't underestimate how important, effective, well-written support documentation can be and how difficult it can be to deliver the information in time.

Come to this session to learn about techniques to improve one of the most overlooked and challenging aspects of becoming agile mature.

Information for Review Team:
I plan on using real world examples and data to show the benefits of kanban and "just in time" delivery of end user documentation for continuous flow engineering teams. I also plan on showing a live delivery of end user content during the talk.

Prerequisite Knowledge:
A basic understanding of kanban is helpful but not necessary.

Learning Outcomes:
- Plan a path towards continuos flow documentation for end users.
- Track progress of cycle time to more accurately predict time to delivery.
- Techniques for working with teams delivering customer features multiple times a week/day.
- When a new capability is released to customers, having access to supporting documentation and training always makes it a better user experience - this talk will help ensure that is always the case.

Schedule info
Track: 
Experience level: 
Intermediate
Drupal Version: 
Drupal 7.x