Projects, Projects…..

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

I’ve been giving a lot of thought lately into how our development team can have an impact on the business. It’s basic common sense when you think it through. We need customer requirements in and quality software out and need to do these as soon as possible for the customer. In the book I just read, it talked about inventory a lot. In software, our inventory is our “work in progress.” It’s sitting on the shelf (in our brains, in a design doc, or in source control) just praying to be finished and then hoping someday it makes it out the door. In our old waterfall days sometimes that took over a year or more to accomplish.
With Scrum, we’re able to keep the work in progress to a minimum, in fact, it’s one of our primary goals. This leads to getting more done and having more to show to show, of value to the product owner, at the end of the sprint. It gives the product owner many chances over the course of the year to decide to ship. On the team I work on right now, we’re about to ship our third release in the last 8 months. Real value, in the customer hands and much closer to when the customer asked for the functionality. This not only is keeping our inventory down, but it’s creating a real relationship with the customer base (field, product management) and a comfort/loyalty in that we can be responsive to the needs of the customer and the business.

I think of each completed user story or epic as another potential business problem solved. Another sale potential that we didn’t have just a sprint ago.

Another big part of the business is making sure you have the right people working on the right things. In Scrum, your teams are always focused on the next top priority item for the business. No more do we throw a list of 100 items and start them all in parallel and come back to the table to see it 10 months later. Hope it all works together as we cross our fingers and do the integration dance.

In an agile team, it builds every day, it demos every 30 days or less, and it’s always ready to ship.

If there are any readers out there, be interested in hearing how you feel Scrum is helping your business plan.

-Corey

I thought I should follow up on my previous post for my two readers. We recently completed a very successful sprint with a very predictable burndown and much higher burn-rate. How, you ask? Tiny stories. We asked that if a story looked like it was going to take more then a third of the sprint, break it up. In most cases we had stories that took less then a week. As a result, we were able to focus on getting these small manageable chunks to “done” throughout the sprint. It kept QA and Doc very engaged from day one and gave the Product Owner and upper management much more confidence in being able to commit to the business on our ship date.

So, here’s the real deal. As with most things in Scrum adoption, it was a mindset problem. The problem before was that we were looking at entire features as stories. We were trying to figure out how to get that feature done within a sprint and making statements like “that could never be done in 30 days”, “why don’t we go to 90 day sprints” or even worse “Let’s have a design sprint, followed by a dev sprint, followed by a test sprint” That would be fine, but only if we want to go back to waterfall in every other way as well.

What we did this sprint is look for logical thin slices of work through a feature. What is the smallest thing we could possibly do to give our product owner and our customers some value in this sprint. Those slices became our stories. Some combination of those stories become a feature. This gives the product owner the chance to be able to decide when he has enough of that feature to be able to ship. Out of the 20 thin slices for feature X, 5 might be mandatory, another 5 might be really nice and another 10 could be completely optional.

Find those slices, and prioritize those, and you will see the impact immediately. Encourage your teams to not just push back on the product owner, but help with the story development to get thin slice stories that make sense to the team.