Thursday, June 18, 2015

Deliver software and stop methods and tools – Computable

<- Googleoff: index -> <- googleon: index ->

Agile has long been very hot. Was it in the beginning something special today everyone claims to be Agile. But is that really so? And how important is that? Agile really helps in achieving our objectives? Carries an Agile working method really help to devise solutions that achieve or is it just the next excuse? Let’s just do it, that’s crazy enough. It is high time to deliver software

.

In my role as a software (I am co-founder of a software house), we make a call daily along with potential customers. There is a huge desire to work Agile. We meet a lot of software teams on the client side who claim to be all Agile. However, often there is on both sides of the table, so both in the business and IT, dissatisfaction. Software projects do not deliver on what they had expected.

An impasse is often the result, accusations are made over and over again. Frequently we hear stories that the business side but do not understand that they do not come get what they ask for. The IT side complains about all the ignorance and the many disruptions to their development through all kinds of customer priorities

Methods not everything

.

In order to improve the situation , IT departments are increasingly taking matters into their own hands. And that is to be welcomed wholeheartedly. One chooses to work in a different way and thus be more flexible towards the business. Usually one chooses to implement Scrum. In this way they try to finally have promised new release to deliver. But if such a change takes place in isolation, it is doomed to fail.

Forced goes the IT department itself namely closing the business. Opening hours are adjusted to keep the business as much as possible out the door. However, alternatives are not presented towards what the customer is in principle anyway. This allows the business side gets the feeling that the service still fell further, because he can his story now no longer lost

Mutual incomprehension

.

Recent I discussed this issue during a keynote address at PMI-conference. A large group of experienced project managers held massive hand down when I asked if they had a good consultation relationship with the business side of their projects. I found this quite shocking. And it confirms what we often see in practice. The business side has submitted a request, but then does not get what was desired. Soundings of the IT department learns that they have not really understood, but anyway produce something.

Such problems can not be solved by introducing eg Scrum within the IT department. Internal change there or processes, rituals give form and the day the short term might lead to more focus and with pleasure. But in the longer term there will unfortunately not change much. The customer remains dissatisfied. And all this by the simple fact that the business does not feel understood and the IT side will continue to lack appreciation

Additional capacity

.

Another solution elected regularly is a capacity to realize all the wishes of the business. Arrears must be eliminated. An external IT partner is involved in the process and which may provide additional resources. In the worst case, this is the start of a much larger problem.

We all know the phenomenon of garbage in is garbage out. ” An inadequate optimized process is not to spend, you can not solve problems by adding more capacity. Lead times shortened not you with that, on the contrary. Nine women give birth to a baby even in a month.

It’s obviously very dangerous to generalize, but sometimes that is necessary to make things clear. The above situation sketches are based on our long-term experience with customers in several countries. Often we encounter similar situations

Together you can achieve more

.

The question now of course there is a cure for this ailment? Yes, that medicine exists and is often too simple for words. Many organizations only apparently needs an outsider to identify the sore spot. In the majority of cases are business and it simply too long opposite each other.

As such, we find this all probably strange, because we would all have to pursue the same business objectives. The practice is more stubborn. For very different reasons, every department now as his own objectives, which are far from being fully in line with that of the overall organization

Wink

.

Personally, I think it should put this as a first step. By showing interest in the business side can create a dialogue. Genuine interest creates an unprecedented exchange of information. It will find that the customer did not need what he asked. He came with a supposed solution to the problem, but in many cases it appears that the real problem is actually different, but that it had failed to articulate this.

Do customers actually know what they really want, or have in need? Often insufficient. And actually they should also not try to articulate. They just have to, in relatively simple functional descriptions, explain what problem they experienced or what chance to see them. If it involves himself in this situation, they can use their knowledge of existing systems and (new) technical possibilities really how to realize it

Common Sense

Do you have here Scrum and other Agile methods and tools required? No, not necessarily. This is simply a matter of using common sense and together make a good dialogue. These are techniques that we apply together for many centuries. Of course, some do support best practices, but on the condition that both business and IT participate.

An IT department that says to work in accordance with Scrum, but has no product owner, is in my eyes still not really good Agile process. Then Scrum up an excuse and it’s time to just do it and have a good talk

Success

.

LikeTweet

No comments:

Post a Comment