agile

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:

Is there a such thing as an Agile solution?

Today, many software product vendors have placed word Agile in front of the original name of their platform. If this is a proper use or misuse of word Agile, is up to you. The discussion about it might be useful, but I’m interested more in how good each of the platforms support Agile values. For anyone to assess this, a set of principles is needed. These principles can be used by Agile teams to better decide if a certain platform will help achieve your goals or stand in your way. So let’s start:

1. It is the team that makes architectural decisions. A platform should be capable of fulfilling these decisions.

Many platforms have so called out-of-box architecture. It means that significant decisions are already made and defined by the platform. In this context, significant decision means any decision which strongly influences the structure and look of the solution. I am not talking about the commodities like messaging systems, application server platform, database, and so on. There is a certain, hard to define, line between what is a commodity and what not. The significant decision here is still wether you want to use certain commodity platform / component or not. But, you almost never want to mess with inner workings of such components. Directly, they have little to do with your business problem domain. This is often not the case for things like BPM tools and ERP platforms. Why not? They tend to intrude the space of the only people who are really capable of fulfilling the business need, which are Agile teams themselves. Signs of this problem is when platform has very specific ways in which certain business requirements are solved or no capability at all. Let’s say: if you want to do payment on your website, then you must use a specific module for these credit cards.

2. If you first need to spend time on implementing some kind of baseline without direct value for business, then it ain’t Agile.

Welcome to 21st century where you still have vendors who try to convince you that you need to be patient for half a year or a year. You spend 500.000 euros before seeing a failure, because of your own fault. “You shouldn’t have changed your requirements!” or “You should have known your requirements before you started!” – says the vendor in a court. Forget the promises, if your team is not capable of delivering value in production in one sprint, then the platform does not belong in this century.

3. Is a platform capable of delivering in production continuously?

I must admit, although I do know how difficult can be to properly deliver things in production, I almost get convinced by those sales presentations where things look like magic. A few hard questions later and this magical stuff proves to be nothing more than hot air. Until your team actually experiences and exactly knows how to deliver solution every couple of weeks (preferably after every check-in) with little effort and high quality, don’t trust those nice looking PPT pictures.

4. Craftsmen deliver value, not platforms

First statement on a typical vendor site begins something like this: “With our software you will reduce costs, speed time to profit, get real time visibility,…” and so on. I should make a software to produce these generic statements, so all these vendors can reduce their costs. 🙂 It sounds like a good business case. Anyway, no software implements itself. Even a rollout of MS Office can become a mess if you don’t have craftsmen knowing their stuff. In other words, no software platform ever delivers business value. It is the people who actually know how to use this technology in specific context. As a customer, if you want to be Agile, you should spend more time on hiring great craftsmen, and less on which platform is the correct one. This should be the job of the hired craftsmen and not yours. In that way, your team might fail to produce value and be held accountable. Blaming a platform, never really works out in customer’s favour. Specially if vendor behind it is one of the largest ones.

5. The team should be able to refactor most of the previously made decisions and implementations?

If anyone advise you to make many difficult and important design decisions before starting delivery, because otherwise you will get in trouble later on, then your platform is not Agile. If business changes their mind, the platform should not be the bottleneck. Again, it is the 21st century, and you don’t want to say No to your customer and users because of the platform.

6. Can you automate testing?

One of the main reasons why Agile teams are capable of delivering every couple of weeks or even more frequent, and still maintain high quality, is because of test automation. TDD, BDD are few of these amazing practices that improved quality of our solutions tremendously. If you cannot automate the validation of everything before every delivery, then your platform is definitely not Agile.

7. Last but not least, if your craftsmen don’t like the platform, don’t use it.

It is very disturbing to hear people treat developers like some children who get bored with their toys. Although many developers lack skill to properly argument their dislike of certain technology, there is always a truth in what they are telling.

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.