Lisa Call

 
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.