LeSS framework and architecting

LeSS framework is basically Scrum, only scaled-up. It is more an additional set of rules and a really good explanation on how to apply Scrum in a scaled situation and still remain effective, than a framework on its own. This is especially evident when compared to other scaling frameworks. LeSS can be used to work effectively on a single product with multiple teams, and even thousands of developers.

less_frameworkA particularly interesting part is the emphasis on technical excellence. It is one of the extremely important aspects often neglected in Agile introductions. Among things like clean code, TDD, continuous delivery, the framework also describes the way we should deal with Architecture & Design in a very refreshing manner. Instead of creating additional organisational structure, roles and artifacts, Craig and Bas give a number of tips.

Think ‘gardening’ over ‘architecting’—Create a culture of living, growing design

This metaphor is intended as replacement for the building metaphor, which is usually used to describe what architecture means. The software systems are grown by incremental development, not built.

The rest is a large set of useful tips and direction of thinking when dealing with large scale Scrum. Here are few of these:

It is so important that every act of agile modeling and programming for the life of the system should be treated as an architectural act.

Standard whiteboards are possible but not usually sufficient–and in fact are often an impediment, because modeling is best done on vast open wall spaces without borders.

Encourage everyone to question and challenge all these assumptions [early architectural choices] and decisions, and to find ways to apply the lean thinking principle of decide as late as possible or defer commitment.

Technical leaders teach during code reviews.

Communities of practice (CoP) are an organizational mechanism to create virtual groups for related concerns.

Internal open source with teachers—for tools too

Don’t use stubs to delay integration

This should be captivating enough to make you visit the site.

Teams in the driving seat

Two weeks ago, InfoQ published our article about many experiences with Scrum at Port of Rotterdam. Several people contacted me afterwards with questions and one of them was an IT manager in a large organisation. He made a very short and interesting summary:

So, developers / teams are in the driving seat!

This characterisation is pretty good and can be used as a test for knowing how Agile your teams really are.

ford-biometric-seat-wellness-driver-research-detroit-lee-test-540x334

Very often, “being Agile” is confused with having teams following some set of practices “correctly”. That could be XP practices, Scrum practices (3 roles, 4 meetings), or something else.

“Teams in the driving seat” means that in a large organisation, information and artefacts are pulled instead of pushed. In a big enterprise, business has some need, which is usually pushed to IT management or product owner, translated by (business) analysts, pushed to Agile teams, which deliver a product in increments.

In case of really effective Agile teams, the need is much more pulled than pushed. The business still pushes the high level idea, with its very limited definition. After this, the initiative is taken over by teams. This switch may happen with a statement from the product owner:

My need is ….. Please enlighten me if this is sensible and what more you need from me so you can pick this up.

From this moment on, teams are in the driving seat and request or pull everything they need in order to deliver value. They are the ones actually deciding which information needs to be gathered, questions answered, artefacts delivered, process followed, and so on. They may request assistance from domain experts, BA’s or architects.

For large organisations with strict processes where first architects and business analysts are involved, direction actually set by IT people instead of business, different levels of management approval is needed, this is a major change in behaviour.

So, next time you hear someone telling you about their Agile teams, ask them who is actually driving the car and who is giving directions.

How to make software architecture decisions?

Today, a friend of mine asked me this question. We both know how companies usually make architectural decisions, but how Agile teams (should) make significant architectural decisions is less obvious. A difficulty with this question is that answer has many perspectives: one could talk about business need, technology choices, documentation, who is involved in decision making, how they actually do it, what kind of meetings, etc.

Image

Continue reading

Agile team without a purpose is a truck without fuel

Why do Agile teams fail and others are extremely successful? Why the rest of the world thinks Europe is a good thing and Europeans are blessed with so many achievements, and only 58% of Europeans call themselves Europeans? Why do you have trouble getting out of your bed and going to your work?

Image

There could be multiple reasons. For a team to be really successful we need craftsmanship, trust, fun, transparency, and a purpose. The things a Scrum Master or an Agile Coach does, has always to do with one of these aspects in some way.

