The essence of smart methodology is bridging the gaps

Listening to Ivar Jacobson’s talk about closing the gap between business and IT gave me an idea, what software development methodologies are all about.

During the 50 years of software development we have seen a plethora of software development methods. Every ten years comes a new methodology, a new solution, to the same old problems we have been fighting for the whole 50 years. And will be fighting, dare I say, the next 50 years. One weapon used in the war is development methodologies. But what really is the essence of a methodology?


A lone coder

Imagine you are developing software alone for yourself. You know perfectly well, WHAT it is you want to achieve. You are effectively a business analyst. Also, you alone specify HOW you are going to implement the software. Naturally you write the code and test the solution yourself.

I bet anyone who has wrote any non-trivial software for himself, did find some opportunities to make the software better than originally thought. When you work alone it’s usually not a problem, you change your mind and are happy with that.

You don’t need much ceremony for this to work.

Enter external client

Things get a lot more difficult when another person comes into the game. Especially if the other guy is your client who is going to tell you WHAT to do.

When two or more people work together (you are working together, aren’t you?) they need a way to coordinate their work, share knowledge and find a way to make decisions.

This comes extremely important when you need to agree on WHAT to build.

Bigger team, more roles

Usually as one person turns to an organization and projects grow bigger, more roles become involved in the game. Most often first person to enter is an hybrid of project manager and analyst taking care of the client and telling the developer WHAT to do. What effectively occurs, is more loss of information (according to many studies ca. 50% of information gets lost on a handoff).

Next people to come into an project are architects, designers (telling developer HOW to do) and testers (trying to validate whether the developers did what the analyst told them to do, no matter is it what the client wants, no matter was it done how designer thought). More coders. More clients with conflicting ideas on WHAT to do. More problems. Many methodologies have been born to solve these questions, many theories about teamwork have existed many decades, so we are perfectly suited for a successful project?

Each new person presents new demands for the development methodology.

And the ultimate question is…

So now we have a team of people (without going into discussion on what is the essence of a team) consisting of many specialists perfectly suited to do their own craft. And the team has a client who has a business process to be improved using software. The only remaining problem is that the team should produce what the client needs. And it needs answering the ultimate question WHY. Why is the software being developed? Why is client asking for what she asks? Why is designer proposing a given solution?

To answer that question (and also to further specify the WHAT) business processes are modeled and various diagrams are drawn.

The problem

Developers have their own methods, business has it’s own methods and IT operations has it’s own methods. Unluckily, there’s very little common ground between the different stakeholders. There are huge gaps between the different sides. And after a few thoughts, we find that our specialists-driven team has also many gaps: designer doesn’t understand what each decision means development-wise, developer doesn’t understand the UI designer etc.

We need something to help us bridge the gap or even better, remove them totally.

The solution

Each project has it’s very own characteristics: it has a unique combination of skills, unique value definitions, unique scheduling, unique state of the world and – what’s most important – unique human beings. This means that the project needs to find a way to work effectively together under these unique circumstances.

I have written before on cross-functional teams. But it doesn’t stop on the software development team. We need a cross-functional business development team. Most software is written because of business change, and as business changes continuously, so do software.

For any project to succeed it needs all the stakeholders speaking the same language, sharing objectives, collaboration, building trust and enabling business agility. Real methodologies always try to find practices that bridge the gaps between end users and client, between client and analyst, between members of development team etc.

“The essence of Lean is thinking in context” someone said. I couldn’t agree more. Thinking in context is the very essence of software development. We have come too far in determining readymade methodologies. Think in context, define your own methodology for your project and bridge the gaps.

Afterthought

A football team consists of highly trained specialists. They have goalkeeper, defensemen, middle-field and the forwards. Each one is focusing primarily on his role. What is the difference between a football team and a typical software development team? Each member on a football team know how to play football! Every single player can kick the ball, they know the strategy, the are able to serve the ball, they know how to tackle the opponent etc.

Typically on a software development team you find testers who can’t write code, you have designers who can’t write code, you have coders who know nothing about user interfaces (or even the users…). Why is that?


Tags: