Our house from February to June, 2007. I’m trying to save this off as iGoogle is shutting down. I had a Google map widget to with this address to remind me what it was. Decided to store it here, along with the stories of our trip. Glad it came to me to save it here as I never thought I’d be posting in this category again. Oh.. and the embed isn’t working for me in Safari, although it is in Chrome.
What do all of these tales have in common? They started out as an idea that led to a small change. These changes could be implemented easily, cheaply and quickly when there was complete buy-in from everyone that the change was necessary and for the better.
Of course, I didn’t always find myself in a better place. One result had us building a product that became attractive for an acquisition, while our related labor cost did not. Many of us lost our jobs to promote the sale. Another consequence of success was having a senior executive in our organization determine that formally sponsoring Agile was no longer needed. We were invited to look for work in other parts of the organization for awhile, or had to leave the company entirely.
Yet there are times when I did help make things better. The best improvements I’ve been a part of happened gradually, required patience, and added up over time. This helps remind me that I can improve my current situation. I need to help the team see the problem clearly and suggest ways to validate proposed solutions.
If we have a shared perspective of the current situation, then we can agree on how to make it better. We will need to check in frequently, and constantly re-validate the understanding and approach.
A home entertainment provider called me in to facilitate User Story writing followed by release planning. The business unit had not tried either activity before. Leadership had been replaced and the new General Manager and Vice President of Technology decided to invest in the group’s burgeoning Scrum effort.
The organization followed a structured work breakdown approach with tasks functionally derived. People were willing to approach product definition in an Agile way and wanted to experiment with User Stories. We discussed the vertical nature of Stories and that teams were formed orthogonally, based on the architectural stack. A few people pointed out that teams were split by functional area.
The group understood that co-located and dedicated teams fit the Scrum model. Yet voices grew stronger that teams were not set up to autonomously deliver end-to-end features. We talked about the merits of the cross-functional team and folks insisted that the group could not afford another reorganization. One of the Vice Presidents had declared that no “dotted line” relationships could be formed to create virtual teams. She found that such an approach diluted the commitment of individuals and made the process opaque.
We got in too some passionate discussions over the once taboo subject. I continued on with Story writing. We later revisited the team structure with executives prior to release planning. The decision to not allow virtual teams stayed in place. Release planning was put on hold for about two months and then they asked me back to finish. The VP had relented, and kept her job.
When I got back, the business unit could work in a matrixed organizational structure. Virtual Scrum teams had been created without going through another Human Resources led reorganization. We were able to proceed with release planning. The teams were organized where they could implement the features independent from each other yet stay coordinated. This helped increase their production rate while increasing the quality of features as well.
Being an independent contractor is exciting yet somewhat lonely, having to support myself and find every opportunity. I look to constantly improve my craft by finding others to collaborate with and have found those needs met by joining Rally. I now concentrate on improving my coaching and training practice with other coaches. We have a support system around us and I get to work with people who have different strengths and skills.
One of the clients I work with is a networking company. One of the teams I worked with had a difficult time establishing a consistent velocity. Forecasting when a release might be ready for system testing was difficult for this group. This holds back other groups who have to integrate with them at the system level.
Leaving Defects Unsized
The Product Backlog and historical velocity information showed me that the team was not sizing defects. When inquiring why that decision was put in to practice the answer indicated that story points were seen as a measure of value. After all, the team is only credited with the point value of a User Story when the Product Owner has accepted the work as done.
The group sees defects as having no value and show that the original story was not really completed. We discussed if User Stories can be in an accepted state when defects exist for them. We talked about how to apply a formula to recalculate velocity and accommodate for defects. It seemed to the team to be a lot of work with little reward.
When prompted, the team came to the conclusion that defects looked a lot like User Stories and that they could see the relative size of them in comparison to those stories. Someone noted that the expected/actual language of a defect matched up well to acceptance criteria.
We discussed what makes up the size of a story, like how complex it is, and how much uncertainty we have about it. User Story size seemed to us to be correlated to the amount of effort the team needed to invest to finish a story. I admitted to having thought about story points as a value metric and had changed my mind, I now thought that they related closer to the cost of an item.
The team talked about what they believed and concluded that it would be worthwhile to try estimating the size of defects and see what happened. They already met weekly to triage them. Defects were stack ranked with the rest of the Product Backlog. It seemed to the team that it would require minimal effort to size them as well.
The Effect of Sizing Defects
Velocity stabilized with the team keeping all the items including defects in the Product Backlog relatively sized. The total point increase of the Product Backlog confirmed what most people thought; the projected release date was further out than first promised.
The predictable velocity allowed this team to now reserve a certain amount of point capacity to invest in automation and other infrastructure. Preventing defects instead of merely fixing them reduced their cost of feature deployment. This could be seen by them in different ways, such as the reduction of defects backlogged and less time spent in triage.
Understanding velocity showed data to help the team decide if more features had to be cut to meet the date, if the date would have to move, or if more people needed to be hired. In the end the organization acted on all of these options.
After the Agile coaching group shut down at Yahoo!, I decided to take a chance at being an independent coach. I quickly found work with a network management group. The business unit consisted of over 70 people, mostly working in San Jose and Bangalore. The Vice President of the technology group wanted to “burn all the ships”, and hoped this no retreat attitude would help the team convert to Scrum within a quarter. I spent over nine months with the business unit.
Creating the Initial Teams
To begin Scrum, the managers created three large teams along architectural boundaries and HR reporting lines. Each team was around 15-20 people. Immediately, integration issues in the system and between the teams showed themselves. It was the norm that for one feature, at least one person from each of the teams would need to work on it. Stand-ups were taking a long time and I would see the same person in multiples.
Using Story Themes for Organizing Teams
I noticed that the Product Backlog was organized into themes and this gave me an idea. At the next planning meeting I tried an experiment. I wrote down each theme on a separate piece of paper. At Sprint planning I held one up and exclaimed, “If you work primarily in the area of the sign I’m holding, come stand over here.”. As people gathered, I handed them the sign, moved a few paces and held up the next piece of paper with another theme on it, repeating the process.
People collected in groups of two or three and as I got to the end of the list of themes I asked them to look around. Did they see any other groups and/or themes they worked with closely? People shuffled around a little and before long, we had six teams of around eight to ten people each.
There was one holdout group and once that was settled, we had a few people that still hadn’t decided where they belonged. Finding them a place required a little management intervention. I then asked each team to think of a name, so that we could continue Sprint planning using the new names for our new teams.
I asked the teams if we could try this experiment for a Sprint and if necessary, people could switch teams in the next Sprint. A balance was reached between steady, persistent teams who felt comfortable in the code, and the capability to move people around to share knowledge.
Benefits of the Team Restructuring
Within a quarter continuous integration was in place. Another quarter after that and each check-in produced a disk image. The image included the operating system, all necessary third party applications, and packaged code the team built, installed on an appliance, which was then rebooted. Within another quarter all tests passed with each build and unit tests covered over 90% of the code base.Художник