Let’s be honest. Most self-named Agile teams are slightly more successful than teams working in waterfall projects. Hopefully, customer is very happy with some visible improvements: faster delivery, better quality, changing requirements is ok, and maybe few others. The tendency is to spend a lot of time on tuning and improving these aspects, which is good.

I’ve noticed that one thing is very often lacking, and it has a tremendous impact on other aspects and being successful. It is a clear purpose. The purpose is expressed in many different forms. One calls them vision statements, others mission statement or project goals, or even business value. Today, any project or team, Agile or not, has a statement representing a purpose. Unfortunately, most of them are worthless, defined by management and ridiculed by the teams.

One might say, who cares!? Let C-level people define vague statements for their own pleasure, while teams build the real thing. Unfortunately, the reason why you are having a hard time getting out of your bed and Europeans don’t like their Europe is this lack of purpose. Despite the amount of fun, craftsmanship, your large salary and so on, this all will also be affected if purpose is not embedded in everyone involved. I believe that lack of good purpose is one of the most important reasons for teams to fail, and one of the most neglected problems. I’ve seen problems and discussions not being solved simply because the root cause was lack of purpose: “Why are we building this?”….”Because the customer really wants this”… Applying the practice of asking ‘why’ question 5 times will often end up in annoyed customer or product owner. Team might finish the meeting as if everything is cleared up, but what really happened is acceptance of the wishes of the customer, while the ultimate purpose is still unknown or even wrong. The effect is lack of energy and involvement. In worst cases, teams are chasing the wrong goal. One of the most awful experiences as an IT professional is when you spend years chasing a goal, project is suddenly killed and the imaginary goal has simply vanished.

The following is a number of common mistakes when defining a purpose as a vision statement or whatever you want to call it.

#1 : The stated purpose is a misfit with a personal purpose

The reasoning why your team member gets out of his bed can be visualised as a tree. The roots are the personal reasons for living and not very visible to others. These might be very complicated and different from person to person, but the commonality is doing something meaningful for ourselves and even more for others. Doing something meaningful has different interpretations. One wants to get wealthy in order to support her family and chooses to work in banking business. Someone else, or the same person might change her interpretation during her life time, and gain new insight, like from getting wealthy into doing ethical banking – e.g. investing in renewable energy sources, and refusing to work for banks that support arms industry.

We tend to spend much more energy into something if it fits our interpretations of word meaningful. Unfortunately, this is often neglected when defining something like a vision statement. Leaders have egocentric tendencies where they feel that their purpose is or should be the same as purpose of everyone else.

I remember the moment I decided to leave a company when CEO was giving a speech where the main message was something like this: “We should be grateful that we are doing better than our competitors, but hard times are coming and we need to be careful with costs we are making. Even more important, every professional should be doing billable work. Also, as you can imagine there won’t be salary increase for anyone. We should be glad, because other companies are talking about lay-offs constantly”. The reason for me to leave was not the money, but complete lack of purpose I was somehow expecting at that moment.

In this case, CEO is actually doing his best to make a fit with the purpose of his workers, which is sense of security. For some this was a good and realistic speech, but most simply didn’t care about it at all. We are talking here about highly educated craftsmen / women with huge experience. They are unlikely to feel insecure. This was noticeable during diner after the speech. This kind of pointless statements and speeches usually end up in no reaction at all or sarcasme and ridicule. Effect on energy levels: they become even lower.

#2 : Vagueness and lack of distinctiveness

So many times I would read a vision statement for a software product and ask management why is it so vague and open to interpretations. The nr. 1 reason they state: “It is a compromise, and we want to have space to move in any direction we wish as needed.”. Ironically, they are not yet familiar with Agile software development, but it sounds like they are. If there is one thing that should not change, it is the purpose explained in the vision statement. Explicitly making sure the purpose behind a statement can change as needed, makes it worthless.

The main reason why companies choose to have vague vision statements is the lack of purpose. If the common purpose is there, it should not be difficult to write it down in more precise words.

