Productivity

Agile Creativity – Principle #11: Self-Organization

by

(This column is posted at www.StevenSavage.com and Steve’s Tumblr.  Find out more at my newsletter.)

We’re almost there, my iterative (ha) effort to review the principles behind the Agile Manifesto – for creatives. We’re on the eleventh principle.

The best architectures, requirements, and designs emerge from self-organizing teams.

For people not familiar with IT, the only area of this that may seem odd is the word “architecture,” the structure of IT systems and the like. So let’s tweak this just a bit for creatives

The best structures, requirements, and designs emerge from self-organizing teams.

There we go. So what can we learn from this principle?

The idea is basically this: that teams who-self-organize create the best designs, the clearest requirements, and the best way to get stuff done. This sounds great, but I find a few people worry about it; how can people who self-organize get stuff done?

That’d be a great title for a section.  Let’s do that!

How Can People Who Self-Organize Get Stuff Done?

First, the entirety of Agile thinking and Agile methods is about self-organizing. The principles reflect this constantly, from communicating among people to reflecting and analyzing ideas and results. All of this helps cultivate self-organization.

(Also, most teams self-organize anyway, because no one can constantly be there monitoring their every move, though people try.  So it’s more realistic.)

Secondly, I take the word “teams” in the broadest sense – this is everyone involved in the process, from the actual creative to the person requesting the work to the people giving feedback.  I mean everyone involved – we’re all part of the team, even the folks ordering the work or the users testing the software as part of a beta program.

I find this approach helps because when you think of teams as broadly as possible (which you should), there’s more collaboration and communication, more trust, and far less us-versus-them. You get a lot more done as you’re automatically involving more people . . .

. . . and you cultivate self-organization with training, with being a good role model, with pitching Agile methods, and of course by using the principles of Agile and the methods to get your own stuff done.

So Why Does This Work?

OK so your team self-organizes and gets how to work together.  Or they’re close enough that they self-organize anyway.  But why does it actually work?

  1. People use their hands-on knowledge to design, plan, and organize. Like it or not the person up top of the big old command pyramid doesn’t know what’s going on all the time – the people doing the work do. This is doubly true for creative works, that often require intimate knowledge, gut-checks, feedback, and specific knowledge.
  2. People find the structure that works for them. The people doing the work don’t necessarily know what’s going to work at the start – but being self-organizing they’ll find out. Plus this exploration yields insights they can use elsewhere.
  3. People who self-organize communicate. This feedback tells people what’s needed, allows for adaption, and builds relationships to further the work.
  4. People determine needed artifacts. Agile principles and methods aren’t big on giant piles of documentation, but we do need them. When you self-organize you come up with what’s needed to track work, describe it, and record information. This saves time and increases clarity (also saving time).

Just remember, to make this work you have to make sure people are allowed to self-organized, encouraged, and trained or otherwise supported in doing so.

Where Does This Help Creative Work?

I’ve hinted at just how this affects creative work, but let’s get down to it – why does self-organizing support creative work – and how can you support it?

It Avoids Overstructure: Starting a creative effort with lots of unnecessary structures in place will kill creative work which needs a level of freedom and feedback and experiment. Allowing teams to self-organize helps avoid this.

  • What you can do in your creative works is allow for self-organizing and be aware of when you’re over-attached to processes and procedures.

It Allows For Adaption: Creative work is hard to automate, even though many of us have tried (me included), and it needs room for adaption. Allowing for self-organizing teams allows for that adaptability upfront – people can find what works for them.

  • In your creative works, support adaption by helping people (even if it’s just you and your client) change and adapt what works, with your eye on the eventual goal. That focus on value will help keep you from being distracted.

It Allows For Communication: Creative works are communicative work (even if sometimes the goal is to confuse, such as in a challenging game). To support communicative work people have to communicate and thus self-organizing teams support that – but also force it. When there’s no checklist being ordered and people are encouraged to communicate, you get more actual talking.

  • For creative works, encourage communication among people – and communicate yourself. It helps to be supportive, finding what works for them, not forcing your goals of “how it should be done,” but helping people find what must be done.

It Creates Habits and Culture: Self-organizing teams build their own structures and methods – and habits. This means that there’s more than just some org chart – there’s good habits and in long-term efforts, a culture that evolves. People who develop their own structures,, methods, and so on will remember and embody what they’ve learned. In time this leads to even more productivity as this is in the bones.

  • In your creative efforts, support developing a culture by finding what works and noting things that went right. In times the best lessons burrow into peoples habits.

