My team is currently in the throws of release planning for our next release. We’re starting to get into the stories for the first sprint now and it’s hard to divorce ourselves from the whole nut. Every time someone has an idea for a small slice, the “but this” and “but that” starts up from the rest of the team. The main issue is while their concerns are valid, they have nothing to do with the success of Sprint 1. That’s the mindset we need to be in at this phase. While it’s important not to code ourselves into a corner, it’s also important for us to not try to do everything at once. Finding that balance is the trick.

An important quote from Ken Schwaber comes in handy in cases like this: “65% of all software functionality is never used”  Think about that. For what seems like good reason, we tend to be driven to all edge cases in existence. We write what we think our customers are going to use, not what we know they want.  Re-focusing in on delivering something that the customer can use and comment on should give us some significant payback.  This is the first release where we are dedicated to getting a build out to our customers at the end of each sprint. I think that pressure will be a good one. Time will tell.

The key positive turning point I saw in today’s meetings is we are starting to have more Agile champions then in past releases. These are mostly coming out of Doc and QA as these are the roles that have been most effected in a positive way by the Scrum process. In past releases we weren’t even having the agile conversations this early on, but now it seems to be a priority of some team members and that’s more powerful then management forcefeed any day.

All in all, a good day in agile land. Hoping the conversations continue.

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!!

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.

Lately we’ve morphed from the traditional Scrum model into a sort of storytelling standup. Instead of asking the three questions to each individual, we do it for each story that we have taken into the sprint. This leads to an extreme focus on the stories themselves. It has better highlighted dependencies between team members and on other teams. It’s helped me as ScrumMaster to understand better where I could get involved to grease the wheels and help things happen. As for the teams, they feel a little less micro-managed (never the intent, but a common misconception) now that we are reporting on stories, rather then on what I did, will do.

The jury is still out on whether or not it is a more effective means of communication in that 15 minutes, but for the most part it seems to be producing better results. I feel that what I gain as ScrumMaster in helping stories move along, I lose in knowing where the external interference is occurring. I try to watch for where stories aren’t starting or being reported on for multiple days and be a little more investigative then I had to be before.

Anyone have other processes? Success or failures with either of these models?

-Corey Jackson

#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

• 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 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

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.

We heard from all the teams recently in Sprint Retrospectives and while some believed the small chunks were a hindrance to real productivity and doing the right thing (design phase – I’ll talk about this in another post soon), others felt that the small chunks were easy to focus on and understand. I think I will take focus and understanding that ends in working software instead of the entire team still being stuck in design review meetings at the end of 30 days.

The lesson here is keep the deliverables very small and you will succeed in both creating something of value and high quality as well as something the whole team (including traditional doc and qa resources) completely understands.

Scrumfully yours,

Corey

There were no going away lunches this week…

So what do we have to thank for all of this….. Scrum.

For those of you not familiar with Scrum, it is an agile methodology where you develop increments of potentially releasable software in 30-day sprints.  At the end of the 30 days you have a sprint review where the team presents on what they did.

I walked around on the morning of our first Sprint review and I couldn’t believe the energy I felt in the halls. People were in each other’s offices communicating. People were running around making sure everyone was on the same page with what they were about to present. For the first time in a long time, it felt like everyone cared about what they were doing. There was a definite sense of accomplishment and a much more connected organization.

From a management perspective, I am overjoyed at hearing from people I never got to interact with on a day to day basis in our old waterfall model. Often people would hear from me, only if they had an outstanding bug that was holding ship. Now, it is daily communication and targeted as I am actively making sure nothing is in their way of moving forward with what they are working on. We have seen new leaders emerge and take ownership of key initiatives. This is probably what excites me most. We watched a traditional QA lead demo the software that was developed during the sprint. There was no show and tell, training, or hand off. It was all shared knowledge the qa rep had gained during the course of the Sprint.

One of the key fears we typically run into at work is the roadmap being non-existent or not clear enough to present much of a future for the team. There is a lot more visibility into what is next for the product line and no question as to the amount of important, innovative work this team will be working on well into the next few years due to the product backlog.

We have some key challenges to overcome in the next few sprints and have yet to prove whether or not we can actually ship this stuff, but it certainly has me excited.

-Corey