On company level, by far the most vision or mission statements are talking about shareholders value and satisfying needs of the customer. The exact same statement can be used for almost any business. The statements like “Blabla company places customer at the center of our business” has a value only when explained further in the context of this specific company and its business. I hope I don’t have to explain why “shareholders value” is completely uninteresting to employees.

Another problem is that vision statement looks like a result of many loosely coupled fancy words. The thinking is: if we leave something out, it will be somehow overlooked later. For some reason, the goal becomes to be comprehensive instead of inspiring.

#3 : Disconnection from daily deliverables

Let’s say we have a really nice purpose, and everyone believes in it. We start delivering first features of a product. Suddenly, after few sprints, product owner was pushed by stakeholders to deliver something completely outside of the scope of the stated purpose. According to Scrum, Product Owner has the right to do this. Nevertheless, team is confused. “I thought we had this other goal which was more important than anything else?”. PO: “Yes, but this is an exception and I don’t have much of a choice. We have to do this”.

The reality of this example is usually much more subtle. Let’s say we have a nicely stated MVP (Minimal Viable Product) and speed of delivery is crucial – the sooner, the better. This drives any daily decisions team makes together with Product Owner. Any decision should be scrutinised by team if it fits within the stated goal. It is a responsibility of Product Owner to be very careful with any deviation from this goal even slightly. These deviations are not wise for two reasons. One: stakeholders are obviously not fully in agreement what the goal should be. Two: team becomes demotivated.

Conclusion

Although most vision and mission statements are ridiculed and seem completely useless, the real purpose for delivering a product is still extremely important to be truly successful. Lack of common purpose is a hidden impediment. It must be made visible and discussed openly. A team should be able to give feedback, or even better, formulate vision statement together with product owner and stakeholders. There are several practices that might be helpful in this process. One of them is The Product Vision Statement – from book Crossing the Chasm, Geoffrey A. Moore.

I want you to ask your manager or product owner right now: “Why should I put my energy in making this product?” If his only answer is: “Because I pay you to do so!”, then you should be looking for some other challenge. Life is too short.

The Dutch government massively failed IT projects openly discussed

Image

I usually write about different details of doing architecture in an Agile way and other related topics, but the reality of outside world is that Dutch government loses between €4bn and €5bn on failed waterfall IT projects. This is definitely a problem in other countries too.

As far as I know, this is the first time huge failures in governmental IT projects are discussed so openly. A parliamentary committee has questioned today five people from IT industry in the first day of enquiry. The first one was Hans Mulder (a professor at the University of Antwerp) who gives some hard statistics:

Just 7% of the projects with a budget starting at €7.5m can be said to be successful, Mulder told MPs. In total, 70% of projects fail. Of those which flop, 36% fail so seriously the new system is never used and around half are of doubtful value because they turn out to be too expensive, take too long or produce unexpected results, Mulder said. – source: DutchNews.nl

Second was Stephan Corvers (owner of Corvers Procurement Services BV). The main subject was about procurement process. His expected opinion was that failures have little or nothing to do with procurement process itself. According to him, the customer should better describe what is wanted before starting a project. In other words, more of everything what is already being done. The most noticeable is vagueness of words and statements he used when answering the questions. “Frames….bla bla….framework…frames…bla bla”. At some point a MP asked: “Frames?….euhm what?”

Third one was prof. dr. C. Verhoef. He explains clearly some real and painful issues in those failed IT projects. His main point is the lack of proper knowledge in IT industry. Nobody is willingly contributing to failures, but rather “the road to hell is paved with good intentions”. IT people are lacking knowledge to successfully deliver. Another point was lack of third element in procurement process, which is quality. These big IT projects are given to software companies based on cost and time aspects. In all kinds of games played out in this process, something perverse is happening. The companies which are capable of delivering and know the risks usually loose the project to competition, which neglects the risks or play the game of underestimating and compensating later and in the process make the project much more costly or complete failure for the customer.

It was a nice analysis of the problem, but solution was a bummer. His suggestion was to specify even more (quality aspects) before the procurement process starts. From my own experience, these beforehand “ilities” are always made up by some group of architects in their ivory tower. The effect of this is possible creation of even bigger problem – overcomplicated architecture driven by quality aspects that have little to do with reality. Another suggestion was to split up these big projects in many smaller ones.

