This blog entry is the first in a series for people who are new to Agile Coaching.
My son was quite a large baby, and grew quickly after he was born. He was quite strong, holding his head up early, rolling over early, and attempting to wear out his Jolly Jumper a good month before he was supposed to be doing that sort of thing. Of course I was justifiably proud, being the father of an overachiever!
When he got to about 6 months, though, he showed no interest in crawling. He had no trouble rolling onto his stomach and getting up on his arms, but he didn't seem to be compelled to actually go anywhere. Apparently he knew that he had people for that whole movement thing.
One day he and I were playing with some blocks. I would make a tower, and my son delighted in knocking it down. I mean he really liked knocking my creations down!
So, I built another tower destined for destruction but I built it just out of his reach. My son was not pleased. He didn't exactly cry, and I'm not fluent in 'baby', but I don't believe that what he said is repeatable in mixed company.
What he also did was move himself, trying to reach the tower. At first he pushed too much with his arms and went backwards, initiating another stream of baby talk profanity. He persisted, though, and within a few minutes wailed away upon my tower, reducing it to a pile of BPA-free rubble. We continued this for a good 30 minutes, and my son was now fully mobile!!
Coaching Point
Don't be afraid to challenge teams by moving the tower on them. We don't often improve ourselves spontaneously - there must be some stimulus to get us moving.
For example, teams new to Agile are often quite wary of any iteration length shorter than 6 months! If a team starts initially with 3 week iterations, challenge them at some point to move to 2 weeks. Feedback is a critical aspect of Agile, and you want to maximize the frequency that it can be obtained. So, the shorter the iteration length, i.e. the opportunities for feedback, the better. When you propose this, you may encounter the equivalent of my son's griping that I put the tower out of reach. However the benefits of making them stretch, of making them ratchet up their intensity such that meaningful increments of value are delivered over a shorter period of time, are well worth the foul language. Any bottlenecks in the process that may have quietly existed in 3 week iterations will no longer be quiet at 2 weeks and will have to be addressed.
Another common area that teams could use the 'out of reach tower' concept is in automating their environment. Builds, testing and deployment are all areas where automation can be applied to simplify the work that the team must do. When someone tells you that something can't be automated, ask if they've tried. If not, ask why they believe it can't be automated. Challenge them to prove it by using a timeboxed experiment. It's quite likely that another team somewhere has encountered the same problem, so challenge the team to find out if there are any existing solutions out there. In short, challenge them!
A word of caution, though. After my son learned to crawl he immediately, and I do mean immediately, started exercising his new freedom by going places that he shouldn't (and I thought we had child-proofed the house!). The team still needs to deliver work that has been deemed valuable by the Product Owner, and thus they can't spend all their time working on these challenges. These types of technical items must be communicated so that the product owner is aware of them. They do provide indirect business value and should be done, but they may not be the top priority at the time. Another approach is to address these technical infrastructure items during Iteration 0.
My son was quite a large baby, and grew quickly after he was born. He was quite strong, holding his head up early, rolling over early, and attempting to wear out his Jolly Jumper a good month before he was supposed to be doing that sort of thing. Of course I was justifiably proud, being the father of an overachiever!
When he got to about 6 months, though, he showed no interest in crawling. He had no trouble rolling onto his stomach and getting up on his arms, but he didn't seem to be compelled to actually go anywhere. Apparently he knew that he had people for that whole movement thing.
One day he and I were playing with some blocks. I would make a tower, and my son delighted in knocking it down. I mean he really liked knocking my creations down!
So, I built another tower destined for destruction but I built it just out of his reach. My son was not pleased. He didn't exactly cry, and I'm not fluent in 'baby', but I don't believe that what he said is repeatable in mixed company.
What he also did was move himself, trying to reach the tower. At first he pushed too much with his arms and went backwards, initiating another stream of baby talk profanity. He persisted, though, and within a few minutes wailed away upon my tower, reducing it to a pile of BPA-free rubble. We continued this for a good 30 minutes, and my son was now fully mobile!!
Coaching Point
Don't be afraid to challenge teams by moving the tower on them. We don't often improve ourselves spontaneously - there must be some stimulus to get us moving.
For example, teams new to Agile are often quite wary of any iteration length shorter than 6 months! If a team starts initially with 3 week iterations, challenge them at some point to move to 2 weeks. Feedback is a critical aspect of Agile, and you want to maximize the frequency that it can be obtained. So, the shorter the iteration length, i.e. the opportunities for feedback, the better. When you propose this, you may encounter the equivalent of my son's griping that I put the tower out of reach. However the benefits of making them stretch, of making them ratchet up their intensity such that meaningful increments of value are delivered over a shorter period of time, are well worth the foul language. Any bottlenecks in the process that may have quietly existed in 3 week iterations will no longer be quiet at 2 weeks and will have to be addressed.
Another common area that teams could use the 'out of reach tower' concept is in automating their environment. Builds, testing and deployment are all areas where automation can be applied to simplify the work that the team must do. When someone tells you that something can't be automated, ask if they've tried. If not, ask why they believe it can't be automated. Challenge them to prove it by using a timeboxed experiment. It's quite likely that another team somewhere has encountered the same problem, so challenge the team to find out if there are any existing solutions out there. In short, challenge them!
A word of caution, though. After my son learned to crawl he immediately, and I do mean immediately, started exercising his new freedom by going places that he shouldn't (and I thought we had child-proofed the house!). The team still needs to deliver work that has been deemed valuable by the Product Owner, and thus they can't spend all their time working on these challenges. These types of technical items must be communicated so that the product owner is aware of them. They do provide indirect business value and should be done, but they may not be the top priority at the time. Another approach is to address these technical infrastructure items during Iteration 0.
Comments