Certified SCRUM Master Trainning :: Day 2

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

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

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

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

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

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

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.