Constantly Changing -

Ten Tales of Positive Change – Conclusion and Acknowledgements

April 16, 2012 No comments

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.

Acknowledgments

I would like to thank Erica Young, Ken Clyne, Ronica Roth, Ann Konkler, Bob Gower, Jeff Patton and Ben Carey for their comments, advice, and encouragement.

Agile, Ten Tales

Allowing for Cross-Functional Teams

April 13, 2012 No comments

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.

Agile, Management, Scrum, Software engineering, Software project management, Team, Ten Tales, User Stories

Finding Predictability in the Velocity

April 12, 2012 No comments

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.

Defect management, Estimation, independent contractor, Scrum, Story points, Team, Ten Tales, User Stories

Figuring Out How to Construct Teams

March 15, 2012 No comments

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.Художник

independent coach, Scrum, Sprint, Team, Ten Tales

Gauging the Rate of Progress

March 6, 2012 No comments

An interesting pattern was revealed to me. I noticed it in my embedded team and with other teams who asked for help. Product Backlogs were not being estimated.

Teams were not estimating in points, days, nor even time. It is unclear what led to this lack of discipline. A consequence of teams not being able to say when something might be done resulted in other people setting deadlines for those teams.

Playing the Team Estimation Game

Demand for coaching was high and we were always being called in to situations. In looking around if I found a backlog with hundreds of items and no estimates, I would try to schedule a session for playing the Team Estimation Game. To play the game I would print out the Product Backlog first and then spend time cutting out each item. I would then place 8.5 by 11 paper around a table with the planning poker numbers on them.

Handing out portions of the backlog to each team member, we would start the session by silently placing items into the corresponding point bucket. The bigger the bucket, the higher the number on a piece of paper taped to the table. Team members were free to move items from one bucket to another. The team kept moving some items around and we noted these for estimating with planning poker later.

Consequences of the Game

The intent of playing team estimation is to quickly size an entire backlog. These teams went through over one hundred items in less than an hour. The technique is not as thorough as planning poker. Done silently, team estimation doesn’t invite the conversation found in planning poker. It does allow for a baseline sizing of the backlog. Team estimation can establish an historical base line velocity for a team if they estimate finished work as well.

Consensus is established quickly on the really big items and on the volatile items that need refining before they are ready for Sprint planning. It helps a team gauge the rate of progress and helps everyone conclude when to expect work to be done instead of forcing dates on people.

Estimation, Planning poker, Scrum, Sprint, Story points, Team, Ten Tales, User Stories

Dealing With an Overwhelming Amount of Work

February 28, 2012 No comments

I located a job as an Agile Coach working at Yahoo! headquarters in Sunnyvale, CA. I worked with a group of internal coaches, offering both training and coaching for the nearly 500 teams that were experimenting with the Scrum framework inside the organization. My directive there was to observe teams in action and offer help when asked.

Observing Team Behavior

Pretty soon I was invited by a Product Owner to observe his team’s stand-up. This team sensed that something wasn’t right with their Scrum implementation and he was seeking advice. They had also recently lost their ScrumMaster and people were wondering what might happen to replace him.

Walking through the buildings from where I worked, I arrived a little early to the meeting and soon about 20 people filled the conference room. When everyone got there we quickly went around the room and everyone said something about what they were doing.

The tone most people used sounded like a status report. I couldn’t detect a common thread woven through what people talked about. I looked around and did not see a Sprint task board anywhere. The meeting lasted for only 15 minutes and then everyone immediately exited the room.

Investigating the Situation

Asking around afterwards I found that the information stored electronically was out of date, having been maintained by the ScrumMaster who had left. Nobody was really thrilled with the electronic tool, something swiftly put together internally to support one of the first Scrum teams. Although many teams used the free tool it was no longer supported nor maintained by anyone.

The Product Owner, a couple of managers, two leads and myself discussed an approach. We concluded that it would be best for me to embed as ScrumMaster for a while, perhaps a couple Sprints or more. This would allow me close inspection of what was going on. It would give the team some time to find a replacement and for me to hopefully work with that person.

Observing a couple more stand-ups I found it very difficult to discern what the expected outcome was of all this work that the team was doing. I spoke with people about how many tasks they currently worked on, and what those tasks were.

Most people worked on more than one Product Backlog item at a time. Some people worked on several items concurrently. Nothing had been deployed to production for over a quarter now. There were around 600 open bugs, and technical debt mounted with more being opened than closed.

Exposing the Work

After discovering all of this, I arrived at a stand-up with a pile of sticky notes. I passed them out and asked people to write down what they were working on, one task per sticky note, and to put how many hours remained. I then asked people to initial their sticky notes and place them on the white board. We clustered tasks together and wrote down what Product Backlog Items they belonged to. The resulting sticky notes covered two 4’x8’ whiteboards on one wall and one more board on the opposite side of the room.

