Content Strategy & Agile

[Rachel Lovinger]

We've started using Agile methodology pretty often. Not just for development of web projects, but for design as well, which causes some interesting challenges. One of them is when to do certain content strategy tasks - like taxonomy development and defining the content model (content types, attributes, relationships, etc.). We can't do these kinds of activities before a certain amount of the design work is locked down, or the model keeps changing. And yet the tech group needs some kind of guidance so they can start setting up the CMS. It's a weird sort of position to be in, having to define the structure of something before you know what it is.

 

Has anyone had experience with this kind of issue? How did you approach it? Has anyone seen any resources out there addressing this kind of challenge?

 

-Rachel

[Alexa D. O'Brien]

We are using the agile process right now to design an enterprise content management platform.  We are facing the very same challenges that you described.  Part of the core cultural issue between the content strategists and the technologists, is a kind of lack of understanding as it relates to UX and content. 

Agile, allows us to get beta versions of the platform, ready for clients, but we find that the lack of a robust enough discovery period with content strategy, leave the process lacking.

--
You received this message because you are subscribed to the Google Groups "Content Strategy" group.
To post to this group, send email to content...@googlegroups.com.
To unsubscribe from this group, send email to contentstrate...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/contentstrategy?hl=en.

--
alexa...@gmail.com
www.alexaobrien.com

[Lisa Moore]

Last year, I was the “embedded” content strategist on a team at a design agency that had been tasked with a fairly sizable website redesign. They’d decided to use agile, and this was my first experience trying to operate as a CS person in this way. I found many of the same problems you and Alexa seem to have run up against, as well.

One challenge was that I should have been brought in at sprint zero but wasn’t for various reasons. So, when I arrived, the IA team had already developed the site map. While I had done a content audit, it was clear the IA team had not spent quality time with the deep-level content as I had. As we’d tackle a section of the site in a sprint, I’d have the chance to validate the current state content against the proposed IA. Invariably, I’d find gaps or redundancies, and we’d have to update the IA accordingly.

Still, agile is all about flexibility (or so it suggests) and so such changes were never viewed as showstoppers, although the process did leave me a bit frustrated at times since I felt that IA and design were leading content decisions and not the other way around. I also found I missed having that “big picture” view I can usually develop on more traditional waterfall projects. With this agile project, I often felt as though my focus was on trimming one blade of grass at a time when I really wanted to get to grips with the great big lawn growing with wild abandon all around me! Call me a completist control-freak, but the phrase “don’t worry, we’ll fix that in sprint 92” just does not reassure me :)

However, all that aside, the team by and large “got” the importance of the content, and wherever possible, real content was used in the wireframes and always in the designs. I also found it valuable to have a voice in the daily scrums – either I or the copywriter would be there to raise content issues, thereby ensuring content always had a seat at the table.

Finally, to answer your question Rachel, no, I don’t know of any resources out there talking specifically about CS and agile. However, I am in the process of writing up my experience as a possible case study for a content conference in a few months and will be happy to share if it doesn’t get me heckled off the stage by agile devotees :)

--Lisa

On 15/02/2011 00:44, "Alexa D. O'Brien" <alexa...@gmail.com> wrote:

[Laura Creekmore]

This is a great discussion and it speaks to my heart -- I'm dealing
with both development styles regularly! I think there are benefits
[and downsides] to agile and to waterfall, and I threw it all into a
blog post:
http://www.lauracreekmore.com/content-strategy-agile-development-friends/

In the end, it comes down to this for me: You have to know the
business goals, whatever kind of development you're using. Even in
agile, you're not working in a vacuum, so you have to be prepared with
the long-term vision to inform content strategy. In addition, agile is
all about iteration, so you should expect that new projects will
require updates to things you recently touched -- that's part of the
game with agile.

Laura

> On 15/02/2011 00:44, "Alexa D. O'Brien" <alexaobr...@gmail.com> wrote:
>
>
>
> > We are using the agile process right now to design an enterprise content
> > management platform.  We are facing the very same challenges that you
> > described.  Part of the core cultural issue between the content strategists
> > and the technologists, is a kind of lack of understanding as it relates to UX
> > and content. 
>
> > Agile, allows us to get beta versions of the platform, ready for clients, but
> > we find that the lack of a robust enough discovery period with content
> > strategy, leave the process lacking.
>

> > On Mon, Feb 14, 2011 at 7:40 PM, Rachel Lovinger <rachel.lovin...@gmail.com>

[Rahel Bailie]

Agile is supposed to have an overall "story" that sits outside the sprints. The understanding is that certain activities require an overall view and get slotted there. The problem is when a team picks and chooses which parts of Agile they want to adopt, and then ignore the parts that they find inconvenient. Some push-back may help, but it's often cultural.

