braz.me

Mom, Whit, and Emma, early 2004. The dementia had been taking away the Mom I knew and loved for a number of years, and her body finally let her go find some rest yesterday morning. She loved Whit and I more than anything, and showed us through sacrifice and hard work every day of her life. She loved her students, loved teaching, hated the politics of teaching, and found joy in helping people who never finished school find a chance to get their diplomas and start a new chapter in their lives. She loved her Pooh-dog, her Grandkids, and her Mom. She finally gets to go be with her Mom and Dad, and her Pooh-dog. We'll be having a visitation at Whitten Monelison on Friday night, from 6:00 – 7:30, and a graveside service at Fort Hill on Saturday at 10:00. In lieu of flowers, please consider making a donation instead in Mom's name to the Amherst Humane Society. It's what she'd want.

: http://flic.kr/p/zG3xqt

: A baby praying mantis on my car door the other morning. http://flic.kr/p/zAmWNG

So, let me ask you this, true believers: if you had one thing about Agile you wanted to know more about, what would it be?

Ship it. Get it out the door.

Rands In Repose: How to Run a Meeting I ♥ Rands. (And, as an aside while looking up the heart character, I also love that Apple has an entire section in their Character Viewer titled "Divination Symbols". What I like even more is that they're all the I-Ching.)

InfoQ: The Role of the Enterprise Architect Good article, but like many things on InfoQ, light on actual, actionable things to *do*. The more I get to be an actual architect, instead of an extra pair of hands or a firefighter, the more it's blatantly obvious that being an architect of course deals with technology, but is mostly understanding what an organization wants to do, how to use technology to get there, and then having the leadership – both the political savvy and the force of will – to get from Here to There.

InfoQ: Crowdsourced Testing, Changing the Game A whole lot of vapor surrounding a pretty good idea, in general: Mechanical Turk meets test scenarios, perhaps? I can imagine how it would work, but I don't see how it would scale, when there are things like CloudTest and JMeter+EC2 to bring millions of virtual users to bear in a load test.

Seth's Blog: First and never

Rands In Repose: B.A.B. Been a while, I know. But, it's Rands that got me to post this little bit here, and for that I thank him. Trust is something I feel really strongly about, especially after watching it get eroded quite a bit around here. How do you rebuild this trust, when it's so severely damaged?

I actually put together a blog post. Who'd have thunk it?

I'll admit it: I've been triple-booked at work more than I can possibly imagine. Part of that is a pure lack of institutional respect of people's time, and the culture that dictates that everything is a priority, so obviously the other commitments you've made can't possbily be as important as My Meeting. But, part of that is an inherent lack of understanding of Sustainable Pace, especially when it comes to meetings. Looking over my calendar for the past few months, I'm constantly amazed at the number of meetings that get scheduled in the miniscule crevices between other meetings. "Oh, you've got fifteen minutes between those two meetings. Let's have a quick meeting to discuss this..." Now, if I worked somewhere that employed a bunch of Marissa Mayers (see: BusinessWeek on "How to Run a Meeting Like Google") then there's a distinct possibility that this would be a very productive, if overwhelming possibility. But, I don't, and it compounds the basic problem in my mind with this constant-stream-of-meetings mentality. Today, I've had the opportunity to sit in a small conference room with one of my peers, and focus on one important deliverable. We called in a couple of experts when we needed them, and turned around our deliverable in a couple of hours. In short, a great use of our time. After that, I felt myself mentally decompress. I took a few minutes to jot down some next-steps, and prepare myself for the next item on my big to-do list. That took ten minutes. Once I took that time, I was able to clearly and succinctly take care of the next items on my to-do list with a minimum of fuss, and with minimum interruptions on other people's time. What could have (and possibly would have) resulted in two or three "quick little meetings" ended up being handled by a discussion or two, in under five minutes each. I've read a lot over the past couple of years about two topics: multi-tasking at work in the name of productivity, and Adult ADD. Being ADD, I fully understand and live the juggling a thousand things lifestyle. It keeps my brain engaged, and paradoxically helps me focus. But, I also realize that hand-in-hand with juggling a million different things is the ability to hyper-focus. When I need to, I can focus on a particular task and work on it to the exclusivity of anything else. In order to do that, I need to take the time to clear my plate, and catch the balls I have in the air, so to speak. When my schedule is filled with back-to-back meetings, there's no chance to clear my plate, no chance to take a minute to shift gears mentally. It's a constant stream of new information and context switching, and much like when I'm juggling a million different things but none of them well, I'm in a meeting but not able to give it my full attention. Invariably, there are loose ends from the previous meeting that I need to capture, that will enter my head and distract me from the things I should be paying attention to now. It's an unsustainable pace, and it's just as true with management and meetings as it is with Sprint tasks or a myriad of other things in life. Without the time to absorb and acclimate new information and ideas, we're just in an unsustainable flurry of things, and everything suffers. How can we communicate this need to those making demands of our time? How can we - as developers, testers, or more generally as professionals - explain that we need moments of rest between bursts of activity? If that basic human need isn't understood, what can we do to make it understandable?

Microsoft's Problematic Lack Of Nightly Builds For IE Really interesting insight into Microsoft's development cycles for Internet Explorer in an article over at Ars Technica. It makes me wonder what obstacles Microsoft's IE Team has that prevents it from making quicker releases and getting crucial feedback from developers so that Microsoft can deliver "...what developers really want in their browser". Without that frequent release cycle, how else do you get that feedback? It's an interesting contrast with, say, the SQL Server team or some of the other developer tools teams, where the CTP is the rule, and getting releases in front of users quicker is the name of the game. How much before the official release of SQL Server 2008 did Microsoft start selling licenses to run CTP builds of SQL Server in a production environment? And, I'm willing to admit that maybe they really do have those frequent release cycles internally; heck, I know we're releasing things internally long, long before a customer ever sees them. That doesn't mean I agree with it, though.

Yesterday, and again this morning, I spent a good chunk of my day changing someone's mind. Well, that's not fair. I spent a good part of my morning convincing someone that the train I was suggesting they take, not the train they were convinced that they needed, was the best way to get to their destination. One of the hardest parts of working with customers - internal or external - comes when the customer has decided that they not only know the problem, but they also know the right solution. Let's face it: we all do it. "When all you have is an Agile hammer, everything looks like a nail." Walking into the discussion, I'd talked about the customer's stated goals with our team: what they wanted, and more importantly, the timeframe we had to make it happen. In short, I described the ideal end-game, and then proceeded to define realistic things we could do by the end of the year. At the end of the team's brainstorming, we'd come up with a fairly elegant solution that, most importantly, was deliverable by this year and... To co-opt a phrase from Obi-Wan, it met the customer's goals, from a certain point of view. Armed with the knowledge that we had an elegant technical solution that met the customer's goals, I set off to discuss the solution with the customer. "No, that's not right." "Why not," I asked. "Because if you do that, we don't copy the data." Well, there it was. The goal was to display the data from a partner's site on our site, as stated, so that the third-parties were happier with prominent placement on our site, and so that the end-users who had to keep data up-to-date only had to keep one copy up-to-date. My team's solution did that, exactly, and did it in the time we had to develop a solution. But, it didn't copy data from database A over to a similar looking form in database B. "Why do we need to do that?" "Because that's what we said we'd do." Looking over the contract, talking to the third-parties whose problems we were trying to solve, that's nothing like what they said we needed to do. Their goal is to have their data displayed on our site, and give their customers one place to update our data. "We didn't say we'd copy it, we said we'd display it. Our solution does that, and gives their customers one place to update their data. Why do we need to copy it to our database?" "Because we need to be able to incorporate their data into our backend systems." Looking over our solution, I realized that we needed to incorporate the third-party data into our backend business rules. We could do that, using our solution, with minimal additional effort. "We can do that by modifying our business rules to include the new data source without creating or changing records in our database. Why do we need to copy their data into our database, and overwrite our records?" "Because we need to increase our numbers in our program for..." I anticipated this need as well. We could easily count the distinct new records between the two databases, and provide a unified number of clients using our two systems. I explained this, and then our CEO joined in the ad-hoc solution discussion in the kitchen. Note to self: if you want to have an opportunity to win over converts one at a time, avoid having those conversations in the kitchen. Luckily for me, one of our other senior managers joined the discussion, and we continued down the same track. At the end of the discussion, after feeling I'd made great headway toward explaining that we both wanted to get to the same destination, but that we had a much faster, nicer train to get there, it was time for the customer and our CEO to go off to a meeting. As he walked out of the kitchen, his parting comment was, "Well, I think we're all of the opinion that I'm right." If I hadn't noticed the sarcastic grin when he said it, I'd have given up hope. As it is, we're well on the way to getting a strong technical solution in place now, that's a good step toward the final corporate goals. When I'm faced with a customer who both knows their problem and thinks that they know the solution, it can be very difficult to examine their solution, together, with an objective mind. The customer knows enough to be dangerously entrenched with both their problem and the Rightness of their perceived solution. In this case, I used a modified version of the Five Whys to get to the root problems, and helped dissect the reasons that the customer's solution was an incomplete solution: there were serious data synchronization problems in integrating the two sources that the customer had just accepted as "intractable", and hand-waved off the table. There are countless other methods and means to get to the root issues a customer solution is trying to solve. Sometimes, the customer is right, and sometimes, they're wrong. But in either case, questioning the underlying assumptions and validating any solution is essential to a successful project and a happy customer. How do you work with your customer, especially those that have a solution already in mind, to uncover their assumptions gently and cooperatively, to build the best solution you can?

A tiger sits and waits, and knows when he needs to act, when he needs to let a situation pass him by. When it comes to knowing that, I'm still Shu. I've got a long way to go before I'm ready to move to the next step of wisdom there, I think.

Don’t do XP « Agile Anarchy Great article about Tobias Meyer. I don't know why I never stopped to think about XP as being over a decade old, but he's exactly right. Software craftsmanship is a great movement, but I'm concerned that without the "package", there's less for people to talk about. XP may be getting long in the tooth, but it's a set of principles that an organization looking to make the evolutionary change from non-Agile to Agile practices can rally behind. As much as the "do this, and this, and this" mentality can hinder teams, it's also something that management can understand. Working to help adopt Agile practices - both project management and software development - I believe that the team's the easier collection of converts. They get it, they can see the empirical evidence that adopting XP practices, say, brings to a team. In this respect, I think Tobias is right on the money. But management? I think it's much harder to explain "We're doing TDD and CI, with a little bit of pair programming, and mixing that with short iterations and cross-functional teams" than to be able to say the conversational short-hand "We're adopting Scrum and XP." Will any team ever do pure Scrum? Pure XP? I doubt it, and again, I totally agree with Tobias on this point. Being able to have a team pick up the right collection of engineering practices is key to the success of an Agile team. But, having the understanding and support of the organization as a whole - the conversational short-hand to be able to explain to a division President exactly how you're developing software and, more importantly, why it's so much better, is key. "Scrum" and "XP" are labels, but labels can be important.

Managing Product Development » What Would a Successful Agile All-Remote Team Look Like? Aside from sounding like some Agile Awards Team ("And now, your 2009 Agile All-Remote Team!") Johanna has a good overview of some of the hurdles facing remote teams. My two most recent perspectives, from today. Earlier, @mhsutton sent out a question over Twitter, asking if anyone uses remote desktop sharing tools to facilitate pair programming. I enthusiastically answered, "YES!" Two of our DBAs use remote desktop sharing so one of the pair can work remotely a fair portion of the time. They've got pair programming down cold, and are a fantastic testament to the advantages of pair programming. It's a great example of how remote pairing can work, well. But then, earlier today as we were stressing out about the testing effort we're undertaking with our outsourced testing team in India (yes, I know. It hurts. Deep, deep hurting) one of that pair exclaimed, "Dammit, it would be so much easier if Mohinder were sitting here, so we could actually see the output of their testing tools!" So, thinking some more about Johanna's blog post, I think that one of the things I've seen that leads to a successful remote pairing arrangement, and by extension remote teams, is that they need to work co-located for a bit, first. There's a natural shorthand that develops between team members. There's a language of work habits and methods that, when working remotely, you encounter obstacles to developing. I'm sure that you can develop these habits, only working remotely. It just seems that being co-located, first, allows those habits to develop sooner, and makes working remotely easier, later. I'm sure there are lots of things I'm forgetting, too. But my brain's wandering off to how to integrate new team members into a remote team, without bringing the entire team together to indoctrinate the new team member, and that's a whole other blog post.