an agile designer...

Certified SCRUM Master Trainning :: Day 2

2010-01-23T14:18:00.000-08:00

I won't lie, Day 2 was a long one.

The 182 slide Power Point was dense with information. It was cool to get more in depth on all of the topics covered in the previous session. I learned a good deal more about some of the things I was interested in, namely Burndowns and other forms of reporting. It was one of the things that while working on a Scrum team, I just never really understood. I get it now, though.

We also dug deeper into some of the dynamics of how a Scrum Master and Product Owner interact. The Product Owner (or Client, or Business Owner, or my fave 'the Truth') role is a very important one. Without a good PO, your project is doomed to fail. The PO's is primarily responsible for the Story Backlog and marking a story as complete. We learned how the Scrum Master and PO need to work together well.

A recurring theme for the day was around how the Scrum Master is a facilitator for getting a problem solved vs. a problem solver. Getting the team to care of of it's own issues internally and removing obstacles, external to team, that stand in the way of them getting things done. I always preferred this dynamic over the one of a traditional Project Manager.

One of my favorite Agile principals is Self-organizing teams. Leaders within a team lead, because they want to, not because they have to. I have seen people who didn't really think they had what it takes to lead, fall right into it, manly because their team saw them that way. And conversely, Scrum teams are flat, so just because you have some title or more time at the company, means nothing to your team. Respect comes from solid performance, and being a good team player becomes very important. More important than individual acclaim or advancement. Accountability to your team can be a very powerful motivator to perform well. I like to think of it like a basketball team, full of players that would rather have a personally low stat night, but get the win. A pass-first mentality goes a long way in an Agile setting.

Working and thinking as a team is extremely important. We played some Planning Poker, showing us that healthy debate and not being too polite is imperative to open communication. Having been on a Scrum team for a long while, you start to speak very directly to one another. You get a bit thick skinned. It cuts through the BS and makes you feel much closer to the people you work with. We would have guests come by to see how we were working and we heard more than once that they were taken back, a bit. It's not all empty corporate-speak. For instance you wouldn't hear, "I don't completely disagree with you..." What? You agree or not? Just say it, don't waste my time...

So, a good day overall. Tons of information to go back and look through. I hope to get my exam invite soon, while it's all still fresh in my head. I will keep you posted.

Certified SCRUM Master Trainning :: Day 1

2010-01-21T19:20:00.000-08:00

My good friends at BigVisible offer some of the best Agile/SCRUM training and coaching around. I have been looking forward to my CSM class, taught by Giora Morein, for quite some time. I have taken Scrum training before, but this is more involved and should set me up pretty well to pass the Agile Alliance's SCRUM Master exam.

Day one started off with some introductions. It was cool to get a sense of who was there and why. Most of the participants are there through their employers. Only one other guy was there on his own dime, like me. The group is made up of IT folks and PMs. I, of course, am the only designer.

We set up in groups of four and did an exercise that simulates a sprint (aka, an iteration). Getting people who are new to Scrum to understand things like team velocity, planning games, story writing and point estimations can take some work. Generally speaking, people who want to learn agile frameworks are very open to it. They get that there's less documentation and more collaboration, for instance, but they need to compare these new things to something they know. Like, a Story Backlog is NOT a BRD...

So, we did some story point estimations, worked through the stories (folding hats, blowing up balloons, bursting said balloons, stuff like that) and learned how points work to make up a team's velocity.

After lunch, Giora did a very comprehensive presentation that introduced the Agile Manifesto, the cost benefits of using Agile over Waterfall, some guiding principals for Agile development and Team Member Rolls.

An interesting observation here is that, the people in the room all 'get it'. They are there because they already understand the potential upsides. And they all say the issues around getting Agile going where they work, is getting buy-in from the powers that be or from the the non-Agile teams already in place.

All in all a great day. More to come tomorrow.

Designing it up front, and throughout

2009-04-23T17:13:00.000-07:00