What About Solo Creatives?

But what about solo creatives? How does this apply?

Recall that the “team” is everyone as far as I’m concerned – the client, people giving feedback, your roommate offering unsolicited advice. Even if you’re on there own there’s still “teams.”

What you want to do is:

  1. Find what “teams” there are – you and a client, you and an editor, etc.
  2. Encourage the teams to self-organize. Be open to feedback, listen, communicate, focus on goals.
  3. When possible, cross teams over. Share that client who wanted your art with a writer that you know. Share an editor with someone else. Build a larger culture among individuals to support each other.
  4. Even when it’s just you in the end, listen to yourself and your ideas. You’re a multitude – be your own team.
  5. Self-organize – don’t get too lost in other people’s ideas and advice, even mine.  Learn to rely on your own wisdom.

Always keep the need to adapt and adjust and self-organize.

In Closing

The eleventh agile principles notes that self-organizing makes for the best results. This works because people communicate, determine what works, and create what structures and tools are needed to get those results. You can encourage this with

  • Avoid overstructuring
  • Encourage adaption with feedback.
  • Encourage communication
  • Encourage development of a larger culture – the self-organizing lessons we keep with us.

Self-organizing teams can produce the best results – even if sometime the team is one person.

– Steve

Agile Creativity – Principle #7: Usable Work

by

(This column is posted at www.StevenSavage.com and Steve’s Tumblr)

We’ve passed the halfway points! We’re now on the Seventh Principle behind the Agile Manifesto. It looks simple, and in fact is simple, which means I’m going to go on at length about it. Let’s take a look:

Working software is the primary measure of progress.

Yeah, it’s pretty clear isn’t it? I’m very fond of it because the idea is the measure of progress is something that actually works. No maybies, no charges, no plans, no mockups. Something that works is how you measure progress.

But let’s tweak it a bit for creatives, since creative work involves a wide range of stuff from art to presentations to films.

Usable products are the primary measure of progress.

There, not much of a change, but we broadened it out. You measure progress primarily by giving people things that are usable.

Now of course, I’m going to analyze the heck out of it.

You measure progress with something people can use – even if imperfect

Your efforts should focus on giving people something they can use and experience – that’s it.  It’s usable/working/review-able or whatever you want to call it.  That does not mean it is:

  • Complete.
  • Ready for public release.
  • Ready for all of your customers to use.
  • Even that good.

You may deliver work that’s incomplete and lousy, but at least each embarrassingly bad delivery there’s something people can use to give you feedback.  You will improve it over time.

As you may guess this means . . .

Delivering usable product means feedback

Giving people something they can use, no matter how incomplete or half-baked, at least means you’ll get feedback on it. It may not be nice feedback, it may mean a lot more work, it may mean a change of direction. But at least you know what to do next.

So the more often you deliver, the better you do getting people to their destination – because you learn how to better get there.  It’s a lot like navigation – in fact your customer or client may learn about what they really want once they have something they can really experience.

But it’s not just people who give feedback. You and your team give each other feedback. If it’s just you, then YOU give yourself feedback (even if it’s “that was dumb”). You also learn by making something usable as opposed to reaching abstract deadlines and milestones.

There’s nothing like having to make something workable to really learn what you have to do, and what you shouldn’t have done.

Now to do this . . .

This almost always means iterative development – so plan for it

So as you’ve probably guessed from reading so far, this Principle really hearkens to iterative development. You measure progress with usable product, so you’ll be delivering useable product over time – probably improvements of previous deliveries. That’s pretty common in Agile, obviously and we’ve already discussed it.

But this means that anything useable you deliver is something you should plan for and keep in mind. Don’t just work on something, work on it in a way that helps you give actual results as often as possible. This could mean:

  • Constant refinement, like putting a logo through more and more iterations.
  • Delivering in usable parts, like a costume where each piece is complete (and, say, at least display-worthy).
  • Delivering in review-able parts, like a piece of writing where each chapter is something that can be edited.

So you can keep getting work out, do that work in the best way that keeps delivering useable results. Because when you do that . . .

Usable Products Are THE Way to Measure Progress

