I recently published an article on the Agile Journal titled “Let’s Stop the Wishful Thinking.” To me, estimates for projects are often just wishful thinking. Can we make them more fact-based? I have tried several techniques on projects and this article is the culmination of what I’ve seen work.

Here’s the link.

Here’s a link to an article I wrote on Agile Journal on our latest experiences at Marion Correction Institution. We had a good crowd of developers who visited this prison and I think everybody learned a lot.

Be sure to read Michael Feathers’ blog post on looking at existing code as “inventory.”

Here is a short excerpt:

Let’s go back to manufacturing. If you are making cars or widgets, you make them one by one. They proceed through the manufacturing process and you can gain very real efficiencies by paying attention to how the pieces go through the process. Lean Software Development has chosen to see tasks as pieces. We carry them through a process and end up with completed products on the other side.

It’s a nice view of the world, but it is a bit of a lie. In software development, we are essentially working on the same car or widget continuously, often for years. We are in the same soup, the same codebase. We can’t expect a model based on independence of pieces in manufacturing to be accurate when we are working continuously on a single thing (a codebase) that shows wear over time and needs constant attention.

Michael works a lot on legacy code and his views are very insightful.

Here’s a link to several blog posts from Pillar developers (and others) who went to the Marion Correctional Institute last month to pair with inmates learning software development.

Are you guilty of greedy philanthropy? It’s something we may all be guilty of without even realizing it. The other day I experienced an example of greed; not greed for money or possessions, but greed for the opportunity to contribute to the general good.

Here’s my story

Our school had a high school student who would be on his own (without parents) for a number of weeks due to one parent donating a kidney to the other. The parents were new to the area and didn’t have family that could help with the student so the PTA parents took the initiative to start a calendar where people could volunteer for one night to cook a home made dinner for the student every night that the parents were in the hospital. The completed calendar was distributed to all of the families who volunteered and every day was taken by a different family. My family volunteered and we were really excited to cook one of our old family recipes. The student came to our house on Thursday and said that he really wasn’t hungry because the volunteer family from Monday cooked enough extra food that he had enough for the whole week. While the student did eat a little bit, our opportunity to participate was pushed aside by the other family’s overly generous actions.  The family thought they were doing good (philanthropy) yet they took away everyone else’s opportunity (greedy).

I learned my lesson that day and have made it a point to seek out help, to always say ‘yes’ when asked if I need some help – even soliciting help when I don’t really need it.  It takes a certain amount of maturity to be able to say “yes, I could use some help” rather than “no, I’ve got it” even when you could work as efficiently by yourself.

But how does this relate to business?

Multiple authors on organizational behavior have recognized this type of behavior. For example Tribal Leadership by Logan and King classify many aspects of this behavior as stage 3 and in Goleman’s Emotional Intelligence, the pacesetter management style has very similar behavior – that’s only two examples. Experts in organizational behavior point out that greedy behavior may be effective in the short term but it can minimize teamwork, destroy initiative, and can lead to burn out of the greedy philanthropist. The team become tired of trying to contribute and simply resolve to do what the pacesetter lets them, becoming a cog in the wheel rather than fully invested in the project.

How to fix the problem

The first step in fixing this problem is to look in the mirror and ask yourself if you are being greedy, even for the best of motives. Ask yourself how you can become a connector, not a performer. If wisdom is more important than knowledge and networks are more important than on-task ability, how can you as a leader build, leverage, and encourage networks? You need to rely on other people, even when you can do it faster alone.

Coach other greedy philanthropists on sharing the workload – not only allowing people to help but soliciting it. Often times people with a goal driven personality can be moved to collaborate by directly challenging them to change – using their very own goal driven tenancies to drive the goal of changing their accomplishment hoarding behavior. They may not even realize that the biggest impact within an organization comes from lubricating the rails of teamwork and not individual effort.

Epilogue

Imagine the impact the family from earlier in my story would have had if they had brought several families together on a Monday and had a potluck with plenty of leftovers for the rest of the week. Networks and relationships would have been built and everyone would have felt valued. But instead the student was well fed and the rest of the families were left feeling like they really just didn’t matter.

This year I am helping with KidzMAsh as part of the CodeMash conference.  I have been using a Kids programming language called Scratch to teach adults Agile for about a year or two and have wanted for some time to look into teaching kids Agile.  I piloted this idea at the Simple Design and Testing conference with my kids.  To my surprise It was easier to teach Agile to kids than adults… in fact to a large degree they are already Agile.

