scrum

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.

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.

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:

Should we blame methodologies?

It is often said: You can’t blame a methodology for not being used properly. Well, yes you can. Consider the fact that everybody’s intention when using one is to succeed. Nobody wants to fail in delivering a software product. The promise of any methodology, even any waterfall methodology, is to deliver value sooner or later. Any failure starts with a choice of using one or multiple of these methodologies and buying into their promise.

Some say, one should have enough knowledge to apply a certain methodology. If not, one is responsible for the failure and not the methodology itself. This does sound tempting until you consider the fact that people who preach this are paid a lot to explain others how to properly apply the methodology. Nevertheless, even after applying methodology according to every recommendation, failure is still there. Ironically, very often because of huge effort being put into doing methodology in a proper way at cost of delivering actual value as soon as possible.

Some say, software development is like manufacturing. Therefore we have all kinds of Software Development Factories. Software developers are factory workers with limited focus and knowledge and therefore need a process, which will guide them towards delivering a product. I guess anyone who does software development in today’s complex world has found out that treating software developers as factory workers constrained by a strict process is a recipe for failure. Besides, it would be more realistic to consider software development same as trying to land a jet fighter on aircraft carrier for the first time than a factory.

It is the fault of a methodology when people use less creativity and less improvisation to deliver value, because methodology discourages them to deviate from rules. It is the fault of a methodology when people are only concerned about their always limited set of tasks and responsibilities assigned to their role.

Some might say, no methodology says we should be restricted in any of these aspects. True! Still, mere existence of a methodology introduces certain limitations by definition. Bigger, more complex methodologies tend to be more limiting than simple ones. Even if everything described in a methodology is called only a practice; and each of the practices can be used but can be skipped too. When used, people will call these practices: the best practices. Who can argue the usage of a best practice? People are discouraged in adjusting the process. Not because it is not allowed, but because of the assumption that they are less capable of setting up a process in their situation than people who spent a lot of time and effort in creating this great methodology.

Does this mean we should not have methodologies in software development? No, it does not. Certain guidance is always needed, and we definitely need ever improving and new practices. But, there is a difference between having rules defined by people who use, change, improve these rules; and imposing these rules on people. There is a difference between having a methodology as a mean to help people deliver more value and hiring people according to roles defined by a methodology.

Every methodology or framework has this problem. Even XP, Scrum or Kanban. The most important reason why these are so much simpler than others is to encourage people to think and be more creative in every possible way. In fact, there is so little really described or prescribed in these that for successful teams methodology is just a detail, a sideshow. Doing scientific research on how successful Agile methodologies are proves to be very difficult. Why? It is same as trying to determine wether Mandarin is successful language in doing business. To have a common language is crucial when doing business, but rather irrelevant detail in the whole process. This is different for large methodologies, where methodology itself is an important factor. Agile brings us more success not because of better methodologies, but rather because we have less methodology.

Still, many organisations are imposing Scrum on people in same way as they did with previous methodologies. Suddenly, many of often used practices have become the only way to do e.g. Scrum and XP properly. User stories, poker planning, TDD, specific meetings, burndown chart, Scrum of Scrums, pair programming. It gets much worse when extended by DAD or SAFe. LinkedIn forums are full of discussions about which of these are better or how to use them properly.

Don’t get me wrong. I give trainings and coach teams in these practices because they are so great. Nevertheless, if we keep giving methodologies the front seat at cost of people, we will keep blaming methodologies for failures. There is a huge difference between giving a “why” behind each practice and simply explaining how it should be applied properly. A team can only become Agile if team members understand “why” behind every practice they use.

So, the next time you say “Scrum has failed in our organisation!”, ask yourself what exactly did you or did your organisation do. What or rather who is to blame?

We are the Borg, our role is Architecture Owner!

I was usually the guy who facilitated different architecture related sessions at HaMIS – Port of Rotterdam. As soon as I was absent for few weeks, nobody organised them in those weeks. During retrospective meeting, several of them would mention they missed those meetings and blamed themselves that nobody thought or took responsibility for organising them. The simple conclusion and reason for this problem was: Viktor usually organised them, and he is the architect.

Every now and then I get in discussion with people about different roles we have in software development. For example, it starts with explanation that Scrum needs someone to be responsible for architecture. That role is named e.g. “Architecture Owner”. Then I try to explain that from Agile perspective, we would like to have whole team feel responsible for the architecture. Having one guy call himself architecture owner, tester, analyst will clearly contradict this goal. The answer is then: Oh no, there is no problem at all. We just need to have architecture role and it does not need to be one person. It can certainly be fulfilled by whole team.

Theoretically, it is possible to have multiple people fulfilling one role. The interesting thing is that nobody really does something like that in reality. It is just confusing. You either have specific group of people with dedicated responsibilities as a group with specific name (Scrum team, architecture team, Centre of Excellence, etc) or a single person. I never heard group of people say about themselves: “Our role is architecture owner!” or any other role in that sense.

So, what is the point of having a role if whole team should fulfil it?! It is just a responsibility or discipline that needs to be taken care of. What is this need to introduce new roles? The suggestion that with such role team would better take care of architectural aspects does not make much sense. Teams might need knowledge and experience to fulfil their responsibility for certain aspect as architecture, but that has nothing to do with ownership or having a role.

In contrary, teams tend to neglect certain responsibilities simply because someone else is appointed and granted a role called blablabla owner. How ironic, the whole problem of taking responsibility is actually created by people whose intentions are to solve it.

It it were some very specific task, which requires knowledge very few people have and it must be done properly, I would understand. But, architecture is one the most important disciplines in software development. It is extremely important that whole team feels responsible and most team members should have the knowledge for dealing with complexities of architecture. The reality is of course that many teams do not have this knowledge. Very often this proves to be the cause of total failure of an Agile team. There are many ways to solve this problem. Introducing a new role is not one of them. It merely maintains suboptimal state of having one or few people keeping responsibility from the place it should be.

Agile and Scrum in Hong Kong

In short, Agile is starting to take off in Hong Kong. Others might say, it is not really happening here (yet), depending on how optimistic one is. While in America, Europe and even other APAC countries, Agile software development is widespread, Hong Kong is a quite different story.

Image

Dinner and gala for ICT CEOs of Hong Kong.

Why? There are several reasons. Most people associate Agile and Scrum with software development, and there are less software development companies and software developers in Hong Kong compared to neighbouring countries. It seems that most software for Hong Kong customers is developed in India or Singapore.

Another reason could be cultural. Software development as craftsmanship seems to be less valued in Hong Kong than in other countries. Also, there is this obvious hierarchy, where management takes decisions and subordinates follow up. Actually, this seems to be only the symptom of much deeper difference with e.g. Europeans. Higher ranking people, both in private (parents and other older family members) and business life, are much more respected than in Europe. This very nice cultural aspect, has a pitfall. It is quite difficult for teams to take substantial decisions without simply asking the boss what she wants. This makes introduction of self-organising teams easier if management actively and continuously approves and (co-)facilitates the coaching process.

Hongkongers are hard working people. Working more than 40 hours a week is very normal. Children are brought up in relatively protected environment, where hard work and obedience are being rewarded. Typical Agile guys in self-organising teams are rather assertive and opinionated, and don’t really like working hard. Instead, they like to continuously improve effectiveness of their work. In other words, achieve more while doing less. There is of course nothing wrong with working hard. It is just that in order to be more effective, very often we have to slow down and retrospect on what is happening. This might feel like waste of time and awkward.

Also, people are very eager to learn new things. Preferably by listening to a lecture or some other form of teaching. Unfortunately, there is not much to learn about Agile and Scrum unless you actually start doing it as soon as possible. Becoming Agile is more about learning from experience, and less about learning from others.

I’ve also wondered if delivering a software solution here in waterfall approach is simply more successful than in Europe or US. Therefore, an Agile approach with faster delivery would simply not be needed. That is definitely not the case. The problems with disconnected business, large IT projects, mostly outsourced and managed with thick contracts are same as anywhere else.

Comments on the subject are very much welcome.