I recently read a blog entry by Sara Summers, that really got me thinking. Thanks Sara!

I have been working in Agile projects for a few years now. I have come to find that part of my role as a designer, within the process, is to constantly explore and redefine exactly how to get the most out of the iterative, organic nature of the process and still make the time to get a kick-ass design in place.

my Twitter convo with Sara:

@ssummers I think most designers have a tuff time w/ many Agile principals. It is a Dev focused process after all.

@jason_goodwin Agreed. It can work if oxygen is supplied to design upfront.

I thought this was very well put, indeed. And it begs the question; How much design and how far up front?

As designers, we feel we need to have a complete view of the entire experience before the building can begin. One of the things I like the most about designing in an Agile environment is not knowing exactly what I 'should' be doing and going with the flow. The down side of this is finding the best way to inject the stuff you learn during each iteration back into the overall experience. I have some ideas about this, but that's a different show...

I am also not a fan of reading/writing huge documents. I like communicating ideas visually and Agile not only allows me to do that, it forces me to. I have found that most of the other people on the project would rather look at at picture of what it is we want to build vs. reading about it.

Something Sara takes issue with is the notion that designers should have to write code. I write tons of code, for a designer. So much that I consider myself a pretty decent UI developer. It's my feeling that if you are a designer who wants to learn some code, or wants to expand on what they know already, Agile is great for that. You get to work side-by-side with developers and QA folks and is a great way to get better, faster. On the flip side, if you don't want to write code, you get to teach some developers a thing or two about design (I have yet to work with one who didn't want to learn). I see it as a win-win.

Please look at Sara's site http://www.uxarray.com it's quite good.

Coming Clean

2009-03-18T09:58:00.000-07:00

I think, perhaps, maybe...

The reason I don't blog here more, is because I seem to have bad luck with the Agile projects I have been assigned to. There always seems to be some reason that someone, or group, just doesn't want to play along. It's as if they don't understand that by not getting involved, they doom the project in some way. It's kinda sad, really. And it seems to come down to, "not having enough time" or "there's someone else who should be doing this". LAME...

In economic time like these, shouldn't one of the goals be efficiency? Use what you have and get the most you can from it? C'mon people, get with the program... enough half-stepping...

grrr... rant...

an agile job hunter

2008-11-26T06:43:00.000-08:00

I was recently laid off my gig. I knew it was coming so I tried to prepare myself as best I could. I spent loads of time on Monster tweaking my profile and resume. Brought my LinkedIn profile up to date. Asked all my friends and colleagues to recommend me.

The flood of calls from recruiters gave me a false sense of hope. I was getting calls, but no interviews. One little thing I did learn was; if you treat every conversation with a recruiter as an interview, you will be much better off when (if) they get in front of an actual potential employer. Think of it as a dry run.

It can be tough selling yourself. Having the confidence to say that you are great at what you do, and deserve to paid for it, can be a hard hill to climb. But climb one must. Here's a short list of things to keep in mind:

- Don't be afraid to talk about money. Your rate should roll of your tongue, no hesitation. If you get the sense it's too high (and of course it always is) the word 'negotiable' can go a long way. But stick to your guns.

- Know what you want from a job. Is it a good company? Do they deserve you? Wiil they let do what you want, what you think is important? It's a two way street.

- If you are dealing with recruiters, don't be afraid to hound them. They make money by finding you a gig. Make them do their jobs. It shows you care.

- Most important one: Call people you have worked with in past first. Use your network, no matter how small. When someone you respect and respects you recommends you for a gig, it holds a lot more weight.

I was able to turn my personal network into paying contracts. While I wait to hear back from the recruiters.

Lazy

2008-11-10T18:11:00.000-08:00

I am so lazy. I don't write here much. I am going to try to be better...

Skip Navigation - I think we have that backwards

2007-05-02T12:13:00.000-07:00

I was recently listening to a blind person explain how he goes about reading a news article online. He said that he looks for a link to print the article so his screen reader won't have to deal with navigation, sub-navigation, ads and other things that get in the way of getting to the desired content - the news story.

This got me to thinking about the general approach to Skip Navigation. The one I am most familiar with is, basically, to add functionality to the top of the page, or any navigation that resides in the page, to skip over it and into the main content. Now, let's say we have a big site. It has a top level navigation and sub-navigation based on what section you are in. Would I skip from the main navigation to the sub-navigation, then skip to the content? For the disabled user this sounds like a lot of work and can be potentially confusing.

So, I started to think about this in terms of what is the real desired outcome of skipping navigation. When I click on a link, I'm want to read the content that is behind that link. I don't want to read the navigation again, or read the next level of navigation, or the ads on the page. I use secondary navigation as a next step, or last resort, if I didn't find what I was looking for.

So, what if, instead of building pages that have lots of skip navigation code, we build pages that automatically put cursor focus on the content, and there's a way to 'skip' to the navigation? Like the finding a stripped down version of the content, the print version for instance, this method just puts out a simple rule: Drop the cursor where the content starts. The user doesn't even have to know about the extra stuff on the page, until they go looking for it. Now they don't have to spend time skipping over stuff, and not knowing where they might land.

Passion – The Good and Evil

2007-03-04T05:34:00.000-08:00

In many of my of the jobs I have had, there would eventually come 'review time'. I was often criticized as being "…too out spoken… unapproachable… pissy… mouthy… boat-rocker… pot-stirrer", while, at the same time, being praised for "team work… innovation… stick-to-itiveness… and lots of hard work" but above all passion.

Passion is a funny thing. We love it when things are going good. As soon as things turn bad, passion is mistaken for aggressive or overly negative. I have had to defend my self many times on this point. Critical != Negative. In fact, outspoken people can be the ones who care the most. Never discount a bigmouth just because they are willing to voice the unpopular opinion. Besides, I like to believe people can see right through being negative just for negative’s sake.

A friend I was working with recently told me our Project Manager remarked to him, about me, "Man, that guy bitches a lot." And I do, when I see things aren't going as well they could be. I am also the first person to pat a team mate on the back and say, "job well done."

I spend more time at my job than I do with my kids. I need to care. That's when I know it's time to go, when I stop caring. There’s a certain sense of satisfaction you get from giving a crap about the work you do. I think that's a big part of being a professional designer, you can't phone it in. Designers get frustrated and mad and defensive because they are in a place where subjective opinion runs amuck. We have to stand up for the decisions we make and defend them against second-guessers on a pretty constant basis. I don't think that happens without passion.

Adding accessibility to an application or web site shouldn't be like putting toothpaste back in the tube.

2007-03-03T13:44:00.000-08:00

Good experiences don't just happen; they are planned for and executed on. Why is the accessible experience any different? An afterthought? An additional margin/metric/number that pads project time and cost?

When deciding on a target audience for any web site or application, there's always that under lap and over lap of users. "We want to target Intermediate-Advanced users, but there will be some Intermediate users and some Expert users and we want everybody to get exactly what they want…" Those fringe use cases can drastically change the experience for that those target users and everybody's OK with it. I'm OK with it. Yet, when accessibility comes up, it’s somehow more than fringe. It' like long-tail or outer limits.

The exercise of creating an accessible experience forces us to break down the message into very simple terms and figure out how to deliver those terms in a new way. If we take this into consideration early in the design process does it not enhance the visual design?

Designing the Experience

2007-01-22T19:11:00.000-08:00

One of the criticisms of Agile by designers is, "We need to be able to design the entire application from front to back to ensure a consistent user experience." I have noticed the over use of the term 'experience' over the past few years. A solid experience doesn't come from the iterative design process; it comes from a solid vision of how the user feels when they are using the application. Much like a brand, there's a bunch of intangibles that come up and explaining them can be the hardest part.

I like working through the nitty-gritty of the user experience of one small component at a time. It can open up some cool things that can be used in other places and reveal some what-not-to-do's right out of the gate. A little bit of focused trial and error on a small piece is always easier to change than finding something out way down stream and having to change the whole thing. Sort of like painting a small section of a room with the wall color and the trim color and seeing how it looks with rug, before busting out the rollers and going to town.

Design and Business – it’s all about the love.

2007-01-21T10:58:00.000-08:00

In many Agile projects, we hear about the ‘truth’. In many big corporations that means the Business Sponsor. I have found that the interaction I have with the ‘truth’ is what makes the engine really move. I have come to find that the role of designer becomes the role of idea generator.

Designers tend to feel an obligation to question every single business rule, and I’m no different. I have found the mini-brainstorms I have with my ‘truth’ put us on the same page, gives me insight as what’s going on in their head and opens a dialogue that is truly invaluable. Business Rules become shared ideas.

So much of Agile is in the talking to your teammates. When business and design show a united thinking, things really fly. I have yet to meet a business sponsor who doesn’t like to talk about ‘the idea’. Any chance to make the idea better is a win for all. I would much rather have a hand in creating the rules than spending my time questioning them.

All for one…

2007-01-21T07:35:00.000-08:00

A great part of Agile is the blurred lines between roles and cube walls. Hands down, my favorite part about Agile is co-location. Walking over to a developer's or business analyst’s desk for a quick chat is invaluable. Impromptu brainstorming coupled with reality checks, you can't beat it! I’m not 'just' a designer – I'm a teammate. If I see a gap I can fill, I fill it.

Recently on a project we had a pretty big, new feature set coming into an iteration. I couldn’t do a whole lot design wise on it – it was almost all back-end and middle tier work, and it was going to take the whole team to get it going. I saw something I thought I could do myself, so I did. In a waterfall process there's no way a designer gets to look under the covers of the code base, much less alter code and check it in. In Agile that's exactly what we allow ourselves to do. It may have taken me a lot more time than an experienced developer, but it got done and tested. In prior iterations I was able to sit with the developers and tweak look and feel as needed with them, so I had some idea of what was going on and I wanted to learn, so I did just that.

The QA testers on my team have done the same with me. They come with a print out of the design and we sit down and write test cases together, based on the interaction designs. If I want something to fade in, it's marked a bug if it doesn't happen. If the application doesn’t look like the design, it's marked as a bug. After I learned how to change some of the look and feel issues in the app myself, those bugs were assigned directly to me.

It is my personal feeling that the days of the single disciplined mindset are over. You have to be able to do more than one thing to make it. Here's my favorite example: Troy Brown of The New England Patriots. This man has played Wide Receiver, Defensive Back and Kick Returner, in the same game, for entire seasons. He is truly versatile and unselfish. He is a true teammate... and he has three Super Bowl rings to show for it.

Can an application have a narrative? It must.

2007-01-20T12:29:00.000-08:00

As accessibility becomes a bigger interest of mine, it is becoming clearer to me that the issues are not in the functionality or code needed to create accessible apps. It's in the design of these apps. As a visual designer I must stop designing visually. I must learn to design 'narratively'.

How can I read you an interface? How do my app designs tell stories? Can I tell a great story with my design without any visual aid?

The shift lives in how we think about interface design and application concept.

Normally we think of our customers in a persona or scenario or a use case. We personify these made up customers with great ease because we have the voice of the user, by means of; feedback, interview, focus group, the list goes on. Then what is the voice of the app? Who is the app?

This is the mission. Personify the application. Breathe life into an experience in the same way that we breathe life into the users of the application. We do this by building a strong story, with beginning, middle and end. In the telling of that story, we have what I think is missing from 'accessibility design'.

We build our apps to be as visually pleasing and functionally solid as possible. We often focus so hard on this that the accessibility portion becomes afterthought. Something that must be retro fitted or hacked or rushed. I believe that by flipping the order of that we will not only have built a solid, usable, accessible app, but a visually stimulating and emotionally engaging experience.