Archives

My Addiction

I’m addicted to TED talks. There have been many nights where I’ve stayed up way too late watching them. For those who are unaware, TED is a yearly conference where world leaders and thinkers gather to share their ideas and spread their passions and work. I’m someone who gets fired up listening to outher people’s passions. I love hearing about what gets other people excited, what makes them tick, what makes them want to share with the world.

One of the more interesting talks I’ve listened to recently is by Tim Brown at the Serious Play conference of 2008. Tim talks about how the elements of play can improve creativity and productivity in our workplace and life. I found the lessons learned from this talk something that can be very directly applied to software development, and taking some of these nuggets of teaching can help me be a better thinker and worker.

Code Ownership is a well known term in software development. Depending on how you define it, it may be a good thing or bad. When a developer sees code-ownership as him/her owning a piece of codebase that only he/she understands enough to make changes, it is generally a bad thing. It is only when everybody is free to modify the code with a sense of responsibility that he/she should leave the code cleaner than how they found it, it is a good thing. In my view, code-ownership is a good thing when viewed as a responsibilty as opposed to a right. I view it as a Collective Code Ownership where code is not owned by a single person or pair but is owned by an entire team.

So, the question is: How to determine if your project/organization has that collective code ownership culture. And what team members (including managers ) can do to create/encourage it.

Does your project have collective code ownership?
Here are few things you may want to ask yourself to determine if your organization/project has collective ownership culture.

Last week I presented at Agile 2009 a workshop for those new to Agile entitled: The Agile Game: An Experiential Workshop. I love this workshop because it allows those new to Agile to experience the rhythm of an agile project in action and learn first hand many of the practices in a non-threatening, non-technical, and fun way. I have used this workshop for clients a number of times and it works. The feedback from this session was overwhelmingly positive too. Comments such as, “Fun game, good to demonstrate how teams do and don’t work together” and “Very, very, practical way to get concept through” are always great to see.

Recently I had been wondering if Project Management was a questionable career choice. I have spent the last couple of years surrounded by talented individuals who seemed to be able to work fine without me. The test is always when the project manager (me) goes on vacation. Has the team fallen apart? Are they forgetting all of the practices they were doing? Is stuff getting delivered to clients? I was finding that I had a backlog of chores when I came back, but overall things were still humming along.

photo credit: alq666

As a software development company, we mostly work on client projects. Occasionally one project doesn’t start right when another ends. In that short interval, we would like to work on something useful — in house products, R&D projects, etc.. Unfortunately, we can’t run these “bench” projects the way we run a normal project. We can’t do two or even one week iterations, because some folks may only be on the bench for a few days. So, how do you apply these resources efficiently? Here are a few tricks we use:

1. Divide work into very small pieces — no epic user stories!
2. Keep your technology as vanilla as possible to reduce the learning curve.
3. Use Kanban to organize the work.

What is Kanban? There’s some good explanations of it over at Wikipedia and InfoQ, but just like Agile and the feedback loop, it helps to know the basic principles so you can figure out how it will work for you. From the InfoQ article:

A Kanban is a signaling device (usually a physical card in a clear plastic envelope) that instructs the moving or creating of parts in a “pull” production system, invented and developed as part of the Toyota Production System (TPS).

[...]

Kanban’s aim is to minimize WIP (Work-In-Process), or inventory, between processes by making sure that the upstream process produces parts only if its downstream process needs it. “Pull” means that the downstream workers withdraw or “pull” the parts they need from their upstream processes.

So, the basic principles are “pull” and minimizing “work-in-progress.” Let’s see how this applies to the bench.

Eric Smith from 8th light gave a hands-on TDD presentation at last night’s Chiphone meeting, hosted at Obtiva’s downtown office, (conveniently located near the the train).

There was a good crowd of people, most attendees have ‘played around’ with iphone development, 4 have actively developed apps (3 people have live apps in the store).  From my quick survey of those that have submitted apps, it seems most of them were free utility apps or simple games, with at least one commercial app Dash for Confluence. It also seemed that no one had yet needed to do any animation beyond the basics, with just a bit of core-animation, but no need for more lower-level openGL or animation engines.

Eric started off by saying that he’s given talks on iPhone testing, but that just telling people what to do is not the same as letting them experience it for themselves,  so we did a Randori, where a pair starts working on some code, and every 3 minutes one person from the pair swaps out and chooses his replacement from the crowd.

What I liked about this was that I felt like I got to know the audience better, and actually watch people reason their way through the code or a testing/mocking issue.  (You know how sometimes you go to a user group, and it can be hard to get a chance to talk to others, or sometimes there is a ‘know-it-all’ guy, and you just want him to shut up. Knowing that you are going to have to go up there and code is a great way to silence those types)

When it was my turn,  there was an interesting issue with one of the tests that had us all stumped for a bit, but ultimately ended up being one of those problems where you need to deconstruct everything and build it back up. (The issue was that while we were trying to set fooController.textView.text = @”foobar”, we hadn’t instantiated a textView object, or set it on the controller yet.)

One thing about agile teams is that they constantly strive to get better. In my experience an Agile team takes 2-4 iterations to work through the forming stage. By iteration 10 or so the team is past forming and storming and is well into norming. At this stage the team is often moving fast enough or better than expected for the business’ needs. Now the team faces a dilemma: How to become a high performance team and why.

If you don’t keep improving and innovating your competitors will.  However, there is another reason to keep improving that is often missed.  The current success might be temporary or an anomaly.

Don’t fall into the trap of a one hit wonder.

All the good stories in agile software development start “three manufacturing efficiency experts walk into a bar…” But seriously, I think it’s clear that software development has a greater affinity to manufacturing than to construction. So, its good to see the Lean and manufacturing folks get a little blog buzz over at AgileSoftwareDevelopment.com with Jack Milunky’s post The 7 Software Development Wastes – Lean series Part 5 – Motion:

Waste #5 in manufacturing is defined as Motion. And motion can be compared to “task switching” in Software Development – as defined by the thought leaders applying Lean thinking to software development.

[...]

I have found in many organizations, especially software companies where there is a real casual atmosphere, it’s easy to always interrupt developers. Interruptions are prevalent with requests. All this interruption only serves to add to the Motion bucket of waste. This is where the importance of a Product Owner, ScrumMaster and Backlog come in. These roles and any artifact are there to buffer the development teams from the noise and chaos outside of the current sprint activities.

Sometimes being able to reference another discipline, like manufacturing, lends credibility to discussions with a stakeholder. More often than not, many consider themselves to be an expert on software development but wouldn’t dream of challenging an expert on manufacturing.

Related Services: Agile Development, Custom Software Development

When you improve a little each day, eventually big things occur. — John Wooden

photo credit: mister b 1138

A few weeks ago I had a discussion with some colleagues on the adoption of Agile within large corporations. The consensus was that Agile was almost always adapted rather than adopted — that is, companies exclude those practices that conflict with corporate culture, modify those that seem too impractical or wasteful, and sometimes substitute those internal practices that seem a decent and familiar substitute.

Various schools of Agile thought have different reactions to this adaptation, all negative. The XP folks particularly don’t like it.

These [thirteen] practices support one another…and thus care should be taken when modifying any of them, or deciding not to include one or more of these practices in a project.

I agree that it definitely helps to follow a particular Agile approach closely in the beginning. Once you have the basics down, you can start to improvise. But it helps knowing the fundamental principle which, in my opinion, underlies all of the agile practices, no matter what the flavor. So, the first three commandments of Agile software development are:

1. Feedback loop
2. Feedback loop
3. Feedback loop

We hear more and more about large organizations adopting Agile software development practices recently.  This is not surprising given that Agile practices have many advantages over traditional methods.  One significant difference with Agile is the focus on building good teams.  Unfortunately organizations new to Agile often miss two fundamental questions before jumping into an Agile adoption.  The questions are deeply related, but not directly at first.

1. Why do Agile? To put it simply: Software projects can be better, faster, or cheaper by using Agile practices.  Pick any, and only, two.
2. What kind of team should be created?  Efficient or effective?

Photo Credit:
Amagill under Creative Commons Attribution

Security is hard

Security is often an after thought, slated towards the end of a project, or after some big issue has been discovered, but the nature of security functionality, rules, roles, auditing, etc make it hard to layer in to an existing codebase effectively.

Oh, and if the code base isn’t sufficiently tested, you’re in for a world of hurt.

If you are a developer that was just asked to ‘do a quick security check and plug any holes’, you are now in the difficult position of managing the expectation that a two-week security review means “we’re covered”. Be realistic about what you can accomplish, setting out some short-term and long-term goals.

Do More With Less. Start with a research ‘Spike’

Instead of pushing for more time to be able to ‘cover it all’ (even though you have no idea what ‘it all’ is yet), it might be better to start with a shorter analysis phase, where you detail your findings, identify any trends, and include recommendations for process change. I’ve found that even the most demanding manager is appreciative and understanding when you ask for a small amount of time in order to produce a better estimate, than to just immediately demand more time without any evidence as to why.

Plan for success

With your analysis and recommendations in hand,