Fourth interviewed was Tony Wildvank (ex-contract manager for large IT projects in government). Her main point was that we need more architecture and involvement of architects before we start. What she actually says: even more documents, theoretical analysis, and so on, before starting to deliver anything. The rest of her statements were either unwillingness to answer the questions because they were too sensitive or full of vague statements like with Stephan. Statement like: “software projects are same as process of making socks in a factory” is a sign of huge amateurism and lack of knowledge.

Fifth and last interviewed today was Swier Jan Miedema. He is an entrepreneur with 20 years of experience in working for or directly with companies like Centric, Logica, and Ordina. He is the embodiment of the pain many honest IT people have in Dutch government IT projects. Many of his statements were maybe too honest and too personal, but he is one of the few brave enough who speak out in such way. I really wonder how this will effect his future business.
His was really appalled by atrocities of big and well-know software integrators in Netherlands. According to Swier, IT projects in government are controlled by these companies. They define what happens with IT at municipalities.

I love his solution. Vendors must prove they are capable by delivering something in one week. If not delivered, they are not paid. After this, close collaboration starts where vendor continuously proves its capability by delivering frequently. He did not say it, but it was obviously Agile he was talking about.

Altogether, I was disappointed and sadly confirmed in my assumption of extreme amateurism in these multibillion projects. Insanity is mind boggling. A clear example is that nobody thinks of splitting a large project into many smaller ones. Even some of the interviewed people are mere confirmation of this amateurism. Some pretend to know how to successfully deliver such large projects. More architecture, better specification, better control, and so on.

The Dutch IT world seems to be completely divided in people constantly discussing why those big waterfall projects are failing and Agile world. They don’t interact with each other much.

Agile: Leadership without titles

This was title of a lecture I gave at The Hong Kong Polytechnic University, or in short PolyU. I’ve been asked to tell my story, and how I got where I am right now, related to leadership. Am I some kind of a well known leader to talk about this subject? No, I am not. At least not in the way many perceive words leader and leadership.

Image

The message was that looking up to or becoming a leader has a flip side. I’ve been through one of the most extreme ones in Bosnia, where leaders pushed people into war against each other. A more subtle one is the way most businesses are being managed. In Hong Kong, but also in the rest of the world. In most companies, we have people who think or manage, and others who execute as being told. Distinction between the two is very clear. There is this whole notion that people on the floor know much less, and are less capable than people on the top. Of course, this has also become a self-fulfilling prophecy with certain level of acceptance. People on the floor are not encouraged to be creative, think for themselves, but follow the process defined by “smarter” people. It is defined by Frederique Winslow Taylor about 114 years ago in his book “The Principles of Scientific Management”. Not much has changed ever since, or has it?

Well, yes. Many changes are taking place in this area and some of them, like Agile Software Development, are making a dent in this old-fashioned way of thinking about people. A nice “side-effect” is that people who have broken with these old rules, actually deliver much better quality faster. Or better to say, they are more effective.

Who is “they” in this case? They are Agile teams. A groups of people holding certain values, like collaboration, trust, and respect. But, what makes these people really effective in business world is the sense of leadership in each member of the team. Team members are continuously encouraged to improve, be creative, place people above processes, take initiative, bring ideas forward, convince others, and so on.

These are the leadership qualities. They are not based on titles, but mutual trust, respect and power of arguments. In these environments, the Taylor’s world is upside down. The traditional leaders / managers, are taking more facilitating role and following the wish of the teams. I have become part of this, in the past 15 years, and will never leave it.

Image

After I told these 18 year old Hong Kong students about basics of Agile and Scrum, the most interesting thing happened. I’ve received about 100 questions, written on paper. These questions are much different from questions I’ve received in any workshop, training or a masterclass I gave before. At that moment I’ve discovered that if I’m able to answer these questions, I will learn a lot about why we like this thing called Agile and also about myself.

In the following posts, I will try to answer those questions, one by one. The list below will be updated continuously: