Lisa Call

Why Do I Need to Know This?

One of the items on my goal list for 2008 was to define what success means to me as an artist. As I mentioned in that post, my definition of success has changed, so I wasn’t sure where to go with my goals for 2008 at the beginning of the year so I didn’t really write any.

This wasn’t a bad thing because turns out what I really wanted to do this year was sell my house and get out of the suburbs. That lifestyle was no longer working for me. I loved my big house and big studio but I’m much happier in the city: close to work, close to the kids school and close to everything – museums, galleries, restaurants. I’ve seen more art in the past few months than I did the last 5 years, because it is right here 10-15 minutes from my house.

But back to success. I feel it’s now time to define what it means to me to be a successful artist. I have a vague idea in my head what I intend for my career but I want to write it down and give it some serious thought.

I feel I need to do this right now for a few reasons:

1. Clarity: Most importantly I want to get really clear about why I am making art and how I want to market it. Or more accurately, why I am making art today and where I am intending for this career to go. I believe that getting very clear about intentions is the best way to ensure they become real. When I am wishy washy with my intent my results tend to be wishy washy. When I get really clear I find I get very clear results also.
2. Adapting: I don’t think it’s realistic, at least for me, to come up with big grand ideas about what success means and for it not to change over time. I wrote out some definitions for myself a few years ago and then I moved and I decided I like selling my art and so much of what I wrote is no longer up to date. By revisiting this definition I can learn and adapt and move get closer to my true desires.
3. Direction: Having a definition of success for my art career makes writing goals very easy. If I know what I think success means then I just have to do the things that will result in that success. Without a definition of success it’s kind of hard to figure out what I should be doing on a day to day basis. There are thousands of things I could do as an artist and only by understanding what my desired destination is, can I pick the activities that best suit my stated intentions.

I’ve spent a couple days writing and thinking about the specifics of this definition and when I get it finalized, or at least polished enough that it feels right and it is clear, I’ll post it on my blog.

 
Do you have a definition for what success means to you as an artist?

 
Another post in my series on Scrum and My Art Business.

My last post I talked about User Stories. I was going to write about managing tasks in this post but realized I needed to cover some more basics first.

The Team

In a previous post I introduced the product owner as one of 3 roles in scrum. The other 2 roles are Scrum Master and Team Member.

Each scrum team typically has these members:

• 1 Product Owner – who writes the user stories, brings the vision for the product to the team and prioritizes the work to be done
• 1 Scrum Master – who gets rid of impediments that are stopping the team from getting their work done (more on this role later)
• 5-9 Team Members – who do the work. From design and architecture to coding and testing.

In my art business there is only 1 person to play all roles. The past month it’s been interesting to think about the difference between each of them. I find I excel at the product owner stuff of bringing vision and thinking up things to do. I’m less effective at actually doing it, not because I can’t, but because I get distracted. So I think I could be a better scrum master and keep myself on track better.

This weekend I unplugged my computer and removed it from my studio/bedroom – the result was 16 hours spent making art. Score one for the scrum master on that decision.

Iterate

One of the key features of scrum, and most agile software development processes, is that the work is divided up into iterations. A group of work is selected to be done for each of those iterations. In scrum those iterations are called sprints (because they had to come up with new words for everything).

Scrum is a series of sprints, typically anywhere from 2-4 weeks in length, that follow this structure

1. Planning Meeting – The teams select a set of stories to complete in the sprint.
2. The Sprint – The team works on those stories during the sprint.
3. Sprint Review – At the end of the sprint the team demonstrate the complete work to the product owner for approval.
4. Sprint Retrospective – The team holds a meeting to evaluate how the sprint went so they can adapt and do better next round.

Repeat these 4 steps over and over and over without end. Every once in a while the software is released to customers and developers move onto the next release with new functionality in the next sprint.

Planning

At the beginning of a sprint the team sits down and decides how much work they can do during that sprint. The stories are prioritized by the product owner, so the team selects the highest priority stories. Each story is also estimated in size. So the team picks the amount of work, based on the size of the stories, that they feel they can complete in the sprint.

Prioritization and Estimation are black arts in the world of software development and maybe not so different for an artist so I’ll touch on these topics again in future posts.

By doing the planning at the beginning of each sprint, instead of all of it up front at the beginning of the project, it is possible to make better informed decisions about planning as the project matures. It’s a fallacy to think the scope of a software project can be determined up front and locked into place. Scrum allows for a more natural way of planning and prioritizing the work.

I think this fits the needs for an art career well. As new opportunities arise and details of existing ones are made more clear, replanning each month allows an artist to reprioritize the importance of each of the goals.

I’m trying out some of these ideas and have decided on doing sprints of 1 calendar month. At the beginning of September I selected some user stories to work on for the month by looking through all of the work I wanted to do.

Sprinting

During the sprint the team members do the work to complete the user stories. They hold a daily meeting in which each member answers these questions:

1. What did I do today
2. What am I going to do tomorrow
3. What (if anything) is blocking me from doing my work

It is through these meetings, and the amazing power of peer pressure, that the team functions without an authoritarian model. If you had to stand up at work each day and be held accountable to your teammates for pulling your own weight, the theory is you will actually do your work, vs surf the internet and buy stuff from amazon and ebay.

I’ve mentioned before that I have an artist mastermind group that I email every night answering exactly these 3 questions. While we are not a team, in that we are working towards a common group vision, having to say to other people "err – didn’t do a darn thing – again" is huge motivation to keep on track.