Rahel

--

[Rachel Lovinger]

Some really interesting comments, thanks!

 

Alexa - Sounds like you're running into a lot of the same issues. We're doing some things to try to bridge the gap between tech and CS in our group, but more in the realm of how we talk about CMS concepts, less about Agile methodology at this point.

 

Lisa - I'd love to see that case study when you get it done!

 

Laura - Nice blog post summing up the issues. If I gain any insights on how to make content strategy work better with Agile, I'll write up my observations, too.

Rahel - I'm not an expert in Agile, but I'm sure we're getting different flavors of it on different projects. We generally seem to get some kind of odd mix of agile and waterfall - and I have definitely had this experience that people don't always know which stories should be outside the sprints. But either way, the tech people want to configure the CMS before the designs are ready! And I don't think that's something I can blame on the methodology. Or can I? :)

 

And I understand that the process is supposed to be iterative, but with content models I want there to be some overarching consistant approach. Otherwise you end up with a system that works, but is potentially a nightmare for the content creators because there's no real rhyme or reason to their content creation process.

 

Well, we'll keep working on it, and I'll let you know if we discover anything interesting. Meanwhile, please share links if you see anyone else talking about this!

 

Thanks,

Rachel

[Noz Urbina]

Hello Rachel,

Maybe this is of interest?

I don't know if it's too late but at Congility 2011 AGFA Healthcare will present their case study about applying a content maturity model (for the DITA content standad) in an agile environment. 

http://www.congility.com/index.php/site/program_detail/dita_maturity_model_in_a_scrum_environment/

I can maybe hook you up with one of the speakers on Twitter if you like.

[R. Stephen Gracey]

Rachel, et al--

As usual, I'm the noob in the room, but as it happens, I am now trying to bring my team into an Agile mode for rebuilding our web properties in Drupal, an Exodus from Autonomy/Interwoven TeamSite.

It strikes me that doing content strategy with Agile/Scrum techniques is no different from developing software with Agile/Scrum--as long as the CMS supports iterative, incremental development.

That's where the challenges come in. With Drupal, you can add to, redesign, relabel, revise almost any part of the content system--models, taxonomy, anything--so that it is possible to design and build chunks of content within the overall story, and make even sweeping changes, if necessary, as you learn more about the content. With TeamSite, on the other hand, everything is so over-coded and stable that making any change once you've begun is excruciating.

This seems to me a case of the tool's shaping the process: You can only do agile with a tool that supports agile because in the end, agile never ends, and every sprint opens up all the possibilities again for change.

My thoughts--

Stephen

~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~

> R. Stephen Gracey
> website: http://rsgracey.com/
> blog: http://contentstrategy.rsgracey.com/

[Cleve Gibbon]

Rachel, this is a great topic and one that I've been wrestling with
for nearly 6 years. I'm still wrestling with it.

We deliver CMS-based projects in an agile fashion. When we first
started out, we were already big into agile development, so everything
agile was great, and waterfall was considered old school. We got
swept along by the promises of agile. Then we encountered some of the
challenges you're facing and re-introduced some of the elements of
waterfall development to address them. Sign-off. Upfront design.
Creatives don't (naturally) work to an iterative and incremental
schedule. They pushed back to let us know that "they were done when
they were DONE". On the other hand, developers prefer to work in
chunks. However, the demands from the downstream development team
caused friction upstream and resulted an large amount of re-work. In
agile terms - waste! And agile is all about eliminating waste.

So we went back to the drawing board and embedded the agile
development process within an overall waterfall approach to projects.
We are still trying to figure out where design and content strategy
fit together in this process, but content modelling, informed by the
outputs of content strategy is something that we feel needs to be done
well and upfront. Also, expressing flexible content models that are
designed to cater for new content types and changes in their
relationships, means that the CMS folks don't need to re-implement
stuff everytime there are upstream modifications. There are patterns
for doing this. I see the content model as the 'contract' between CMS
tech team and upstream folks. Add all the other bits and the model
becomes a content architecture.

This is really interesting stuff and I've got a few of case studies
that surface more of the don't than do's. If anyone's interested,
I'll try a get something down.

Let me know.

Cleve

On Feb 15, 10:25 am, Noz Urbina <b.noz.urb...@gmail.com> wrote:
> Hello Rachel,
>
> Maybe this is of interest?
>
> I don't know if it's too late but at Congility 2011 AGFA Healthcare will
> present their case study about applying a content maturity model (for the
> DITA content standad) in an agile environment.
>

> http://www.congility.com/index.php/site/program_detail/dita_maturity_...

>
> I can maybe hook you up with one of the speakers on Twitter if you like.
>

