Monthly Archives: October 2012

Some Thoughts on Agile

Big risks, if not the biggest risks in a project are:

  • Unclear requirements/ shifting scope – because you don’t know what to aim for, or you aim at a moving target
  • Large head count – because communication becomes an issue when things don’t fit into a single head
  • Absent/ unwilling customers – because the solution will be out of touch with what is needed (not to mention that “customer” often enough is not equal to “user”)

Many projects fail for these reasons. It would be very helpful to not have to work under these conditions. It would be helpful, too, to only have really good people on the team.

Unfortunately, many projects have to operate on this basis. Requirements are sketchy, but management demands a project plan in the first week of the project. Some project are large, because there is a ton of stuff to tackle in limited time. The people who hand you the requirements are often not the people who have requested the system, or the ones who are going to use it. And, especially in big companies, developers are a broad cross-section of the spectrum there is.

Now, if you look at the opposite of these detrimental factors, you get a good portion of what Agile is about:

  • User stories that describe what the customer wants. Maybe not in great detail, maybe not completely at the start, but this is what iterations are for.
  • Small teams, maybe a dozen people
  • A customer who is always present and cooperates, giving feedback all the time (and who has the authority to do so)
  • Highly communicative, capable developers who share a common, Agile mindset

Well, this is why I like to work in an Agile environment, too :-) I lead successful, agile projects under the prescribed conditions. I suffered like any others in big projects where the sheer amount of required cross-team communication stifles every move.

How to put this nicely… Any project that fits the second list of factors will have a much higher chance of success than a project plagued by the first list, no matter what approach is being used.

I have the impression that, at least to a degree, Agile increases project success by excluding major risk factors (please read on).

If that exclusion is by definition (“let’s only look at projects that fit the definition”), that is a cheap way to success. If a Marathon would be only 5 kilometers long instead of 42km, it would be much easier to run.

If that exclusion is by changing the approach (“let’s do it differently”), that is what Agile is about. The tough part is that places that attempt huge projects in a waterfall fashion are not exactly fertile ground for Agile approaches.

What gives?

  • Agile defines a setup which is more likely to succeed, because it tries to get rid of certain major risks
  • When a large projects with unclear scope and absent customer gives you a headache, Agile likely is not the solution to use in the situation, you would need to change the situation
  • Should you see statistics that Agile projects have a higher success rate than conventional approaches, be aware that this may be owed to the fact that the projects done Agile inherently were less risky from the beginning, and that the big nasty ones were not even attempted in an Agile way.

So, try something new by changing the way you start and execute a project, not by trying to sprinkle a new method on a doomed setup.

Where Do (Software) Architects Come From?

Where do software architects come from? There is a simple, obvious answer, but that is not what I mean :-) I am referring to company environments. I can’t help noticing that more often than not, architects come from one of the following sources:

  • Architect by appointment” (not skills). Somebody got promoted to be the architect (implying the role carries a higher value than that of a programmer), or somebody got simply pointed out
  • Not-so-great programmers who are thought to be good enough for “drawing boxes and lines on an abstract level”
  • Programmers who are so far removed from the trade they don’t have the insight any more what their options are, and what impact their decisions have
  • Non-programmers who, well, can’t code and therefore must do something that does not require coding

That is weird, assuming you choose your architect to help, improve, complement the implementation project on a level that is different from that of a programmer.

But maybe those who choose architects don’t know what to expect and what to look for. There is evidence for that: companies often don’t educate their people to be architects, or even have an expectation (that they communicate).

I can only offer my own standpoint: An architect is a person dedicated to looking at and being responsible for the quality aspects of a software project.

What kind of qualities? I would stretch that pretty far: Can the structure of the system be easily understood? Does it fit the purpose of the project? Does it address the problem and the constraints of the environment in a fitting way? Does it reduce the impact of changes to the requirements or infrastructure on the system?

While programmers must address quality issues, too, they are primarily occupied by translating functional specifications into technical reality (which is why code generation will not happen before arbitrary natural language can be understood by a computer), and wrestling with the intricacies of highly complex APIs, other people’s code, and their own.

The architect in my opinion must be a seasoned senior developer who knows what works, knows what doesn’t, and understands and can explain why that is so. S/he, too, has the (urgently) necessary people skills to promote good architecture, to convince management that additional effort will pay off, and to convince programmers that the marching direction is the right one.

You can’t study to be a “software architect”, though there are certifications. There are some great books that for sure can help. I believe a certain attitude to programming, long experience in many various projects, being awake at the IDE, and musing about why things went the way they did are a good base.