Delivering usable products is the way to measure progress. There’s the obvious ones of “this customer is happy,” but you can also use this to get a bit more mechanical and procedural.

  • If you have a list of features for something, like perhaps a game, as you deliver them in prototype, you can check them off. Yes, some may be wrong or changed, but you can get a rough idea of progress.
  • If you are aiming for certain numbers, such as a performance score or loading speed or image size, then you can measure them – with workable product.
  • Of course, you get abstract feedback from others, maybe customers or even beta testers and early access users. They might provide other quantifiable forms of feedback, ranging from yes/no responses to answering polls and questions.

From simple lists of features to complex analysis, usable product is not just a way to measure results in general, but gives you a way to get specific results, maybe even complex ones that need some number crunching.  Thinking in deliverables and producing them gives you access to a wealth of data.

Though I wouldn’t overdo it. This is Agile after all, let’s not get complicated.

Rounding Up

Let’s review the Seventh Agile Principle for Creatives:

  • Frequently produce something usable for your audience, no matter how imperfect.
  • Iterative development is the best way to do the above, so organize your work accordingly.
  • Because you are delivering something usable, you’ll get feedback and learn, meaning you can produce a better product.
  • If you need to have deeper analysis, working products are a great way to do it.

It’s another simple principle, but it’s really great advice – progress is producing something.

Sounds like you could overload yourself with trying to constantly get stuff out, right?  Well, let’s move to the Eighth Principle . . .

– Steve

Agile Creativity – Principle #6: Facetime

by

(This column is posted at www.StevenSavage.com and Steve’s Tumblr)

Agile principle #6 is a simple and sweet one about communications.  It needs no embellishment:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This is obvious.  If you want to get the most done, effectively, talk to a person directly.  I could probably stop here and you and I have easily discussed 70% of the value of this Principle.

Obviously I’m not done – and we’re talking Agile and Agile Creativity, so there’s some subtleties to go into.  So I’d like to discuss this principle in a bit more detail, and focused on creative work.  This probably would be faster if we were face-to-face, so revel in the irony.

Good communication is vital to all work – creativity moreso.

It’s obvious that you get more done productively if you actually go and talk to people, and in-person conversations convey a lot of information effectively.   In-person you can judge gestures, expressions, voice pitch and more.  In-person you sync-up with people better.

When you communicate effectively, you say more, hear more, and can work effectively.  You can adapt better because you’re actually talking to someone directly and saying so much more.  I’ve seen team behavior change and become more productive when face-to-face activities are introduced.

In creative works are challenging to communicate because they involve everything from intuitive interpretation to understanding complex emotions.  This makes face-to-face or similar far more important because there’s just a lot to convey.  So if you have to collaborate creatively, get talking face to face

(As you may guess, I accept we can’t always get face-to-face, which means) . . .

Face-to-face isn’t always possible, so make due

Communicating with people on your team face-to-face sounds great.  It’s also probably impossible at many times due to location, travel, mutual loathing, and what have you.  So what do you do?  You find the closest-way to face-to-face in order to interact.  This could mean:

  • Video conferences (with sharing)
  • Chat programs (of course)
  • Phone conferences.
  • Meeting face-to-face when you can and packing in all the communication you can do.

You do what you can.  This may mean when it comes to creative works, you have to get pretty innovative.  You may do things like sending people videos and following up with online chat, and it may not be face-to-face, but it’ll be as close as you can get.

Is this somehow violating the ideal?  No, because . . .

Face To face is the most efficient and effective method – not the only one.

This Principle is a recommendation and a statement of truth – face to face is the best way to communicate within your team.  It’s not the only one, it’s just the best.  Agile isn’t big on hard rules and structures.

But sometimes the best is not available, so you do what you can.  Don’t fret, don’t beat yourself up over it.  Just do what you can.

A quick thought for solo creatives.

Does this matter to the solo creative?  Actually, hidden within this Principle are two important lessons:

  • You may be solo, but changes are you still are depending on other people for some things.  Delivering supplies.  Providing editorial services.  Etc.  Face-to-face still applies to these “team-like” connections.
  • Are you taking time to really communicate with yourself?  Analyze results, do research, consider where you’re going?  You might not be – learn to pay attention to yourself.

A moment for review

This simple principle is pretty easy to review:

  • Face-to-face is the best way to communicate with your team members.
  • If Face-to-Face isn’t possible, learn the best alternatives.
  • Even when solo, practice good communications techniques and take the time to self-reflect.

Simple one there.  Good, because the next Principle seems simple – but has a lot of depth.  In a way it’s a core to a lot of Agile thought . . .

– Steve