My new goal should probably be to keep them Agile.

My kids are seven and nine and spent about three hours focused on this exercise.  Here is what we did:

1. We set a goal: after some discussion we choose to build a Version of PacMan
2. We created a Backlog: they wrote 3 x5 cards for things like “Making PackMan move” and “Making Ghosts kill PacMan”.  We also had some interesting enhancement ideas like “Make PacMan Shoot”.
3. We created a Kanban Board: to keep it simple we had three columns Backlog, In Progress, and Done.
4. They proceeded directly to writing production code

What I found:

• They paired naturally:  my nine year old drove most of the time but talked through what she was going to do before she did it.  My seven year old redirected her often and came up with many possible holes in their solution.
• They were not easily blocked: if they had a question they came and found me and asked.  When I was not available they even found others at the conference to help them.
• They owned their process: they decided they needed to add a column (“things we do not know how to do”) to the card wall without being asked.
• They added to their backlog as they learned: when a card was too big they broke it down and added cards, when they had a new idea they wrote a card and they were good at updating the board with what they had done and in progress.

They did have one advantage, the already knew Scratch.  It went well enough that I am going to try it with a bigger group at KidzMash

Apple has led us into the world of platforms and app stores. Seven years ago, who would have thought of a cellular phone as a software development platform? And yet, we know now that these new platforms are absolutely the future of consumer-oriented and enterprise software (as we’ve discussed on this blog). No vendor can introduce a new electronic device without all of us asking “Do you have an SDK (software development kit)?” You’d better. Amazon introduced the Kindle e-book reader a few years ago and developers complained until Amazon created a platform for custom apps on the Kindle. Ford and Microsoft build a complete driver-support system for Ford vehicles called Ford Sync. “Can I build an app for that?” Turns out you can.

It is exciting enough to envision everything we’ll be able to create on these platforms that already exist. That’s what my last blog post was about. But what are the platforms yet to arrive??? The biggest one on my horizon is the smart grid. The smart grid is an electricity grid that is soaked in information technology. Instead of today’s grid, which simply transmits electrical current one-way with no information, the smart grid contains nodes that can talk with one another. Each power meter becomes a smart meter. Each appliance in your house (fridge, stove, television) becomes a smart appliance.

And guess what??? Each meter and appliance becomes a platform. Where you can run apps!

I’m just sitting here imagining a future conversation between two home owners.

“I just downloaded an app for my fridge. I’ve only been using it for 3 days but it has already been saving me $5 a day in energy costs!”

“Oh yeah? Was the app created by the fridge company?”

“Heck no. Probably done by two guys in a garage somewhere.”

Everything that’s happening on our phones today will start happening in our cars and our houses. Why not? We couldn’t sit around waiting for AT&T or Blackberry/RIM to innovate? Let somebody else move technology ahead.

Smart meters are a reality in more and more places. Westerville, the city where I live, has been implementing them. Astoundingly, the effort has been stalled (for now) by technology luddites questioning the value of them. The luddite issue will be a tough one all across the U.S. until people are sufficiently educated on the technology.

Predictably, Google is already at the forefront of this not-yet-an-industry. They’ve built Google Power Meter, an open source information hub that talks to smart meters. Open standards will be important, and companies are getting behind an open standard protocol called Open Smart Grid Protocol that will allow devices/nodes to speak to each other. They’ve said that Google employees who’ve started using it have noticed a 17% decrease in personal energy costs just by virtue of knowing what power they’re consuming and when. Imagine what they could do with app stores full of power-saving apps!!

(Photo courtesy first-utility.com)

Recently one of our consultants, Nilanjan Raychaudhuri, asked the question “Where is groovy love?” on our internal wiki. He noted that there is a lot of interest in Ruby among developers inside Pillar but not so in Groovy. He was curious as to why there was more interest in Ruby than Groovy: community, language features, cool factor?

Here are some of the opinions from the brain trust at Pillar (edited for clarity, content, and length):

Zachary Spencer:
The groovy I’ve done has always been painful. Ruby on the other hand, provides instant delight. The analogy I use when discussing Groovy is: I go to the ice cream store and get the green ice cream, thinking it’s mint. I take a good hard lick only to find out it’s pistachio. It’s not that it’s bad (I *like* pistachio) it’s just that I thought it was mint, and I wanted mint, and I expected mint and got… Pistachio.