> > On Mon, Feb 14, 2011 at 10:12 PM, Rahel Bailie <rahel.bai...@gmail.com>wrote:
>
> >> Agile is supposed to have an overall "story" that sits outside the
> >> sprints. The understanding is that certain activities require an overall
> >> view and get slotted there. The problem is when a team picks and chooses
> >> which parts of Agile they want to adopt, and then ignore the parts that they
> >> find inconvenient. Some push-back may help, but it's often cultural.
>
> >> Rahel
>
> >>   On Mon, Feb 14, 2011 at 4:40 PM, Rachel Lovinger <

[David Farbey]

I am a technical writer ("and self-styled content-malcontent") in a software company that uses an agile methodology for software development.

In theory, content strategists have much in common with agile developers: both approaches see work as a continuous process of small incremental improvements, not as a "one-big-effort-and-its-finished" activity; both are (or should be) passionate about teamwork and collective responsibility; both are interested in performing a balancing act between the legitimate commercial demands of the business ("we have to release the product on 1st March"!) on one side, and giving genuine decision-making power to the staff who actually do the work on the other; and both try their hardest to meet the needs and expectations of their end-users.

In practice, things can easily get problematic: individuals or organisations sometimes set artificial boundaries to which people can work together; some agile development teams are made up exclusively of software engineers and all other disciplines are excluded; sometimes management imposes completely different timescales on different groups of staff who should be working on a common goal; and very often, the transition from traditional management and development styles to agile ones is poorly handled, poorly explained, and rushed into without preparation.

I look forward to taking this fascinating conversation forward at the Congility conference in London in May (www.congility.com)
 
David

David Farbey - da...@farbey.co.uk
Mobile  07879 005 946
Web site/Blog <http://www.farbey.co.uk>
Twitter <http://twitter.com/dfarb>

[nickyt...@gmail.com]

Loving this thread.

I've been working on Agile teams in various capacities (IA,
copywriter, CS, SEO) for 5 years and have learned a few important
lessons:

1. The CS or designer should be included in the storycarding and
estimation process. They should be responsible for stories just as the
dev team is, as this increases accountability and project transparency
(which is crucial to stakeholders).

2. Ideally, the CS should be involved from the very beginning of the
project. It's rare for this to happen on custom web app projects, as
most stakeholders simply think they or (worse) the dev team can handle
copy or CS, and find out too late that this isn't the case.

3. To Cleve's point, Agile is not so much about "eliminating waste,"
but never creating it. One of the core principles of Agile is to
deliver working software over comprehensive documentation. To that
end, the CS must constantly be working in terms of the smallest
deliverable, shippable units of work. This doesn't negate the need for
an overall strategy, but should encourage you to think small when it
comes to implementation.

Nick Strate
@pray4surfnturf

