Projects, Projects…..

My new iPhone blows my mind in so many ways. There is so much thought given to the activity of the user as well as what else might occur while doing those activities. Listening to music, working on an application? Phone rings No problem, talk through your earbids and well return you to the music and app when you are done.

The keyboard morphs into all sorts of configurations based on the app.. Wouldn’t it be great if your computer keyboard could do that. Hint hint , MacBook touch.

I enjoy holding and using this device leagues over the overheating laptop in my lap.

It didn’t come with a manual. No instructions. Just play. This led to delight as I not only found new things but in the comfort of not having to refer to a manual for troubleshooting. All software should be written with this as a goal.

That’s all for now. My train is about to pull in to Lynn.

Fanboy to the grave!!

I’m sitting here writing this from my new iPhone for a few reasons. 1. I’m addicted to this thing. 2.I haven’t posted in a while. 3. I’m a little bored.

We are currently in between projects and we are horrible at keeping the wheels in motion in between releases. I’m thinking it’s not such a bad thing given how hard we work the other eleven months but the scrummaster in me wants to get that next feature out as soon as possible.

Any suggestions out there for how to find the time in project a to get ready for project b so as to avoid this lag.

We are certainly not experts at this one, but I think we’ve improved greatly over the past year.

#1 - Do not model your scrum teams after your organizational structure

When we started out, we modeled our teams almost exactly to our org chart. We took managers and their teams and set them off on their component pieces of a larger whole. As a result we ended up with 5 teams all working on their individual component pieces of the same user story. This leads to a great deal of dependencies between teams and thus to a flood of impediments. We took a step back after our first release and reorganized our teams, but NOT our org chart. This is important for many reasons which I will go into later. We decided to put teams together that would have the skills necessary to implement whole features with very minor dependencies on other teams. This cleared up a lot of our impediments between teams and helped teams plan their sprints better with all members on the same team.

#2 - User Stories Need to Be Less Then a Third of A Sprint

Or smaller… We had a lot of stories listed in our backlog that were larger then a sprint or in some cases, larger the two sprints. I talked about this a little in my mindset posting a month back, but I wanted to revisit it here in the context of effective teams. The story building should not be done in a silo. The product owner needs to create the high level story and help with the breakdown into the smaller stories that will make up the whole. The team should help in developing the smallest slices possible through the entire feature from end to end. With the right team makeup, and nice small stories (that the team helped develop) you will see instant increase in understanding what is being asked of them and that translates to more velocity.

#3 Managers as Product Owner Advocates

This is a personal opinion and some could disagree with this. To truly have self-empowered teams, you need to keep the managers out of the teams from an individual contributor standpoint. They also should not be the ScrumMaster for obvious reasons. Where we have found them to be effective is as “Product Owner Advocates” that help the Product Owner with prioritization, story development, and answering day to day questions from the team members. Even in this role, you need to be careful that the team isn’t just following whatever the manager says to do (while the sprint is in progress). The most important reason to keep the manager as oversight over components or logical divisions is for skill development and mentoring. The manager’s role as trainer/coach is one to be embraced strongly. It shows the employee an interest from their manager in their career, skillset and growth and less of a focus on micromanagement of their day to day work.

That’s all I got for now. We’re still learning and growing. Not everyone is happy, but we’re getting closer. Would love to hear from others on ideas here. What’s working out there?

-Corey

So I recently read a very good book on simplicity, The Laws of Simplicity by John Maeda. While I was reading, I twittered some short summaries of what I was learning. Some of it was obvious, some of it not so obvious. I’ll repost the twitters here and go into a little more detail on some of the finer points the book had to make. I’m looking forward to the second book in the series called “The Value of Simplicity” which is apparently going to focus a bit more on the business side.

• Reading the laws of simplicity a good book for our team to read 06:40 PM April 23, 2008 from txt
• Chapter 1 - reduce provide something small that will be sure to delight and surprise with its function and quality 06:45 PM April 23, 2008 from txt
• Chapter 2- in organizing function find areas to integrate together into one control ajax gives us great power here 07:04 PM April 23, 2008 from txt
• Back to Simplicity Ch. 3 - Reduce time where you can. Cant? Hide it w/ distractions. Maintain a flow of time. No one likes a stopped clock. 10:22 AM April 24, 2008 from TwitterFox
• Ch. 4 - Learn - Think of kids learning to walk. Gradual, repetitive leading to motivated, independent with a reward of personal growth.
• Chapter 5 difference - finding a rhythm of simplicity and complexity that keeps a users interest
• Ch six context- resist using all whitespace think of google search and how the primary function pops
• Ch 7 Emotion - give everything you develop life and it’s function will have importance. This is a bit crunchy, but I think it makes sense.
• Ch 8 Trust - “In simplicity we trust” something simple, does what it says, earns trust. Complexity scares us.
• Ch 8 trust (cont.) - Undo button gives comfort to someone but is somewhat of a fake trust mechanism. undo power can lead to “I don’t care”
• Ch 8 trust (cont.) - Is UNDO there because you don’t even trust what you’ve developed, or is it there for a real customer use. 06:39 PM April 24, 2008 from web
• Ch 9 Failure - Not everything can be simplified. Recognize failure to simplify in the beauty of the complexity - think of a flower. 06:47 PM April 24, 2008
• Ch 10 - Make the complex, simpler by moving it away - SaaS : simplifying what I need locally and doing the hard stuff far far away. 06:53 PM April 24, 2008
• Ok, I’m done with the book so no more boring tidbits. I plan on expanding on the little summaries in a blog post soon on cjproject. 07:05 PM April 24, 2008 from web

Chapter 1 was very interesting and a good hook. I liked the idea of something small almost demanding a feeling of pity. You want to hold it, care for it and soon you are completely delighted in all that it can do. The example he kept going back to was the iPod. So little….. so simple….. so frail??? ….. nope, this thing is AWESOME! Wouldn’t we all like to strive for our users to have that experience.

One of the ways to delight is to hide functionality until it’s needed. Let the user gradually discover it. Think of common video game tutorials, or one great example he used in his book was learning to walk. It doesn’t need to happen all at once. As a matter of fact it would be downright insane to expect it all to happen at once, so don’t throw it all up on the screen the first time the user visits.

I liked the ideas in Chapter 5 because it relates to my favorite acting lesson. In Chapter 5 it talked about difference and it’s importance. You can’t have simplicity without complexity. On stage, I tell my actors to look for opposites in every scene. Add complexity to the character and the decisions and actions the character takes will inspire more interest from your audience. This is hard to translate to software UI, but I think about it as providing someone with a simple view that has a lot of complexity. Think of how much is in a simple AJAX UI these days with the ability to leave the screen in place while performing all sorts of hidden actions to uncover new functionality within the control.

I’ll write more later. Need to head out to catch the 6:45 home. Hope this enlightens. Would love to hear your thoughts.

-Corey