I didn’t know I’d be a Journey Fan…

As I sit here listening to Pandora, I’ve realized that all channels lead me to Journey. I guess I was meant to be a Journey fan even though I didn’t know that when Journey was famous. Maybe I was too young to appreciate it. Maybe my tastes have changed. In any case, my point is, we never really know what we’re going to want in the future. Similarly our customers in the first half of 2009 are going to have different likes and dislikes then they have right now.

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.

Design

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

Between projects

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.

The Daily Stand(sit)Up

Sorry, but does anyone really force there teams to stand?  We get done in 10-15 minutes, so I don’t really feel the necessity to make everyone’s feet hurt. Is starting a blog post with a tangent a bad sign? Ok, so on to the point. The Daily standup.

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

Creating Effective Scrum Teams

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

It’s Not that Simple….or Is It?

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

Show your Business Acumen with Scrum

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

It’s all in the mindset, govenor!

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.

Small Manageable Deliverables are great, no they stink, no they’re great….

In the Scrum methodology you have 30 calendar days to a sprint (usually). This means 22 working days. We assume a 30% maintenance burden which breaks down into fixing bugs on shipping product, helping Product Owner with next sprint, and other distractions. That leaves about 16 days for each team member. Of this 16 days, some team members will have time off and other distractions leaving you with an average of 10-12 days per team member on any given sprint.

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

Scrum Da Dum Dum

 So this past week has been an eye opener for sure. As one collegue pointed out, it almost made him teary-eyed with joy. Employees were engaged. The office felt like it had a buzz for the first time in two years.

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