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?
“There is No End State When Transitioning to Agile” (Mike Cohn, Succeeding with Agile)
As usual, a good article from Mike Cohn to start off my work week.
This reminds me of an article I read earlier, about process improvement at Toyota (I can’t find the link, but if I do, I’ll come back and add it to this post). In short, they described the view of “process” at Toyota as fairly binary: either the process is being actively improved, or it’s degrading. There’s no concept of a steady-state, no concept of “done”.
From Mike’s article:
So, a transition to agile cannot be a process that “articulates and defines the entire change process required to bridge the gap between ‘as is’ and ‘to be’ and creates tactical plans,” as I read in a traditional change management book recently. Creating such a plan would require leaping two impossible hurdles: first, knowing exactly where we’ll want to end up; and second, knowing exactly the steps to get there.
There’s a ton of utility in this half-paragraph - in Agile, in business, in life. Most importantly, though, is the recognition that like Toyota, no matter how good your transition is, no matter how refined your process, you’re never done.
This is hard, and tiring. Accepting that you’re never done also means accepting that there’s always work to be done, always more to do, always more improvement. If your goal is to coach a team until they’re Agile, then realizing that you’ll never be done means that you have to redefine your personal success criteria.
How can you succeed personally if you have to accept that you’ll never be done?
One of my friends and I have been talking about this very thing, albeit in a more circumspect manner. How can you feel comfortable walking away from a job, a project, a team without feeling like a failure? How can you say “I’m done” without sacrificing your own sense of commitment to the team, without feeling like you’ve failed in your project?
Agile is tough. Continuous improvement is tough.
No matter the circumstances, you can always improve. You can always start improving with yourself. You can always start improving today.Kent Beck
Kent Beck’s quote has always resonated with me, especially as I’ve transitioned through so many things over the past few years. It’s setting the bar higher, always looking to do more, do better. But, accepting that the bar can always be set higher means figuring out when to stop, when to catch your breath.
I don’t have a lot of answers today; mostly, Mike and Kent’s quotes leave me thinking and rolling thoughts around in my head. But, a quote from one of the books I keep on my bedside table has been stuck in my head as something of a counter-point:
The tiger is the same way. He conforms to every situation that comes. If he spots prey and is not ready to hunt, he will let it go. But he has not failed to act. He has knowingly let the prey escape, and this is much different from someone who loses a situation through slow reflexes or inability. When the tiger wants his prey, he pounces upon it without any thought or hesitation. There are no morals, no guilt, no psychological problems, no ideologies to interfere with the purity of his action. This undiminished grace in action is called nonaction.
No. 34: Engagement, Deng Ming-Dao, 365 Tao
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.
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.