On Feb 16, 7:09 am, David Farbey <da...@farbey.co.uk> wrote:
> I am a technical writer ("and self-styled content-malcontent") in a software
> company that uses an agile methodology for software development.
>
> In theory, content strategists have much in common with agile developers:
> both approaches see work as a continuous process of small incremental
> improvements, not as a "one-big-effort-and-its-finished" activity; both are
> (or should be) passionate about teamwork and collective responsibility; both
> are interested in performing a balancing act between the legitimate
> commercial demands of the business ("we have to release the product on 1st
> March"!) on one side, and giving genuine decision-making power to the staff
> who actually do the work on the other; and both try their hardest to meet
> the needs and expectations of their end-users.
>
> In practice, things can easily get problematic: individuals or organisations
> sometimes set artificial boundaries to which people can work together; some
> agile development teams are made up exclusively of software engineers and
> all other disciplines are excluded; sometimes management imposes completely
> different timescales on different groups of staff who should be working on a
> common goal; and very often, the transition from traditional management and
> development styles to agile ones is poorly handled, poorly explained, and
> rushed into without preparation.
>
> I look forward to taking this fascinating conversation forward at the
> Congility conference in London in May (www.congility.com)
>
> David
>

[nickyt...@gmail.com]

Oh, and for anyone who hasn't already read it, dig the Agile
Manifesto: http://agilemanifesto.org/

Good stuff.

Nick Strate

On Feb 16, 11:22 am, "nickythebl...@gmail.com"

> ...
>
> read more »

[danbarley]

Rachel, I've had a number of conversations with colleagues about
adopting Agile as an approach but have no direct experience (it's
pretty much culturally anathema to the UK civil service, where Prince2
methodology sometimes seems like a religion). Has anyone written a
good book about Agile? Sorry, I know I'm answering your questions with
another question - not what you were hoping for.
Dan

On Feb 15, 12:40 am, Rachel Lovinger <rachel.lovin...@gmail.com>
wrote:

[Kevin Rapley]

On 16/02/2011 21:55, danbarley wrote:

Has anyone written a
good book about Agile?

I am awaiting a few books on this subject to be published. Authors are busily putting together their thoughts as we speak. Admittedly they all have a UX focus, but I am sure the principles will apply to CS.

Anders Ramsay to publish his book Agile Experience Design later this year on Rosenfeld Media [http://rosenfeldmedia.com/books/agile-experience/]

The UX Book Project — Chapter 16: Agile UX Methods [http://www.theuxbook.net/contents/]

I have just bought, and about to consume “The Art of Agile Development” published by O’Reilly Media which covers all roles in Agile, including those of designers and usability staff, which again I am sure will give a deeper understanding of where CS will fit in to the equation.

--

Kevin Rapley

[Rachel Lovinger]

Some great replies to this thread, and I want to respond more specifically to some of them (and want to follow up with those of you who have mentioned case studies). But the for moment, I will just say that I definitely agree that the content model and taxonomy should both be flexible - but they should have some kind of overarching logic or metaphor that is adhered to. Which means that you have to at least understand the range of types, or the range of facets, that you're going to want to detail out over the course of the sprints.

 

The reason I think that this is a little different from UX (although maybe it's not as different as I think) is that we are making actual recommendations about how the CMS will be set up. The real question is - when we think about the user experience, are we thinking about the experience of the users of the CMS? Or only the end-users of the site? I really want a consistent and logical experience for the content creators as well.

 

Is it possible to define the... not sure what to call it... like some kind of CMS meta-definitions before even starting to define the content types?

 

I look forward to checking out some of these books!

 

-Rachel

--

[Ruth Kaufman]

Disclosure: I'm working with Rachel on the same project.

I want to just add a dimension to this discussion thread about Agile
use cases and diminishing returns.

Say your scrum team is multi-disciplinary, and different people
gravitate to different stories and tasks based on where they can
contribute the most. A principle of agile scrum is that teams are
self-organizing. What will tend to happen is that people will take
tasks that they are specialists in. Designers design, software
engineers develop, database architects do database architecture, etc.
So what happens to the sprint if the team self-organizes? They create
a mini waterfall within the sprint because the developer needs the
designs from the designer, and the designer needs the wires from the
IA and the content from the CS/writer, etc. The person who is likely
to take the trailing tasks in this naturally occurring waterfall is
the most squeezed for time. Either that, or those tasks, whether
finalized design, development, or QA, don't finish in the sprint and
move to the next or future sprint.

One conclusion is that there are too many stories in the sprint. But
if you have fewer stories, then people sit idle, or are not optimally
contributing while other parts of work are in motion. It's a function
of timing. In theory they can move onto the next stories, but that
only works if all team members are at roughly the same level of
contributor -- that there is no hierarchy or that they need no
direction from others to define tasks and begin executing. On a
multi-disciplinary team, and on a large project, that is unlikely to
be the case in reality.

Another conclusion is that the stories are too big, and that if the
stories were smaller then the scrum team could finish them more in
bouts than in a broader stroke of a mini waterfall. But small stories
mean small increments of work, and if 3, 5, or 10 people have to touch
a small story in a 2 week time period, that adds up to a lot of person
hours. Each touch involves, well, a touch -- time spent in discussion.

My observation, therefore, is that there are diminishing returns in
Agile with multi-disciplinary teams and with large projects. I think
the process works better when it is black-boxed within an overall
quasi-waterfall. This doesn't mean that there isn't collaboration
across teams or that there has to be "extensive" documentation.
Liaisons from each discipline team can help bridge the documentation
gap. Feature sets can be developed in parallel if there is an overall
release plan and product roadmap -- i.e., you don't have to finish ALL
design before starting and development.

So I think issues arise with a "pure" Agile process under the
following circumstances:

1. The project scope is large "horizontally" -- a significant
technology undertaking like the implementation of a new platform
2. The project is large in scope "vertically -- it requires new
technology and new design to launch simultaneously. In both 1 and 2,
the "minimum marketable product" is a new thing, not an iteration or
augmentation of an existing thing.
3. The project requires multiple disciplines -- there are few "anyone"
tasks, and each person can only be productive part of the time, but is
needed to consult on almost everything.
4. There are many external forces -- executive expectations,
dependencies on other teams

In the end, under these conditions, independently or cumulatively,
Agile sort of becomes a framework for collaboration across teams. It
also can provide useful change management methods, requirements
definition approach, and business process controls. But it's not
really Agile as Agile was intended. It's really just smart planning
and dexterous project management.

With all that said, I'm a fan of Agile for true incremental
improvement on an existing product. In this case, there are standards
and frameworks already in place.

Maybe I should have just written a blog post instead. I may copy this
into one, probably with some editing/updates. If I do, I'll distribute
the link.

Cheers,
Ruth

On Wed, Feb 16, 2011 at 5:13 PM, Kevin Rapley <ke...@digikev.co.uk> wrote:

[Cleve]

Rachel you bring up a very interesting point regarding user experience.  We've found that we need to surface the two different perspectives on UX.  Our clients equate UX with customer experience (CX) and the creatives will build out scenarios for how visitors will navigate the site.  However, author experience (AX) is the other side of the same content coin that needs just as much attention as CX.  So we need to cater for both types of UX in the content architectures/solutions we deliver. The main driver for this is that we are not really being asked to deliver a content managed site (what they ask for), but a publishing platform (what they need). Therefore content creators and all the intermediate roles and activites leading up to content actually going live need to fleshed out.  As you know, this is no easy task.

Agile enables us to flesh out the content architecture early, fail fast in our assumptions by implementing pilots and proof of concepts, and feedback tangible insights back to our authors.   Authors produce content and the CX is validated.  I'm still really weak on the content strategy side and am hoping to get some help from experts in field.  These are definitely is exciting times.  I'm desperately looking for ways to connect with people with similar challenges, exchange ideas and hopefully move things forward.

Sounds like this is the right place :)

--
Cleve

[Clare O'Brien]

Ruth

Thank you for this brilliantly clear summary (far more than a dimension) of
the reality of large multi-disciplinary projects and task teams and Agile.
What you've described raises the difficult but all too common 'it depends'
qualifier. I am not a project or process manager but have requirements,
variously, to have one implemented or contribute to an existing project
implementation plan, and so have no 'expert' position. Therefore my
observations are pragmatic to say the least. If humans were predictable
machine components and all projects followed predictable 'template'
structures then Agile as I understand it has extremely attractive benefits -
and I agree that incremental development is probably where it's best
applied. But in original development practice and when dealing with
multi-disciplines and specifically multiple content types, human objectivity
would seem to get in the way of the Agile approach which seems to be
inherently sensitive to un-planned corrections and so forth. It kind of
reminds me of just-in-time manufacturing techniques, totally reliant on
distant systems and humans working in harmony and which so often resulted
(still results?) in supply gaps and lost sales.

So yes, it really is about smart project planning and management, layering
systems and approaches for different phases and project stages.

Maybe we don't need a book about Agile per se (looks like a few on the
stocks at the moment anyway) but we need a practical guide (inc
case-studies) to efficient integration of different development processes
that address different stages of projects governed by content life-cycles. I
don't know - maybe that's too narrow - but content is such a governing
factor and from what I observe pretty hard to think about in 'absolute'
process terms.

And maybe you could write it - just a thought...

I think this is a really important thread by the way and is giving me loads
to chew on.

Thanks, Clare

Cheers,
Ruth

> The UX Book Project - Chapter 16: Agile UX Methods

[Karen McGrane]

You all might be interested in my session (with Jeff Eaton) at Drupalcon, coming up in Chicago on March 9:

Baby Got Backend: Content Administrators are Users Too

http://chicago2011.drupal.org/sessions/baby-got-backend-content-administrators-are-users-too

I'm excited about this one, because it combines a CMS developer's perspective with my thoughts on editoral workflow and user interface design. 

[Celeste Crocker-Payne]

Hi all,

From the sounds of this discussion I was in the midst of an Agile
project a few months ago (and didn't really realize it). But I was the
lead CS on a big project where we had similar conditions that others
have listed here:

A large CMS platform change/implementation
Site redesign (content/architecture/functionality/visual design)
Tons of multi-disciplinary team members

To deal with the dual need of content definition for CMS development
as well as content definition for UX/IA development, I created a
hybrid deliverable (at least new for me) that was a mix of visual high-
level wireframes and detailed content specifications. This
deliverable, which I referred to as content templates, was created
after the content audit/inventory and the high-level content strategy
was completed.

The document contain two main items:
Content Types (specific elements -- product module, content teasers/
highlights): these were targeted to drive CMS development
Content Templates (made up of specific collections of various content
types): these were targeted to drive front-end UX/Design Development

Unique content types were designed to ensure the new CMS platform
achieved the desired functionality and editorial flexibility. I
visually documented each content type (think rough, rough wireframe)
but also specifying the required element of each content type (i.e.,
Product Image, Product Name, Product Number). I also annotated each of
the visual elements to identify data source and/or data requirements
for each element (i.e. Product Name Source = Product Database)

I generated this collection of content types based on the overall site
content strategy where I had identified specific content needs (based
on user needs) for each category of content.

Once I felt all content types were identified (as could be at each
stage of development), I collaborated with my Interaction Designer, to
assemble my various content types into templates that corresponded to
the unique page types we were developing in the wireframes and visual
designs. The rough content information captured was generally
sufficient to get CMS development moving, catch red flags in-terms of
CMS capabilities etc.

The high-level templates also allowed both the UX team and the visual
design team to better understand the rough information parameters that
had to work within as far as visual design explorations. Again, these
were not refined and finished wireframes but the content templates
served as a starting point for the eventual creation of the full
fleshed out wireframes.

It was time-consuming, and of course due to project timing we did not
get the opportunity to see this process through completely for the
entire site redesign, but it did allow our team to get over the big
CMS development hump without losing UX development time. All in all, I
would attempt this approach again.

This approach was also a nice way to get some consensus from team key
stakeholders (design, UX, content, development) quickly, allowing the
team to identify gaps and risks without requiring tons of rework.

I'd be happy to share a rough example of the document if anyone is
interested.

Celeste

[R. Stephen Gracey]

Oh, man, Celeste--

I hope you put this in a blog post somewhere: I'd hate for it to get lost in the endless river of e-mail...

:-)

Stephen

[Eddie V.]

Celeste, thanks so much for sharing your experience. My team is about
to migrate to the Alfresco ECMS, and I'm working with our interaction
designers to come up with templates for our content types. This gives
me some great ideas.

Eddie

Eddie VanArsdall
Managing Editor/Content Strategist
Ironworks Consulting

[boogabean]

celeste,
I'd love to see an example as my team is in the discovery stages of just such a project and this sounds incredibly helpful.

best,
shannon

**++**++**++**
shannon johnson

[Rachel Lovinger]

Hi Celeste,

 

Yes, this is what I meant by defining the content model, and you've done a great job of breaking down the steps and the deliverables. This is a work intensive task to begin with, and there are additional challenges when your project is following an Agile methodology.

 

I'm not an expert at Agile, so I'm not sure how well I can describe it concisely, but the aspect that's relevant here is that, in Agile, the project is broken down into short Sprints (in the case of the project I'm on now - 2 weeks). At the beginning of a sprint, the team determines what tasks they can accomplish in that time period, and so the work is sort of chunked - "here's all we're going to think about for the next few weeks" - and then when you're done you plan the next sprint.

 

This makes project development more flexible because rather than planning everything out at the beginning and then running into problems later down the line, the team can adjust priorities and needs at the beginning of each sprint period. But, for those of us who are doing work (like content modeling and taxonomy development) that has an impact across the entire set of pages and functionality, it can be difficult. I want to be able to take into account the whole landscape, so that I can design a content model that's consistent and logical, but it's hard to foresee what needs will come up in future sprints.

-Rachel

[R. Stephen Gracey]

Rachel:

But "taking into account the whole landscape" doesn't require seeing it in precise detail. That's the difference with Agile. At any point, the team roughs out as much of the landscape it needs in order to focus on the current, most important pieces of work that are "getting done." You just don't try to "lock down" the details of any particular piece (taxonomy branch, content models) until you get to it because learning is taking place over the course of the whole project.

Now, as I said, I'm just starting to learn about this process myself, but I can easily imagine that all the same work needs to be done. There's just a knack to keeping the "big picture" in mind as the details are worked out iteratively and incrementally.

I could be completely wrong, but as I suggested in my blog post about it, becoming "agile" is more about changing one's own mental models about how the creative and crafting work is done. There are still IT folk who can't imagine how Agile could possibly work for coding a huge project, yet agilists have been doing it successfully for 15 years. Conventional wisdom about doing work runs deep, and Agile or any new paradigm forces us to dig up the roots of conventional wisdom, which as human beings, we hate. That's why we rely on conventional wisdom in the first place.

As I'm writing now, I'm coming to this conclusion: Thinking that the waterfall is necessary for software/websites is the result of applying an inappropriate metaphor. How we build complex *virtual* systems was inherited from engineers who build complex *physical* systems. When you build a skyscraper or a bridge, for example, you have to engineer the whole thing up front because once you pour concrete and weld steel, you can't take it back. And then there are the pesky physics of the situation, like gravity and stress. So when engineers turned their attention to *virtual* systems, they thought, "Well, it's the same process, isn't it? Design it before you start, then turn the blueprints over, and manage the construction."

But virtual system resemble living things more than skyscrapers or bridges. They can grow, rather than being "constructed," and because there is almost nothing "physical" about the systems, they can always be shifted, at least a little. Agile treats the system as a living organism, more like a community. Yes, you strategize about what you want to have in the future, but you allow the details to emerge as it grows.

Agile requires a vision and a long-range plan, but premature detail makes it fall apart. Besides, "it's hard to foresee what needs will come up in future sprints" is true, no matter which approach you use. We cannot know the future. If we try to lock down the future, it will just be "wrong" rather than "unknown."

Stephen

[Sophie Dennis]

Adaptive Path have just published an interesting interview on Agile
and UX design, 'The Awesomeness Factor: Cameron Gray on Agile and UX',
with links through to several other useful sounding articles and
interviews which I thought had some interesting insights in the
context of this discussion. It is more concerned with where design
fits in, but I feel the challenges of fitting design - with its
traditional Design Up Front approach - into agile are similar to those
for wider content strategy and UX work.

http://www.adaptivepath.com/blog/2011/02/18/the-awesomeness-factor-cameron-gray-on-agile-and-ux/

[Ruth Kaufman]

This article inspired a few thoughts for me -- some of which have been
rolling around in the back of my mind for weeks. I'll try to
articulate them.

It seems that different tenets of Agile resonate with different
people, and this is one avenue by which Agile can work well or be
cumbersome for different parts of a team. In my experience, there is
tension between the identification of story and task priorities and
the notion of self-managing teams.

In my mind, the priority dictates what is most important to finish at
the *end* of the sprint, regardless of when within the span of the
sprint the work on it occurs. To someone else, the priority dictates
the order in which work/tasks occur, thus becoming the de facto
workflow. This is an issue I'm running into with my current project.

I will continue to lobby for true self-management because this, in my
opinion, will yield a higher quality product than the notion of
priority=sequence.

This article also gave me the idea of creating a scoring system for
our product owners to use during sprint review -- something like:
- Not good enough
- Good enough
- Very good

My gut says 3 scores is appropriate to keep us moving through sprint
review and sprint to sprint without unnecessary debate overhead.
Nuanced opinions only matter so much when at the end of the day, the
decision is binary -- it either will or will not launch. We can save
nuanced opinions for the next round of design.

The part I like about Agile for creative and UX isn't so much the
structure it provides for our work, but that it legitimizes working
alongside development teams and beginning development far earlier in
the process. I like being able to prototype on the actual system (as
opposed to a mock-up) and that I have so many technical resources on
hand to discuss solution ideas with. This didn't happen as well with
waterfall projects.

Another benefit is the idea of sprints. I've worked in the past with 4
week sprints, and now I'm working with 2 week sprints. I venture to
say that 3 weeks is probably better than either 2 or 4. Two feels
arbitrarily rushed, while 4 feels like it offers too much room to
negotiate and refactor designs within the span of the sprint. I think
the team likes the feeling of moving quickly, not dwelling too long on
design concepts, as well as the quick turnaround of feedback from
senior team members and product owners.

With that said, Agile is bringing me, in my role as a team lead, a lot
of process overhead with overall unclear return for my team's ability
to create quality UX and design work product. The sense of urgency may
be getting us to deliver faster, but it doesn't guarantee that the
stuff we deliver is "good enough" to launch.

Ruth

[Michelle Thatcher]

Ruth, I love your idea of a scoring system; I'll have to see if we can introduce it on our teams.

And I'm feeling so validated by your last two graphs -- they describe exactly my experience. When you have only two weeks crammed with all the work plus sprint planning and end-of-iteration reviews, and especially if you have a lot of stakeholders, it can seem like you've only just gotten your mind around all the little contingencies to the work you're doing, and suddenly you have to turn something over. Things can get pretty sloppy, for no particular good reason.
 
Best,
Michelle

[Celeste Crocker-Payne]

Really great discussion here! Rachel and Stephen both your posts
reminded me of a few other 'support' items that I had during my
previously described project.

We had pretty detailed project scope and even more detailed business
requirement documentation that helped define "how big the bread box"
was --so our site redesign did have a rough framework to target
(moving, but still a target). These items were critical to help frame
up the project at a high level. With business requirements and scope
defined (and my initial work in terms of content needs outlined) we
were able to chunk out pieces of the site into small pieces (sprints),
and I was able to try and develop a content model with an eye my
current sprint as well as functionality coming up in future sprints
down the road.

To be honest, there were times within the project where because a
specific piece of design or functionality was so intertwined with
another, 'sprints' or had to be reorder/re-prioritized. For example,
user account functionality was slated to be towards the end of the
project, but because it became a big piece of viewing products, this
piece of functionality was moved up, and had to be spec'ed out sooner
rather than later. This wasn't at all optimal, often pushed project
timing into flux and frustrated the heck out of our project team, but
it was a necessary evil of the project.

Rachel -- the challenge you bring up is what I often describe as a CSs
natural need to understand, categorize and rationalize information --
molding it into a framework/system within which anyone (even those
unfamiliar with the subject-matter) can understand and grasp. It's
just what we do :) Agile seems to contradict this activity because it
forces you to work in an iterative manner where your framework is only
as good as the information that's in front of you at that moment.

To Stephen's point, I had to try and have a long-term vision of
content (and how to present it) versus the '100% right and lock-
downed' vision that everyone, especially CSs, really want/need to
have.

That lack of specificity and vagueness did really drive me crazy
during my project. I pretty much had to realize that there would be
things that I would have to go back and rework/adjust as we worked our
way through the site. Unfortunate, and with the amount of rework I
agree with previous posters that Agile isn't necessarily the most
efficient method of web design. But on the positive side this approach
did force collaboration between multiple teams/stakeholders. It also
forced groups that typically love to overlook CS (*design,
development) to understand and see the value first hand.

One additional point, I think that if web teams are using this method
that you MUST communicate the high possibility of change/rework to
your client -- not merely for timing and budget but to prepare them
for possible gaps in system functionality and changes in UX design
decisions.

P.S. -- for those that requested a version of the content template
document I mentioned earlier, it's coming, I promise. I needed to de-
client-ize it a bit and I hope to send it out tomorrow. Again, great
conversation all!

Celeste

> <rachel.lovin...@gmail.com>wrote:

> ...
>
> read more »

[Rachel Lovinger]

Lots of great points being made here, and there are definite benefits in terms of team dynamics. As Ruth points out, the timing of the sprints also has an impact on the effectiveness of the team. All of these are things that I think can be worked out, and are in some way accounted for in the Agile process itself.

 

The big X-factor for me is still the CMS - some seem to accomodate "rework" more easily than others. They absolutely require details, at least for the bits you're trying to accomplish in the current sprint. So, as you move through the process and learn things that make you want to go back and update previous configurations (assuming time has been alloted for that), well, some CMSs may be flexible enough to do that and some may not. 

 

For the "strategy" aspect of content strategy, I can see how it can fit into an Agile process (much as I might like to know all the details upfront, I'm prepared to work with what I've got in the moment). It's the *implementation* of the strategy that I'm concerned about. Of course, as Ruth mentioned, being able to prototype real things as you go is a hiuge benefit here, and maybe that helps catch flaws in the implementation that wouldn't be noticed until too late in a normal waterfall process.

 

So, maybe my whole issue is really just with certain CMSs, not with Agile at all :)

 