There was a shared concern that the team worked on too many items. Seeing it hanging on the wall all around them convinced everyone. The team decided not to take on any more work until the current work in progress diminished significantly. The Product Owner prioritized the list and provided focus for the team as most people had tasks for more than one item.

The Effect of Work Limits

We calculated how many items finished weekly. Looking at this number along with team size helped us establish a limit for how many items could be in flight at any time. Before long, the team finished one Product Backlog Item every two to three days and deployed two to three features per week. Hours were no longer tracked. The bug count went from close to 600 to several dozen and eventually down to zero bugs open by the end of a Sprint.

The highly visible task board continued to be modified by us and now fit on a wheeled 3’x5’whiteboard and stood where people worked. The Product Owner was happy with what he saw and I caught him once hugging the board. Having the work visible resulted in better preparation and understanding by the team of the flow of features desired.

Agile coach, Scrum, Sprint, Team, Ten Tales, Yahoo!

Getting healthy

February 21, 2012 No comments

Always hurting from something

During my first rolfing sessions, I ask my therapist if I can help her set up her table. She turns down the offer, which is relieving. My back hurts and I move with care and intention, trying not to fire off the twitch muscles. After my 6th session, I’ll learn how light it is when she leaves me the table and goes on retreat. Moving it around really is no trouble, as she insists.

My wife believes the back pain is from a mis-adjustment I received in yoga class. I agree and think that shooting down a 5′ wave that crashed on my back also contributed. It’s part of a collection of aggravations from the misadventures in snowboarding, biking, hiking, dancing, and even just exerting some. Sustaining bodily damage and persistent injuries puts me in constant recovery. My intention is to build up my strength, durability and resiliency for longevity. What happened in yoga class is ironic. Even as I seek out a healthy platform, I’m injured and slowed down.

happy in the city

My lower back bulges out. The vertebrae are sore to the touch. I behave like a timid swimmer, testing the water with a brush of a big toe across the surface before easing in. It concerns me, and my wife. For my last birthday, she gave me the rolfing 10-series. She offers this as help on my path of self-healing, so that I may live in comfort.

Let’s take the yoga intensive

We’re coming home from one of our walks, talking about the rolfing sessions. Why not use it to establish a health regimen? We both need it. Among our current options is an inneryoga intensive. We decide to sign up when we get home, where we learn that it started. That day.

Inclined to give up we call the studio instead. The class is on break. The person who answers asks Dina, the instructor, if we can join tomorrow. There’s plenty of room for us. After signing us up, he convinces us to come before the break ends.

Arriving late to class

The entrance is awkward. They’ve started. It’s a classic move for us. About as responsible and organized as a pub crawl, we lay out plans in advance which become difficult to follow. Yet we keep staggering on, barely able to keep ourselves together. We can be as tactful as a marauding party, occasionally making a scene. I’m afraid that’s happening during our entrance for a six-month long journey with these folks.

Invited in we find places to sit in the circle, and make ourselves comfortable. We go over the handouts for the class as it unfolds. We start with the inneryoga mandala and its balance of kindness, breath and awareness. The borders of it are the physical, emotional, and subtle bodies. In the center is the word ease and I’ve written underneath it the word flow.

We draw representations of our highest, and lowest, selves. We’re invited to accept the low-self without judgement, using the expression of the higher self to embrace its conditions and habits.

Developing our daily practice

We list out poses for our daily practice. I’ve chosen 36 breaths, main central, and sphinx pose to start.

Results of our gratitude practice

We write down what inspires us, and I have:

hiking around and being outside
reading, writing and learning
trying something new and novel
having intelligent conversation

I choose to go on short walks to look at the city, thinking about the view from a park near our home. Erica suggests that after we finish our poses, we write down a word or phrase of gratitude that comes to us in the moment. This rounds out the elements of a daily practice to support our higher selves.

Doing our homework

The handout states that we should contact Dina to make up absences, which I do. I hope to make up some for how we started out. She tells us to write down our emotional, physical, mental states and energy level each day for a couple of weeks. At the end of it, she’d like a little report of what we’ve noticed.

When I pay attention, little itches present themselves in my physical body. My emotional state is distracted and my mental state is not clear. My energy levels are usually low. Is it because I write these things down after our gratitude practice, right before bed?

Changes from yoga and rolfing

I’m starting to notice other subtle changes. My daily walks has me developing the ability to scan the whole landscape with my eyes. Instead of leaping from one object to another, I continually perceive everything as I look around. It’s like a rolling point of contact, only with my eyes.

I’m also incorporating lessons from my rolfer in to my days. She has me thinking about how the psoas controls my posture. My current exercise is to walk backwards and when I turn around, to incorporate those feelings in to my walk. It causes me to lift my toes, step on the heel, and push off the toes to propel myself forward.

Rolfing and yoga has me feeling mostly better. Yoga has aggravated an injury to my knee. I am being kind and patient with it and wear a brace for protection and support. Overall, the results have me feeling happy and calm. It’s improving my relationship with my wife, and work is more pleasant. Next weekend is the second one in our inneryoga intensive, and I’m ready for the next step in the journey to getting healthy.

