agile.brazism

"What killed us was “one more thing.” We could have easily done three major releases that year if we..."

Wed, 10 Nov 2010 09:06:00 -0500

“What killed us was “one more thing.” We could have easily done three major releases that year if we had drawn a line in the sand, said “finished,” and shipped the darn thing. The problem is that the longer it’s been since your last release the more pressure and anticipation there is, so you’re more likely to try to slip in just one more thing or a fix that will make a feature really shine. For some projects, this literally goes on forever.”

- 1.0 Is the Loneliest Number — Matt Mullenweg

Good article about the need to actually ship - “Great artists ship” - that’s summed up in one sentence:
But if you’re not embarrassed when you ship your first version you waited too long.

Getting your product out the door, in front of users, is still the best way to find out what they actually want and need, instead of studies and surveys and interviews. Get people to use it, get them to complain about it, and that single act will provide you with all the information you need to prioritize the “What’s Next” list of features for 1.1, 2.0, 3.0 and beyond.

Ship it. Get it out the door.

"A meeting has two critical components: an agenda and a referee."

Thu, 19 Aug 2010 13:52:21 -0400

“A meeting has two critical components: an agenda and a referee.”

- 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.)

"If you don’t have good leadership skills, the rest of it fundamentally doesn’t matter…..."

Tue, 03 Aug 2010 22:13:49 -0400

“If you don’t have good leadership skills, the rest of it fundamentally doesn’t matter… If you do not lead and do not take the risk to lead, the transformation won’t occur. One of the barriers for the profession today is that many architects are not prepared to take the risk of leadership.”

- 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.

"Crowdsourced testing is the powerful combination of combining web and cloud economics with the..."

Tue, 03 Aug 2010 18:38:45 -0400

“Crowdsourced testing is the powerful combination of combining web and cloud economics with the effectiveness and efficiency of crowdsourcing. Could this be a game changer?”

- 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.

"Revolutions are like that. They invent and destroy and they only go one way."

Sat, 20 Mar 2010 10:42:00 -0400

“Revolutions are like that. They invent and destroy and they only go one way.”

- Seth’s Blog: First and never

"Here’s my question: do you or do you not want be the person someone trusts when they need help?..."

Fri, 19 Mar 2010 15:01:18 -0400

“Here’s my question: do you or do you not want be the person someone trusts when they need help? Manager or not, do you see the act of someone trusting you as fitting with who you are?”

- 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?

Surprise, surprise...

Tue, 12 Jan 2010 13:33:46 -0500

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

Sustainable Pace and Meetings

Tue, 12 Jan 2010 13:26:22 -0500

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?

"At the core, every browser has some type of release cycle for every build,” Hachamovitch said...."

Fri, 20 Nov 2009 11:43:07 -0500

““At the core, every browser has some type of release cycle for every build,” Hachamovitch said. “Some of the projects do nightly releases, others don’t. The goal of any prerelease offering is to have a meaningful feedback loop. The value to website developers of having all these drops to keep testing creates some fatigue for them because they keep testing this stream of drops. We’re trying to balance the number of drops to just meaningful drops.””

- 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.

How Do You Change Someone's Mind?

Tue, 10 Nov 2009 18:55:58 -0500

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?

"You may have a clear vision of what “doing Scrum” or “doing XP” means to you, and you may get others..."

Mon, 09 Nov 2009 09:10:33 -0500

“You may have a clear vision of what “doing Scrum” or “doing XP” means to you, and you may get others to buy into exactly that same vision, but where the organization ends up is likely to be somewhat different. In fact, to even refer to end states in an agile transition is incorrect; there can be no end state in a process that calls for continuous improvement.”

- “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.

"I urge Scrum coaches to stop talking about XP and start talking about software craftsmanship. That..."

Mon, 12 Oct 2009 11:54:22 -0400

“I urge Scrum coaches to stop talking about XP and start talking about software craftsmanship. That is what we ultimately seek and desperately need in this industry.”

- 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.

"Maybe their stories were too big (probably). Maybe their estimates were too far off. Maybe they..."

Fri, 09 Oct 2009 12:44:40 -0400

“Maybe their stories were too big (probably). Maybe their estimates were too far off. Maybe they didn’t know how to work as several people swarming around a feature when they were remote. But I can tell you that their velocity was significantly lower when they were apart than when they were together.”

- 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.

"An easy test of micromanagement is to let your team know you are confident in their ability to do..."

Fri, 09 Oct 2009 10:52:00 -0400

“

An easy test of micromanagement is to let your team know you are confident in their ability to do their job and offer, if they wish, that you will be less involved in their day to day work to give them more room to perform. Tell them you are available if they need you, but otherwise you will put some of your attention elsewhere. See what happens. Hold your tongue. Don’t demand to review that email. Don’t insist on regulating who can meet with who. Take one small step backward and see what happens.

Odds are extremely good the world will not end. Your best employees will be happier and more productive, giving you new energy to invest in the rest of your work or more afternoons where you can head home early. Some of your team might surprise you, and thrive with more autonomy. And for those who fail to improve or make mistakes, you’ve lost nothing, as you can step back in where it’s actually needed.

If you are terrified of trying this and have a list of excuses why this is a bad idea, the only thing you are managing is your ego.

”

- An open letter to micromanagers « Scott Berkun with thanks to @HackerChick

This is an interesting supporting article to Mike Cohn’s article that I quoted earlier, about the team micromanaging itself. Micromanagement isn’t necessarily bad, depending on who’s doing the micromanagement. Traditional micromanagement - the kind that Agile, and Scrum specifically, fights to eliminate - is the best example of command-and-control failure I can imagine.