-Rachel

--

[R. Stephen Gracey]

I think that's absolutely right. Having struggled with TeamSite for four years, the move to Drupal has made so many more things seem possible because so little has to be "locked down" to start. I've decided that any CMS that requires an army of programmers isn't worth any of the claims that the vendor might make. But that's just in my experience, limited to Joomla!, Drupal, and TeamSite.

Stephen

[Tomomi Sasaki]

Rachel's point about CMSs strikes home to me. Even though I wouldn't be involved in the CMS development itself, I'm more comfortable during the CS and IA phase (and more precise in managing the project in general) when I have experience with the CMS that will be used. 

It's interesting to think that there could be a CMS of choice for content strategists, in the same way that Expression Engine is the CMS of choice for many designers. Would you say that flexibility in data model handling is the biggest factor? 

Tomomi 

AQ株式会社
佐々木朋美 / Tomomi Sasaki

tom...@aqworks.com

Twitter: @tzs / @ripplet

Tel: +81-03-6427-6027

http://www.aqworks.com

[Rahel Bailie]

Because a CMS is supposed to address a business problem, the idea of a "CMS of choice" is a little bizarre, to me anyhow. I often use the metaphor of vehicles (seeing as how a CMS is basically a technology "vehicle" that moves content around, according to a set of "traffic" rules) to explain what I mean. Before you decide what the "best" car is, you ask "best for what?" and if you're a couple who loves speed, you might choose a sports car. If you're a family of four plus a dog, you might choose a minivan. If you need to transport workers to and from oil rigs, you might choose a Sakorsky helicopter. So what's the best vehicle? I'll choose helicopter every time, though everyone else may think the sports car is best, or the minivan is best.

I've used Expression Engine and WordPress (the "motorcycle" end of the vehicle spectrum) as well as Interwoven, SiteCore, and OpenText (the monster-size trucks used on mega-construction sites) and some custom CMSes that would be the equivalent of a warship. I wouldn't recommend EE or WP to the orgs that need the warship-strength functionality, and I wouldn't recommend EE or WP for the little organization that has relatively simple needs.

Rahel Bailie

2011/2/25 Tomomi Sasaki <tomo....@gmail.com>

[Paola Roccuzzo]

I wholehartedly second Rahel's opinion, and I would add that a CMS is
not a tool for the Content Strategist, but a publishing platform (or
part of it, in complex Enterprise-level architectures). So, beware of
strategists who have CMSs of choice.

What ideally a CS should be confortable with, IMHO, is having a
high-level under