Jeremy Anderson:
For me I think it comes down to the testing tools. Using mocks in Groovy just seems awkward.

Shih-gian Lee:
For me, it comes down to language construct. Ruby is more concise and terse. When I use Groovy, the language reminds me of Ruby in many ways but doesn’t work like Ruby.

In the Ruby community there is a lot of innovation. Groovy is a new language and so is its framework, Grails. So far, I have not seen any great innovation came out of Groovy community.

Ruby is simple to learn, especially if you have coded in JavaScript before. I believe if someone can understand a complex language like Java, he will be able to pick up Ruby pretty quickly.

Another reason I am in favor of Ruby over Groovy is because there are many good gems out there that can boost productivity and they are not yet available in Groovy world.

I am still doubtful how successful a Groovy/Grails project can be if we work with a development team that is very conservative. Most of the people I have talked to told me that they sold JRuby on Speed and Productivity.

Clients who don’t have a good handle at good practices, such as TDD and Planning are not ready to tap into the power of a modern language like Ruby and framework like Rails. Rails really embraces agile approach.

Kevin Baribeau:
My main reason for looking at ruby has always been the community, which includes some exceptionally bright people. The craftsmanship community especially seems to be mostly involved in ruby. You can count the rails community on top of that, and the loads of other cool ideas that seem to come from that crowd.

I’m not aware of any new ideas coming from the groovy community. If there are cooler things going on in groovy/grails land though I would love to hear about them.

BJ Allmon:
Groovy and Grails seems to be going really smooth at my job and I can only speak for my experience with it.. I love it. Grails seemed like a great start to migrate legacy Java.

Nilanjan Raychaudhuri:
Grails still going to be my number one choice.

Groovy gives confidence to the client architect who worries about his less skilled developers. Groovy is something they can easily understand.

Groovy probably has the best integration with Java than anything other JVM languages. I can take a EJB and drop it to grails with one line configuration change. Java stack is typically Hibernate, Spring, some web template engine etc. In one words that is Grails. Underneath it uses the same set of frameworks that you would choose anyway if you do it in Java. It helps to get hardcore Java shops excited about Groovy & Grails.

Ruby, though, does have awesome collection of gems and using JRuby for Java is a good idea.

Justin Searls:
While Groovy & Ruby both feel about as expressive as one another, Ruby (particularly 1.9) seems much more feature-rich, pound-for-pound.

Most importantly, the smartest people I know (and know of) are prominent members of the Ruby community. I, for one, care more about being around smart people than I do about characteristics of programming languages, and Ruby absolutely blows Groovy out of the water in this respect.

This is all without even exploring the fact that the Ruby community consistently puts out some of the most novel and influential open source libraries/tools/frameworks that are merely weakly imitated in other environments.

Groovy was created in part because python/ruby didn’t run on the JVM. Now that Ruby runs on the JVM without issue, I have a sense that the inhibitions of organizations to adopt Ruby are mostly cultural, not technical.

Kevin Smith:
Groovy is a great language for anyone or any shop with a Java background that wants to transfer that knowledge smoothly. Some will consider this a negative but you can copy and paste java code into a groovy file and 98% of it will execute. This is extremely helpful for migrating corporate developers into the dynamic nature of groovy and the grails framework.

Groovy for testing is awesome… you don’t need any mocking libraries as you can take any map of functions and turn it into an implementation of any class or interface — if that isn’t enough one line of Class.metaClass.xyz = {} has been enough to solve just about anything I’ve come across.

Groovy is type optional instead of pure duck-typing. Maybe it is just me but I love being able to specify a type when I absolutely know it, but not have to all the time.

Eric Wilson:
I think the answer is pretty simple. Groovy is a compromise. We use it not because it is our first choice, but because it is something cooler than Java that a client would consider.

Groovy is not unpleasant to use, but it is unlikely to be the favorite language of many. While I haven’t found any reason not to like Groovy, I also haven’t found anything that is particularly distinct about Groovy among the modern choices. Except, of course, that valid Java is (almost) always valid Groovy.

When a language’s “killer feature” is that you can transition Java developers to it without too much trouble, it isn’t likely to generate a lot of love.

Biju Rajan:
In a java shop, it would be easier for the developers to transition to the groovy/grails path. It takes more rampup time for going the ruby/rails path.

