Agile Process

Cutcaster photo 100202812 Frustrated woman with incompetent mechanic in backgroundI was out at Agile Prague earlier this week. There were many great presentations on building up better processes and a particularly interesting one by Linda Rising on the introduction of agile into organizations. However in talking with many of the people during breaks and dinners etc especially attendees I noticed different problems that people were having in real life.

The had the wrong people

No amount of process will fix this problem. If I take a bunch of people that don’t know how to actually produce decent code that works my process won’t fix it. They can’t actually build the wrong thing let alone the right thing if they can figure it out. I might be able to get away with teaching them to actually produce but now I have bigger issues. Can you imagine if you had to teach your mechanic how to change your oil so that he could actually change yours?

Its feasible to train such a team but it will be very expensive and time consuming, this should only be done in the worst case where other options are politically unavailable for some reasons (yes government sector I’m looking at you)

If a team is unable to produce instead of attempting to introduce small incremental changes. Consider making really big changes (like getting rid of a large portion of the team).

I think we should really at conferences be spending more time talking about big changes and how to know when to use them. We should also spend more time talking about how to build a team of the right people. I know this is not as interesting of a topic but it seems there are many more people with this issue than those in cases where they have a well executing team that they want to improve.

This entry was posted in Uncategorized and tagged , . Bookmark the permalink. Follow any comments here with the RSS feed for this post.

5 Responses to Agile Process

  1. Whilst I agree that there is no point in hiring bad developers, I also think there is a tendency to try to make junior developers commercially viable immediately, rather than give them the time and space away from direct commercial pressures to learn their craft. As somebody who is trying to level-up my skills, my feeling is there is only so much I can improve by learning on my own in my own time, and the only real way to step your skills up to is to be learning everyday. Even if I am learning things at home, if I’m not allowed and supported to apply the theory then my learning is going to be painfully slow and limited.

    I’ve always maintained that the only reason to hire a junior developer is because you can’t find a suitable senior developer. If you can’t find/attract senior developers then all you can do is hire junior developers and train them to be seniors. People should not be hiring developers as cheap resource. We all know that good developers are worth orders of magnitude more than bad developers, so hiring juniors because you want to reduce the cost of development is an enormous false economy, in my opinion.

    Perhaps I’m living in a dream-world and few companies will provide the required space and time (although I’m encouraged by one company offering a technical academy). Perhaps bad development is enough for some companies and they don’t feel you get the required ROI.

    The line about not being able to build the wrong thing chimes rather nicely with research on IT effectiveness and alignment, the conclusion being that it’s much better to become effective at delivering before you try and further align your solution with the business, which I’ve heard Steve Freeman mention.

    I suppose there is one case where I would agree that developers must be let go; where the bad developers show no interest in trying to improve. Then I don’t see much option but to replace them. Also, the ability to train is dependent on a company having at least one developer with the appropriate level of skill, which is not always the case.

  2. Dan says:

    i think that there are good developers and developers good at one thing. so as i see it, success comes from the management team: to prioritize, delegate and blend the team in such a way that the person most suited for a certain task will do that job.

  3. Rudy Steinhoff says:

    I agree. These past years since the peak of the internet boom has seen business try again and again to replace knowledge, skill and craftsmanship with process. Attempts to funel development into assembly line practices have not worked. Skill, talent and approach to buiding and maintaining applications takes time, committment and resources. I predict expanding SaaS and Cloud where hosting companies can provide the long-term expertise while the typical IT shop will decline in value to the organization.

  4. Vadim says:

    I think the other major problem with introducing agile into an organization is that the organization doesn’t actually want to do agile. They’ve just heard that it helps improve delivery, but are unwilling to bend their bureaucracy in order to facilitate true agile development. So you get stuck with presenting estimates where scope and time are fixed. Delivering all kinds of useless artifacts and going through change management meetings. However, since you’re doing iterations, you’re doing agile right?

  5. Thomas says:

    On the one hand i agree with you, it’s the easy option to just let go off people you deem not able to work on a certain thing. However it also seems a bit harsh to not let people improve themselves. Not all people are born super-developers! You must have employed them for a reason, no? You have seen their CVs, know what they are able to do, and what not. If you employ them and give them a project they are not able to handle, maybe its also your own fault?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>