Daily practice, Dina Amsterdam, Health, Rolfing, Yoga

Admitting to the Real Date

February 13, 2012 No comments

I agree We established a trusting relationship at vianet with our customer. We invited them to each Sprint review and planning ceremonies. They checked out and deployed our code from our servers in to their environment.

Negotiating the Date

It was the end of fall and our customer said they needed the work finished by the start of spring. Everyone wanted some buffer in case something delayed deployment and we agreed to finish development by the middle of winter. This date was written in to the contract drawn up by lawyers and signed by both sides. The rate that we were now building the product at had our team estimating we would have something out after the date in the contract.

Inspecting Progress

Our customer attended reviews, inspected progress by checking out and building the latest code at any time, and saw our responsiveness from requests in planning. It was because of this interaction that when we told them, they understood that we had more work to do than could be delivered by the contract date. Everyone believed the data they were seeing.

Working Closer with Our Customer

The customer then upped our trust in them. They told us that the intention was to go live in the early summer. Our velocity and Product Backlog size showed that we would finish most of the work by the end of spring. The customer worked closer with us, providing frequent feedback on the direction.

We worked together deciding on what to build next. People from both companies traveled between the two sites. Our Product Owner seemed calmer. Everyone understood clearly what to do and we launched within the window predicted. The customer eventually acquired vianet.

Agile, Contract, Management, Sprint, Ten Tales, Velocity

Reassigning Points to Validate Estimation

February 3, 2012 No comments

Keeping a Good Agile Estimation Practice

As part of our Scrum practice at vianet, we spent time as a team tending to the Product Backlog. We played planning poker and kept all our stories sized. We knew the entire size of the Product Backlog. Every Sprint we looked ahead and refined some User Stories.

Our velocity was stable and we could predict what User Stories would fit in a Sprint. The total size of the Product Backlog and the number of Sprints left projected that we would not hit the date promised to the customer.

Verifying the Estimates

The Product Owner started to question our estimates. He neither questioned the technique itself nor the merits of relatively sizing items, just the numbers we produced from this estimation technique.

We decided to spend a day with the Product Owner looking over the backlog. We looked at some of the work we’d finished to help calibrate sizes, and triangulated it with the items not yet started. Some of our User Story estimates changed. We sliced some of our User Stories thinner and even removed a couple. The Product Owner was convinced that our estimates were sound.

When we finished and totaled up the points, it was nearly the same as the beginning number. We learned that keeping the backlog sized is priceless and that reassigning points is useless. The total size of the Product Backlog had not moved a significant amount from all of our work, although we now were intimately familiar with it.

Time for a Talk

This didn’t help the fact that we all recognized that we needed to have a tough discussion with the customer. We couldn’t deliver on the date we promised with the features they wanted.Икони на светци

Agile, Planning poker, Product Backlog, Scrum, Sprint, Story points, Ten Tales, User Stories

Keeping Progress High and Questions Low

February 1, 2012 No comments

Everyone Wants to Know Status

Vianet established a cadence around Scrum and soon our customer, stakeholders, executives and others would ask how the current Sprint was going. The people asking questions numbered more than we had on the team. The questioning increased as a Sprint neared its end.

I asked if people could hold off with the questions until the end of the Sprint. It had become too much of a distraction for the team.

Designing Good Retrospectives

A friend suggested that I read “Agile Retrospectives” by Esther Derby and Diana Larsen. The book was recommended to me to help weave activities together to get the most out of a retrospective. In reading it I noticed that the effect could be amplified by tying retrospectives together for another level of build-up, from one retrospective to the next.

It’s suggested by most Agile Coaches to only put in a couple of hours to prep for the Sprint review. I would invest up to three hours preparing for a good Sprint retrospective and another hour and a half to facilitate. I spent some more time writing up summary notes to help us remember decisions, and to help me design the next Sprint’s retrospective.

Communicating Results

At the end of the Sprint we would have our review and take feedback from our customer and others. When asked how we thought the Sprint went we could usually point out that we had once again met our commitment and if not, a quick explanation why not.

Further comments from the team, we insisted, would have to wait until we could have our retrospective. We decided in our retrospective what information we wanted to share out, which was mostly conclusions and next steps.

Better Interactions

Our team constantly improved from how we practiced retrospectives and we made a habit of relating afterwards how we felt about the Sprint. While we included feedback from Sprint review into our planning, we would also explain our plan for improvement that came out of the retrospective.

The questions dissipated and we could work without as much distraction. This allowed us to meet our commitment and celebrate it in the Sprint review.???????? ?? ?????

Agile, Diana Larsen, Esther Derby, Management, Retrospective, Scrum, Sprint, Ten Tales

Page 1 of 12
1
2
3
4
...
12
Next

Recent Tweets

Tag Cloud

Check it out

For February, 2012