Projects, 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.

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

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

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.

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

 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

As I start to think about implementing Scrum or some other Agile process into our development world, I get scared of the reaction. Everything I’ve read and listened to on managing change in an organization says you have to pay attention to two groups of people, the top performers and the slackers.

Let’s start with the slackers because they are the least interesting. An agile process where you either contribute or get lost, will bubble up the slackers to the forefront right away. These people will have nothing to say at the daily stand-ups. They will consistently be stuck on the same mundane details, and will eventually feel so overwhelmed they will look elsewhere. While this is good, in a budget crunch where I can’t fill that req, the slackers work might be better then no work at all. I haven’t quite figured out if no developer is better then a developer who’s kind of in the way.

Now, how about the top performers. They are quite often the most invested in existing processes. They are quite often the ones most resistant to change. From my standpoint, I am going to get them involved in defining the new methodology and hopefully get them to become agilists along with me. It’s important to keep the top performers happy and engaged in what is going on with their day to day processes and activities.

Thoughts, my non-readers?

I was reading Agile Software Development with Scrum last night and I couldn’t believe the common sense it made me realize. Sometimes you need a good swift roundhouse kick to the face before you get it. We in software development are always talking about “if anything can go wrong, it will” It’s completely unpredictable. Yet, we constantly try to apply these waterfall models where we design, design, design, define work breakdowns of defined inputs, expecting for the right outputs at the right times, and that is NEVER who it turns out.

We try to apply a predictable process to an unpredictable deliverable which is ever changing in requirements.

We must as software engineers adopt a more agile model just to deal with the very nature of what we are building.

Thoughts? I know no one reads this, but surprise me.

Listening to a podcast with Jared Richardson the author of “Ship It!” I actually own this book but have not read it yet. The biggest concepts he seems to focus on are continuous integration and test automation.  Knowing the state of your project at any given state is key and with those two things working, you will always know.

Parts of this conversation seem to be focused on Scrum principles. Daily meetings where you look at what you did today, what you will do tomorrow and what is standing in your way. The feature lists which are prioritized by a team lead and are the only things you are allowed to work on during any given iteration, sprint, etc.

All of this is starting to make real sense to me. I have not heard any anti-agilists. Just people who are resistant to change. We have our challenges in adapting it here. Should be interesting. More to come on this.