I highly recommend this type of group activity. I found my mastermind partners during the Artist Breakthrough Program” I took with Alyson Stanfield last spring. We’ve been emailing almost daily for months now and I know for me personally it is huge.

The Review – And Done

At the end of the sprint the team demonstrates the software they completed. Only user stories that fit the definition of done are demonstrated (see my previous post on this topic of what done means.) Almost done or close to done don’t count.

The product owner looks at what the software does and decides yes or no if it is acceptable. How do they decide? It’s based on the acceptance criteria for the user story (see the section on testing in this post about users stories for details on acceptance criteria.) If the product owner either accepts or rejects the work.

Any story that is rejected or that does not fit the definition of done is moved back to the list of incomplete user stories and is placed in a future sprint during a planning meeting.

I’m about 1/3 of the way through my first art sprint so I can’t report on how this might look but I’m hoping I don’t reject too much of my own work as not good enough.

I’ve been doing planning in iterations for my art career for a while now, and again I use my mastermind group to keep me on track. I’ve tried weekly goals and 2 week goals and monthly goals. Again emailing to the other artists what I hope to do for the month and how that month went. So I’ll continue doing that as a part of my sprint reviews.

The Retrospective

The adaptive nature of scrum is a very important piece of the process so I’ll devote more time to this later also. If you aren’t thinking about how things went and changing behavior based on those observations you aren’t doing scrum. And really, you aren’t being very smart about life.

We’ve all heard the saying: the definition of insanity is doing the same thing over and over again and expecting different results.

It’s really rather obvious, but it’s also not so easy to implement.

The Rock

The photo at the top of this post has nothing to do with scrum but I like it so there it is. Another photo from hiking in Colorado. The water looks golden because of the pebbles underneath.

Click on the image for a larger picture and more rock details (I love rocks). It looks totally cool with my LED fancy screen on my laptop, which hasn’t yet been color calibrated so who knows what colors you might be seeing.

What Needs Done

The requirements for a software project are called user stories in the world of Scrum. These are basically a list of things that the software needs to do and they are written by the product owners, as I mentioned in my last scrum post.

User stories have a fairly specific format according to the Scrum powers that be, which is:

As a [insert person here]
I want [insert action person would like to take]
so that [insert benefit of action here].

For example, a user story for a user of a blog might be:

As a blog reader
I want to be able to leave a comment on a blog post
so that I can participate in the conversation.

This story tells the developer they need to provide a mechanism for readers to leave comments.

Art User Stories

The past few weeks I’ve been working on writing my art goals as user stories. Except not really. Because I see no reason to follow the above format.

The "as a" person is almost always me, the artist. So I skip that. And I am not looking to communicate between multiple people (in Scrum the product owner writes the stories and the developers need to understand them). I figure I understand myself fairly well so don’t worry about lots of extra words.

The "so that" benefit piece is important and if I see myself writing down a goal that has little to no benefit to me as an artist I question myself as to why I would want to do that item. Last month I ended up not entering 2 juried shows as I determined it was a large time drain with basically no tangible benefits to me.

Some examples of my user stories that I’ll be tackling in September:

• Complete setup of my new laptop
• September Studio Newsletter
• Complete rewrite of my website/blog
• Update artful home webpage
• Show my art at Butler Museum Show

Not quite as detailed as a software story but plenty of information there for me to know exactly what the thing is about.

Conversations

The description above is just 1 of 3 parts to a user story.

User stories are not complete and so they are a promise of a future conversation between the product owner and the developers [you will see this phrase a lot if you read much about user stories]. These conversations are the second part of a story. The constant feedback from the users of the system, represented by the product owner, is a key feature in making sure that the software that is delivered is what the users want.

For me as a solo artist I’m not going to be having conversations with myself about the stories (or at least not admitting that I talk to myself) but what this means to me is that I need to not get too hung up on some goals that maybe in the end aren’t what are best for my art career. I need to constantly adapt to the feedback I get from the market place and adjust my goals accordingly.

This adaptive feedback loop – plan – do – study – act (ie adapt) – is a key feature of scrum and it will come up several times. It’s also know as the Deming Cycle and makes for interesting reading.

Testing

The final part of a user story are acceptance criteria. How do I know when the story is completed, successful and done? I talked about done the other day. Each story needs to define what that means. When is the story Show my art at Butler Museum Show done? What makes it successful?

In the software world we write these things down as they are very important. Our quality engineers use these acceptance criteria to test the software and the developers use them to know that they are finished with the story.

In the art world I’m not writing this stuff down for the obvious things, at least right now. I think in the long run it might make sense to write these things down because how else do I know I’m done. For updating my artful home webpage – is it done when I’ve done the upload? Or after they have selected some work and put it on my page? Do I need to update my records as to which pieces they are displaying? To be clear, this information is best written down.

For the rewrite of my webpage the acceptance criteria is clear – the acceptance criteria is that I go live on both my blog and website with the new design. Anything short of that and it’s not done. (fixing bugs is a whole other story – but for now let’s assume there are none).

Tasks – Where are the Details

User stories tell the developer the What and the Why of a requirement. They don’t tell the How.

Writing down redesign website is all wonderful, but just how the heck do I go about this?

The answer is what most productivity folks say – you have to break down big stories and goals in to small manageable tasks. And that will be the subject of a future post as this is getting rather long.