Trust your people. Trust the team. Give them the freedom to do something, and give them the support so that while they may fail (and learn) their failures are manageable long-term for the project and organization.

That freedom and trust inspires people to branch out and try new things, and their solutions may be totally different than yours - and, frankly, may be a thousand times better.

A good manager is like a good coach: tell the team the goal, and let the team run their plays. If they need the help, be there on the sidelines to help them see the Big Picture, the whole field, and cheer them on.

"The original XP book includes this magical role of Customer (as in On-Site Customer, Customer..."

Thu, 01 Oct 2009 09:57:03 -0400

“The original XP book includes this magical role of Customer (as in On-Site Customer, Customer Tests). Scrum has a concept of a Product Owner, no less mythical tha[n] the XP Customer.”

- Gojko Adzic » The Mythical Customer Problem

Great, short article by Gojko on how to better handle the “Product Owner is never available” problem, with a quick reference back to Collaborative Specifications from his fantastic book - “Bridging the Communication Gap”.

"It is valuable for a business to be able to identify people who have the skills, ability, and..."

Tue, 15 Sep 2009 08:50:56 -0400

“

It is valuable for a business to be able to identify people who have the skills, ability, and intention to help them.

It is valuable for developers to lean what’s important to know and do, and how to improve.

If the ideas I care about–the same ideas you claim to care about, you whinging pissants — are to thrive, good businesses and good developers need to get together, and to grow and learn together.

”

- Whinging Pissants | xProgramming.com

You know, I love Ron. I understand that some people don’t, and find his style too abrasive. So be it.

Regardless of that, the fact remains that he’s one of the best minds in the Agile community, and the work he’s doing to try to bridge the knowledge gap between project management practices and technical practices is invaluable.

Shine on, Ron.

"Yes, agile is about micromanagment, but it’s about the team micromanaging themselves and for their..."

Mon, 14 Sep 2009 10:32:29 -0400

“Yes, agile is about micromanagment, but it’s about the team micromanaging themselves and for their own benefit.”

- Ssssh….Agile Is All About Micromanaging | Mike Cohn’s Blog - Succeeding With Agile®

Good, short article by Mike Cohn. It illustrates the necessity for personal responsibility in Agile, and the necessity for micro-management, even if it’s just micro-management of your own tasks every day.

Hard lesson for me to learn, but I’ve got the stack of lists to remind me of how important it is.

"We did that with Agile. The term “Agile” was vague at the beginning, as an umbrella term covering..."

Tue, 08 Sep 2009 19:40:58 -0400

“We did that with Agile. The term “Agile” was vague at the beginning, as an umbrella term covering many methods. It is now watered down to the point where to people who care, a project calling itself “Agile” is assumed to be messed up, and it usually is.”

- Watering Things Down Is Not Good For The Plants | xProgramming.com

I love reading Ron’s work. He’s so straightforward and to-the-point, and has a fantastic way to cut through the bull to the point we’re all talking around.

The recent conversations about Scrum and engineering practices, or between @michaelbolton and @thatqaguy are perfect examples of us getting lost in the words, and losing focus on the intent of what we’re all trying to. While it’s an interesting discussion from an academic perspective, how does any of it actually help us deliver more quality software?

"In order to deter people from showing up late to their daily “Scrum” or..."

Mon, 10 Aug 2009 14:44:55 -0400

“

In order to deter people from showing up late to their daily “Scrum” or “stand-up” meeting, some teams charge the culprit(s) a fine, or make them do some embarrassing activity (such as singing) for the team. Some teams use the money to buy lunch for the team once a month or so. (If that’s you: Please stop it! You’re rewarding the wrong behavior.)

It may be effective, at first, but if there’s a habitual lateness by an individual, or usually someone is late (though not always the same someone), then there’s a deeper problem: The meeting is not considered valuable to the team.

”

- Powers of Two: Charging Fees for Tardy Meeting Participants is Avoiding the Root Cause

Good article that, I think, is totally summed up in the first two paragraphs: if the meetings aren’t seen as valuable, then of course people won’t be motivated to attend, or see their late arrival as a real disruption. How can you be disruptive to something that has no value?

There’s another, more insidious possibility: that the individual doesn’t value the team, and in that case, the person either needs to be taken off the team or removed from the organization.

Let’s hope that, if you find yourself in that situation, you also find the support of the organization to actually deal with the problem, instead of hoping that this next trick will solve the underlying issue.

“Scrum doesn’t solve problems. It just highlights them, and forces you to deal with them.”

If only every organization had the courage to deal with their problems.

"In the cruise phase each defect is accompanied by the sound of evaporating money. On the runway..."

Fri, 07 Aug 2009 10:54:46 -0400

“In the cruise phase each defect is accompanied by the sound of evaporating money. On the runway defects are part of the price of feedback.”

- Three Rivers Institute » Blog Archive » To Fix Or Not To Fix?: Another Good Question (via @bpettichord)

Wow, I’m on a Kent Beck kick today. Thanks, Bret!

We’ve got such a loud defect siren that it’s deafening at times. Sure, we’re theoretically at our cruising altitude, but we also just released an entire rewrite of our core customer-facing product. Defects *should* be feedback, because we’ve got a backlog of new features to implement and legacy products to migrate/rewrite. But, we’re so reactionary that it hurts.

Frustrations abound today, it seems.