Six Line fix, huge speed boost to eventmachine
April 29th, 2009 tkadom
just read this on rubyflow. well worth reading the post and grabbing the patch.
Posted in Random | No Comments »
Agile Lego…
April 15th, 2009 tkadom
Last night I attended an Agile Atlanta group meeting because the topic in the meeting announcement included two of my favorite things: Agile and Lego!. I figured any meeting that merges those two into a functional excercise for all the attendees was worth checking out. I can honestly say I was impressed with the presentation that the guys from thoughtworks cooked up for us…
The goal of the meeting was to introduce agile principles to everyone by immersing the group into a technology that most of us were familiar with (LEGO), and having us tackle a project. As a group we broke up into three teams of 4-5 individuals, and we were given some basic agile principles and guidelines to work under. Each group would be building a lego project for their own product owner who had a set of user stories with associated business values for us to estimate and work on. We were challenged to complete three iterations within a 1.5 hour span with time boxed stages for
- estimation - Estimating relative difficulty of the provided user stories
- prioritization - organizing those user stories into development priorities
- sign-up for tasks - choosing tasks for each member of the team
- construction - executing the allocated task
- testing - ensuring that the delivered task met the criterea provided
- retrospective - reflecting on the iteration as a whole as a group.
The group got very little instruction beyond some basic term definitions for those of us who were not as familiar with some of the agile terminology such as user story, backlog, etc. Each group was tracked individually on our velocity, and some of the basic management techniques of determining velocity based on the business value and effort for a given task were briefly outlined for everyone before we got underway.
I was very curious to see how close the lego building analogy would mirror my real world experience. I can only do justice to the lego technique by recounting the iterations as best as possible, but I can honestly say that I was stunned at how many real world challenges our team of 5 mirrored. I think the best way to demonstrate that is to recount each of the iterations in detail.
Iteration 1.
Our group kind of introduced themselves prior to the actual estimation stage. Everyone seemed eager to get started on the construction, and we had a box of lego’s sitting in the middle of the table taunting us with its potential pitfalls and complexity. The legos were ordinary, and it appeared almost random, all the colors were represented, and it looked like any cross section of lego that you might expect if you just pulled up a bucket of lego from a bin. We were given 5 minutes to estimate a set of roughly 10-12 user stories which had associated business value. Our product owner was with the group, but we rarely consulted the product owner due to our fascination with the user stories. After some initial confusion which arose out of a quick brainstorming of how to proceed, we decided to read all the cards aloud to the group before we would estimate them. Once the cards were read we would go around and ask everyone to give their effort value from the provided scale of 1 to 3. We had just finished estimating the first two cards when the stage of the excercise was announced to be closing and that we should move on to signup. Having essentially run out of time we blitzed through the remaining cards with less debate and simply blurted out our value and settled on the group majority. It was on to prioritization…
The task was to build some type of lego animal. The initial set of stories outlined that the animal should have a single color, and that it should be no less than six inches high and no less than four inches long. There would be an enclosure for the animal, and it needed to have a head and a tail. there was another requirement that the animal should be able to move across the table, that it have at least 2 legs, and that it have at least 4 legs, and that it would also have wings. As a group we immediatly identified the single color as a constraint and after glancing through the box of lego’s we determined that Blue was our dominant color and that the animal should therefore be blue. We also thought that we should build the enclosure first and that we should focus on the length and height as our initial objectives. there was only brief interaction with the Product owner, and we had just settled on 9 points worth of work when the phase ended. We were told signup was over and we would now start construction..
a member of the group immediately decided that all of us fumbling through the box for lego parts would be counter productive and dumped the entire contents on the table where they were easy for everyone to reach. At the time I did not give this act much note, but in the end I think this was a key element for our success as a group. We all took a card and went off to work on our points. There was some minor communication between the team members, but it was compartmentalized. I was working on the legs with a partner, so we were making sure we were building to the same scale and using the same proportion. One of us was tasked with an enclosure fence, and the other two worked on the head and the tail. With just a little time left in the iteration the body legs, tail and head were done, and the individual working on the fence asked for assistance in identifying narrow Lego parts to help him finish his work. We all chipped in and helped and were about to finish when the team that was building the head decided to make a change to make the head a little prettier. Under the call of time, this last minute act left the head unattached. On to testing…
the product owner who had been mostly neglected during construction was now presented our delivery. We had a blue horse looking thing with a tail that was missing a head, and we had a fully functional enclosure. The PO went through the cards and noted that while we had built the animal in a single color, we did not check with him on what the color should have been. The color we had chosen was entirely unsatisfactory, and did not meet his corporate colors. He would not be abble to accept the horse in blue. We did manage to meet his expectations on the length, but due to the head being unattached we missed on the head. There was a little discussion with the PO on the necessity of replacing the blue, but we were basically back to the beginning with the color and would need to reconstruct the horse in his corporate colors which were yellow and green. We asked if he would accept any other colors, and he said he might be able to negotiate on red. The phase ended and we were on to the retrospective..
During the retrospective we lamented not having engaged the product owner on the color. We also identified the late change for the head as having cost us points. We had signed up for 9 points and only delivered on 7. The management team went around to each of the groups and we digested the feedback as an entire room. Our initial velocity was 7 with a business value of 1200. (Iteration one result) On to iteration 2…
Iteration 2
At the start of iteration two, a whole set of new requirements was added to the intiial pool of user stories in the form of different color cards. We already knew we would be rebuilding the entire horse, and as a development team we decided that while there was not enough green, there was plenty of yellow and red. There was an additional requirement to add stripes to the animal, which was going to be relatively simple for us since we had to rebuild anyway. We engaged the PO more on how the stripes should be arranged, vertical or horizontal, we asked more questions about the vague user stories, and we were determined not to let him ambush us like he had in interation one. We also decided that we had room for more work and signed up for more points than our initial velocity showed. We did that because we figured we would have had more value delivered if it was not for our last second head change. Assigning efforts was blazingly fast. we used the same technique we used as we were running out of time in iteration one, and there were only cursory glances at the cards to determine the effort.
During prioritization we mostly neglected the PO since we had pinned him down on all the user stories already. There were a couple questions that dealt with dependencies. One of the new features was that we should build a small baby version of the animal, and there was an additional story that this baby version should have a cart. We asked if it would be ok to deliver the cart prior to having made the baby version since the cart was relatively low effort. The response was "absolutely not. No point in having the cart before the horse.. "
In construction our team flowed much better than we had initially. We cross communicated between all the team members. The baby needed to look like the adult, so we were coordinating among each other to make sure that the design was going to meet that expectation. We had nearly finished iteration two when we noticed that the neck on the adult version of the animal was not striped. The head was again removed and stripes were added just as time was called. Again, our animal was left without a head. This time we were not just losing the effort value for the head, but also for the height of the animal and for the baby version matching the parent.
During testing the PO who had been simulating phone calls to his significant other during construction lamented the fact that we delivered the horse in red and yellow. He had signed off on yellow and green, where did red come from? In our regimental approach of looking at the resources for green we assumed that since he was willing to negotiate on red, he would accept red. We were mistaken, but after some convincing about the resource scarcity of green the PO accepted the animal in red. He was not happy with the priority of what we chose to deliver and was unclear about what he was receiving since he was essentially left out of prioritization. While the team communicated better amongst the developers, we still had left the PO guessing about what he was going to be receiving in the iteration, and not engaged him enough during that stage.
The retrospective showed that our team over-committed by signing up for 10 points when we had previously only managed to deliver 7. Our velocity dropped as we only had 4 points accepted during testing. On a positive note, simply attaching the head would have gotten us the full ten. We all felt that we communicated better but that we needed to keep the PO engaged with the project. A member of the group suggested that the PO might be more helpful if we engaged him in the construction. Our velocity had dropped to 4, and we delivered 900 points of business value. On to iteration three…
Iteration 3
Estimation was a snap, and we kept the PO’s attention with a constant banter of questions. We probed into the possibility of him assisting on a task, and his response led us to believe that he might be more of a hinderance than a help since he was not familiar with lego. but he was willing to help if we thought it would be constructive. Our one question was how to estimate the work that we had essentially completed in iteration two and that was now much less effort than we had initially estimated to complete. All we needed to do was attach the head and we would net easy points that we did not get credit for in the previous iteration. we were told not to re-value that effort and so we decided to sign up for 7 points in iteration 3 which included those earlier stories.
In prioritization and sign-up we ran each of the cards by the PO and we decided to go for fewer points than we did in the previous iteration figuring that we could always pick up a story card that we did not sign up for if we finished early. We also agreed as a team that the PO would be more helpful answering questions during the construction phase and that we would need him to stay focused.
In construction we now peppered the PO with every little detail as we were building, to keep him engaged on what we were doing. We finished early enough to attempt to put a roof on the enclosure that we had built, and so we made an attempt at that after clearing it with the PO. (iteration 3 result)
Our animal held up very well during testing, and the PO could not find any points of contention other than that he would disqualify the roof which was a bit hastily attached. The two animals we had built actually looked quite good and i was impressed that within the space that was allocated that our group had managed to achieve all those objectives. Our velocity in the final iteration was 9 with a business value of 2800.
Group retrospective
The iteration 3 retrospective was with the entire room and we had a wonderful cross-section of problems that each team underwent. One of the teams had a rather critical tester, who frequently broke their delivery. They lamented that his harsh testing hand caused them to lose points in their final iteration, but to be fair their animal did appear to be a bit larger than the others and consequently more brittle. The other team seemed to have more communication and confusion issues. All in all, it was a very enlightening experiment and I think all the problems we encountered on our one and a half hour agile experiment have analogues in the real world. We encountered last minute changes, communication gaps, assumption on design, even "it worked when i tested it".
I was also very impressed with the thoughtworks team that put this excercise together. Each of the PO’s challenged the team in the same way that real world PO’s often do. It was suggested by a member of our team that the excercise would have been simpler if the daily standup meeting was also modelled, but due to the time scope I think speaking for even just 5 seconds every minute might have been too disruptive.
It was a great excercise, and if you find the opportunity to participate in this excercise with thoughtworks I highly recommend that you do. There is rarely anything better than first hand experience when learning a subject, and I found this experiment to be very useful in grasping the strength of the agile development methodology.
PS) If you thought that all thoughtworks does is agile and lego, you would be wrong. They also play rocks paper scissors to determine who wins the free giveaway texts… 
Posted in Presentations and screencasts, Random | 2 Comments »
conformity in the workplace…
April 13th, 2009 tkadom
During my irrelevant reading this weekend, I stumbled across a neat experiment about social conformity, and the impact that it can have on the human mind.
Ash’s Conformity Experiment demonstrates how social pressure can cause people to suspend their intelligence and agree with a group even when they know the group is wrong. Essentially these people over-rule themselves when they hear the rest of a peer group give an answer even if they believe the answer is wrong.
How often do we agree with a technical decision because it appears to be the group consensus, and how often to we clear our throat and stick our neck out? Recently I was involved in a technical decision for a client, and I had the unique perspective of being one of three technical decision makers on the subject of adding a third party api to a site we were developing. We came up with a 2-1 split where one other technologist agreed with me and the other one was a fairly strong dissent. Needless to say the dissenting voice owns his own business and did not get where he is today by being shy.
We argued the point on its technical merits and in the end went with the majority decision. I think we could equally have settled on the minority position, but my point is that this type of dissent is actually quite rare in most organizations, and in fact it seems that group think and group design is more often the norm than not. With few exceptions in better development shops, most teams seem to cluster around their stars and agree with them.
I remember working at a large financial institution a few years back, and it seemed like no one ever questioned the work. I was hired as a technology consultant to build financial models based on mortgage data that we were purchasing from Bloomberg. Each time a bloomberg terminal pulled up a security, we paid a transaction fee to Bloomberg. The maddening thing to me was that the institution I worked for owned and published nearly 40% of the data that it bought back from bloomberg. It almost seemed like a no-brainer not to purchase that data back when it was your data to begin with.
The director of the group I worked for instantly saw the opportunity to save the company money. She proposed that we build a data mart for the organization that would post process our own data in the same manner that bloomberg did in the hope of saving the company millions. Her Idea fell flat at the executive level where one of the Vice Presidents voiced his concern that the internal system would be unreliable.
That vice president may have been right. It was a build or buy decision, but what amazed me most then, and still amazes me today is that no one ever questioned the fact that we were buying our own data.
Posted in Presentations and screencasts, Random | No Comments »