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.
Has anyone written a good book about Agile?
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
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
On Wed, Feb 16, 2011 at 5:13 PM, Kevin Rapley <ke...@digikev.co.uk> wrote:
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'
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.
> The UX Book Project - Chapter 16: Agile UX Methods
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
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
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.
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
- 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.
2011/8/5 Rahel Bailie <rahel....@gmail.com>: