The Use, Application and Future of the Agile methodology
Be the 1st to comment!

I recently received this question about the Agile method of developing software and thought I’d share it and my answer.

Q. I am doing some research on agile methods, and wanted to know what you think about the use and application of agile methods? Will they continue to be used more in the next decade in internet software development? And what agile methods do you use?

A. Many startups have been using a more “agile” project management methodology without really knowing it. It’s the formalness of the “official” Agile and Scrum practices that are gaining in adoption now. As to if that official set of rules will stay around for a long time it’s impossible to predict, but judging from history, I think certain exact sets of guidelines come and go in popularity. The principles behind what is considered Agile however, I believe will last a long time. Many of us have seen the failure of planning out year long projects, holding daily hours long meetings to discuss statuses, and building 100 page analysis documents before anything is ever built.

Small, lean, flexible teams, working on shorter production cycles will always produce better software than rigid, bloated teams working on long drawn out project timelines. But most teams will do so without ever getting certified as a Scrum master or some official title for following some group’s rules as to how to manage a project. They do it because they observe the failures of the opposite through experience, particularly if they ever worked in a large corporation and had to follow the time wasting mess of project management that typically emanates from such places.

For me, following rules for how a project should go is not agile enough in itself. Guidelines are great, and I recommend understanding the Agile method so you can learn from it’s principles, but true agility comes from fitting the process to the specific team and project at hand. So I recommend never becoming allegiant to a certain methodology of project management, nor even to a certain development process. Use them as guidelines, but adapt them to your specifics and let them grow with you as you learn and experience more. Ensure the team shares in the understanding of why the agile process is better versus things like the water fall approach. Once they do, wether you stick to the Agile Manifesto or not will not be the significant deciding factor in the efficiency of your software development. It’s the underlying principles that matter, and those I believe will be with us for a long time.

Experimenting with Workplace Environments
Be the 1st to comment!

For years I’ve questioned the stubbornness with which companies cling to the Industrial Age’s workplace environment and management strategies. In an age of new technology, new work skills, and a new desire by employees for an opportunity to go beyond being simple workers, to creative influences with input and ownership of their projects, so many companies and managers continue to treat their employees like expendable resources that can be burned down to ash and simply replaced with a new job posting. As well, work environments are stale, don’t inspire creativity, and fail to treat the workers as responsible adults (which, by the way, inspires them to trust you and perform at a higher level).

Two articles were published this week on these topics. First, from Robert Dempsey of Rails for All and Atlantic Dominion Solutions, with his article The Changing Role of Managers, in which he discusses how his role as Project Manager has evolved through trial and error, and describes his main role as PM with these words:

The main role of the scrum master [project manager] is to remove impediments that hold back the development team from being productive. Impediments might be lack of tools or clients taking a long time to respond. The scrum master also ensures that there is as little outside interference as possible.

He goes on to say that the manager’s role is that of leader, and that trust is a major element in team success. He provides a list of books he read as well on the topic.

In the second article, from Jason at 37signals, titled, Workplace Experiments, he discusses some of the new benefits they are experimenting with to keep their team fresh and happy, and thus in the end, far more productive than the teams that work away their lives (not to mention cutting down on the high hidden cost of employee turnover). 37signals is experimenting with:

  • four day work weeks
  • helping pay for their employees to learn new things and expand themselves; everything from learning to fly to learning to cook
  • credit cards for discretionary spending (books, conferences, software)

Not all experiments may work, nor be affordable forever, but I loudly applaud the effort to shake things up, treat the employees like you really value, respect and trust them, and make an effort to look for new ways to enrich their lives and help them fulfill their passions.

Remember:

How we spend our days is, of course, how we spend our lives.
~ Annie Dillard

Focused Problem Solving
Be the 1st to comment!

My favorite web development company, 37 Signals, recently added a post by one of their team members, Jason. He discussed some of the decisions and process that went into a recent functionality addition to their product Highrise. They set out to provide import functionality that their customers were asking for, but in their pursuit of a solution they got off track due to thinking too large.

Sometimes development and design teams can think too small, and not see the forest through the trees, but at other times, and I see this a lot in the IT industry, development teams think way too big. They see a problem and instead of focusing on the important issue, they attempt to provide functionality just in case they might need it some time down the road. But just in case development is very costly, and from my experience, most times that “case” never actually occurs.

The point of Jason’s post is that in this instance, not only did they waste time, but they also didn’t even provide the needed functionality, because they lost focus on the particular problem that really needed the must urgent solution.

In Jason’s words:

…don’t lump a bunch of related small problems together—it just makes one big problem. One big problem requires one big solution, and big solutions take a long time (and often don’t go right). You’re better off chopping big lumps of problems into smaller chunks until you’re able to knock them off one at a time.

Read the entire post, “Design Decisions: Highrise import“.

Increase Programming Efficiency By Taking Breaks
Be the 1st to comment!

Recently, Matt at 37signals wrote a post about taking a break from your programming task after four hours.

The comments of the post took a detour from the main point, which was to stop and take a look at the task and your direction with it. However, most of the comments seemed to focus on taking a break when you are stuck. It’s true if you hit a wall, you should take a walk and try to get some distance from the problem. You’ll often then be able to see over or around the wall, or realize the wall is actually only a figment of your imagination.

But I think the point to this post was to take a break from your task, after you’ve spent about four hours on it (though the time should be in relation to the size of the task), and reassess your current status and direction, and most importantly, if the task should even continue to be done.

Sometimes we think of a solution, but while working on it we hit road blocks; things that we weren’t aware would be a problem. An example might be using a new technology we thought would solve the problem, but in doing so we introduced new problems. As programmers, as thus problem solvers, we get so focused on solving the problem at hand, we need to take a step back and realize that the direction we are going is more work than our nifty solution was worth. Adding this new technology, for example, might turn out to add far too much complexity, and require too many other solutions to get it to work.

There may be times where, after taking a break and re-evaluating, we have to go back to the Project Manager, Team Leader, or whomever you report to, and let them know the task is not nearly as simple as you thought, and more time needs to be allotted. After reporting this, you may find that the task you are assigned to is no longer quite so important to management, knowing it will cost them more.

I’d like to add, that taking breaks from tasks, and taking time to clear the mind, and step away, is such a vital part of being a problem solver, and yet it is discouraged by the very nature of the 8 hour work day modern IT management stubbornly continues to conform to. My personal belief, is that some days should be 5 hour work days, and others might be 10. Or, you may work four hours in the morning, and four in the evening. We need to be free to stop what we are doing when it becomes clear that we are no longer making progress for whatever reason. We could be tired, we could have hit an unexpected wall, we could have a personal issue that is distracting us. In many of these cases, its much more efficient to stop, and do something entirely different and come back to your work later, than to attempt to press through, and possibly waste countless hours making absolutely no progress.

This requires management to assess your effectiveness by what you accomplish on the project and with the team, as opposed to what hours you are sitting in front of your computer monitor. For some reason that shift in people management has been very slow in coming. I know some companies, teams, and managers that understand it, but I think the majority are still far behind; still stuck in the industrial age of management styles.

Read the entire 37signals article, “Four hours upfront and then reevaluate“.

Delivering Focused Features
Be the 1st to comment!

I mentioned in my previous post, “The Real World”:

I prefer a short development life-cycle, keeping the requirements for each cycle short and to the point. The smaller the feature set, the shorter every sub-cycle is (design, testing, etc).

37signals recently discussed a great example of this concept with their “Public Contact Cards”. They saw a need, and delivered a solution to it within 48 hours. In order to do it, they kept a very tight focus on the goal of that feature. They solved the problem in the simplest and most direct way possible. They mention several features they could have added and didn’t. Some of them certainly sound like great additions as well, and you may one day see them. But, by keeping the focus on the problem at hand, they can act much quicker to market and consumer needs, keeping their customer base happy, and reducing the risk of implementing new enhancements. They also get a chance to see how their consumers react to the direction of the solution before they have gone to far down the road.

Read more about the Public Contact Cards they added to their new Highrise application.

Page 2 of 41234