I like Ruby as a language though I still have reservations on Rails as a framework.
I haven’t had a chance yet to work on a full scale Groovy/Grails project but I am sure it would be a lot more fun than a standard java app.

Clients may be looking for help at the Practices level (TDD, Energized Work, Planning Game, …) when they come to us, but I think that opening minds to the power of today’s languages is a fruit of efforts at the Values and Principles level – trust the team to make the right choice.

At Pillar, we are strong advocates of open source software, Maven, Hudson, Ruby on Rails, Eclipse – you name it. But a lot of corporations hesitate to use open source software for a variety of reasons. “Who else is doing it?” One answer is – Netflix. In this post, Netflix’s VP of Systems and e-Commerce Engineering proudly explains why his group uses open source software for most things. Netflix is an incredible technology company, but more importantly, they are a leader in other ways too. Here again they show how they are ahead in one more way – making smart usage of the open source tools that exist for software development, deployment and execution.

Over the past few months I’ve become fixated on a theme. This may seem like common sense to the well educated and debonair readers of this blog, but to me it feels like a flash of insight more poignant than profound. Consider:

There are Three Forces in Balance on a Effective Software Team: Technical Excellence, Management, and Customer Representation

When these come out of balance the team tends to become less effective. A team which is more concerned with how beautiful of an object model they can create instead of consistent delivery of business value can wind up creating very little value. However, a business which cares only for the next big thing at the expense of technical craftsmanship will eventually wind up incapable of adapting it’s technology to meet its customers needs and substantial cost increases. A company who cares too much about their customers that they don’t take care of their own needs as well can collapse due to not being able to sustain their rapidly expanding customer base.

Unfortunately the solution is not simple. Companies who are out of balance tend to have rifts in their organizations. These rifts may play out as a technical team which think management is stupid, inept, or evil. Or it may be one where no matter how many times people call customer support, the real needs of the user just don’t percolate back into what gets done. Maybe management considers the technical people lazy or uninterested in their values. No matter what the rifts are, they make it really hard to execute a software project effectively.

Making great stuff is a team sport, and all three of these concerns need to be tied together by effective practice. Now, the word practice has many meanings so for now I mean a customary way of operation or behavior.

It is my belief that in order to bring these forces back into balance, and rebuild relationships throughout the company requires a culture of mutual respect and collaboration. To do that we must create teams which are held wholly responsible for success, who share their responsibilities based upon the situation, not job titles. The team must consistently share and evolve it’s practice to take into account the three responsibility areas of effective teams: technical practice, customer representation, and management practice.

Technical Practice

A technical practice is anything that makes change easier, increases reliability,  improves technical quality, or otherwise aids in the creation of working software. Extreme Programming advocates things such as pair programming, refactoring, test driven development, and continuous integration as a baseline for an effective teams technical practice. I happen to agree.

Customer Representation

A customer representation practice is anything that makes it more visible or obvious what it is your customers actually want. The most important aspect of customer representation is the on site customer or product owner. However, don’t limit your customer representation to a single person, instead the team should be responsible for creating personas (and helping stakeholders putting them on maps so you know who is most important!), writing user stories, and doing usability testing.

The majority of customer practices originate from the fields of business analysts, quality assurance (or advocacy, my preferred QA), user experience, and cognitive psychology. Primarily they are oriented towards learning who your end user are, what they want, and why they want it.

Management Practice

With the rise of self organizing teams and a focus on interactions between people many considered this the “End of Management.” However, I believe that management is not dead, but its role is evolving. Maybe to management 3.0. However, management cannot fall to just one person. In fact the entire team should work to make information big and visible, create a healthy work environment, facilitate group decision making, and build strong relationships throughout the company.

Mixed Practice

In reality, trying to shoe horn some practices into just one of these three boxes is unfeasible. Often times something we do benefits them all. Story cards help facilitate big and visible information, as well as represent a customers desire. Continuous integration systems give us fast feedback on our software quality in a big and visible way. So many of the things we do help out in each of these arenas, which is why it is so crucial that the whole team owns these areas of practice.

The Practice of No Practice

Bruce Lee was famous for his “No Style” style of martial arts. By learning as much as he could about a huge number of fighting techniques, he was able to adapt his own personal style directly to the situation at hand. This is the end goal of our three areas of practice. By creating teams of specialized generalists who are extremely competent in at least one of these areas of practice and branching out into the others we create development powerhouses. We can build the right software, the right way, and generate business value even faster