Content Strategy & Agile
Rachel Lovinger
Alexa D. O'Brien
--
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
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
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
>
>
>
> > 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.
>
Rahel Bailie
--
Rachel Lovinger
Noz Urbina
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
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
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.
>
> I can maybe hook you up with one of the speakers on Twitter if you like.
>
>
> >> 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
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
Mobile 07879 005 946
Web site/Blog <http://www.farbey.co.uk>
Twitter <http://twitter.com/dfarb>
nickyt...@gmail.com
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
Manifesto: http://agilemanifesto.org/
Good stuff.
Nick Strate
On Feb 16, 11:22 am, "nickythebl...@gmail.com"
>
> read more »
danbarley
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
Has anyone written a good book about Agile?
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
--
Ruth Kaufman
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
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
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
Celeste Crocker-Payne
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
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.
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
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
R. Stephen Gracey
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
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
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
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
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
>
> read more »
Rachel Lovinger
--
R. Stephen Gracey
Stephen
Tomomi Sasaki
Rahel Bailie
Paola Roccuzzo
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 understanding of which functionalities the different ranges
of CMSs have (from Enterprise, to Document Management, going through
Catalog, Components, etc).
A CS who is familiar with the concepts of entities/templates/schemas
and workflow/content lifecycle will be able to write down the business
requirements (tender), and challenge the vendor about how their
solution fulfills those requirements (commercial discussion).
And, since this discussion is devoted to Agile frameworks, my
experience as an embedded content expert in teams of software
development has brought me to the following conclusion: a CS should be
considered both as a business analyst and a practictioner, so he/she
should be involved in the requirement gathering phase as well as in
design and iterations (and remember that Scrum and Agile are not
synonymous, so sprint is really a Scrum concept).
As far as deliverables are concerned:
- Content audit and gap analysis should be part of the requirement
phase (and a well written gap analysis will basically create the task
backlog);
- Schemas/templates/wireframes are part of the design phase;
- Creation of copy/assets is part of the iterations;
- Data entry/management should be considered the first line of testing/QA.
Paola Roccuzzo
2011/8/5 Rahel Bailie <rahel....@gmail.com>: