This is part two of this series about the importance of having the same vocabulary and today we will dig into the somewhat infected word PROJECT, a word that is mostly rejected in our Agile world. And when a common word with a meaning is not used, then it is very difficult to discuss why it was so bad and why the new is so good, and how the new takes care of all the ancient bad. For the details of the history of the evolved way of working in our organisations with the introduction of projects to keep up with the market changes, please see this blog post series.
But this blog post will elaborate on what the word PROJECT really means, to be able compare traditional way of working and Agile way of working. Here is a clear definition of PROJECT from Cambridge Dictionary [1]:
project – a piece of planned work or an activity that is finished over a period of time and intended to achieve a particular purpose*
It is important to state that the all organizations are systems, which makes the purpose common for all the people in the organization, a purpose that they strive for together. Each of the initiative (project) made by the organization on the other hand fulfils only a particular purpose, in order to fulfil the common purpose of the organization, or the organizational purpose. This is why “common purpose” has been used throughout System Collaboration in the definition of an organization.
As we all can see, this meaning clearly states that there is no difference on this high level at all between the traditional way of working and the work done in our Agile world, or any other way of working, no matter context. The reason is that the definition is WHAT, not HOW. In the definition we can see that there is people (most probably 😉 ) doing activities, and for you that have been following this blog book, know that this is close to our system start definition for our organisations, “People that interact to solve activities with interdependencies for a common purpose”, see this blog post for more information.
What happens when we doom a use of a common word, but we still are doing its meaning in disguise, means that we blur our intentions of what we are doing, because we try to say that we are not doing the meaning of the word at all. This is treacherous since our new way of working, Agile in this case, really does not state what was bad before regarding the word project, and what is done differently in Agile to take care of all the bad things that the old way of working with projects did. The only thing stated is that our way of working in Agile is not projects, which is very obvious that it is not the case according to above definition (WHAT) of the word project. The only thing that really can be stated is that the way of working or method (HOW) is different from before. And with familiarity about both traditional and Agile ways of working, we know for sure that they are different.
The Agile thinking is a new fresh wave taking care of the people in the respective teams, by respectfully letting them take care of the HOW to do their work themselves. The traditional way of working many times had too much micro management from both managers and project managers, which interfered too much with the team’s work, which also made the team members felt they were not trusted to understand themselves how to do the work. So far so good, when we talk about separate independent Agile teams.
And as we also can see, the definition above is neither stating how long a project can be. In Agile, we are doing small projects in every sprint, meaning that the main difference to traditional projects is the length of the planned work, even though traditional projects also are divided into phases, sometimes unnecessarily long even regarding HW projects.
Since the definition is not stating how long a project can be, this means that it can be the total of needs to be achieved or a very small piece, a part of the total, or anything in between. This means that the definition indirectly is, neither stating how to scale the organisation, if the original piece of planned work is too big for one team and you need several teams working together to achieve the original aim, nor if the smaller pieces have interdependencies between each other or not. The former depends on the size of the project and the latter of course depends on context of the project. A production line has only consecutive processes so there is never any interdependencies, meaning that size of the total task never matters in production. But, for product development there are always interdependencies, no matter if your teams are I-shaped or T-shape, which means that the total size of the task matters significantly, see this blog post for the details on the importance of looking at the wholeness. The interdependencies are really important to take care about and is the reason why our system start definition contains this word also.
This means that planning, which is part of the definition of project above, always need to consider interdependencies that depends on context, which is elaborated on in this blog post series, deeply digging into production, Agile and waterfall way of working. It also indirectly gives that we will get more interdependencies when the original piece of work is broken down into smaller pieces. This also gives that it will be harder to achieve high Flow Efficiency without planning the pieces, see this blog post for the details about the treacherous Flow Efficiency problems in Agile teams, especially at scale. We also understand, that the smaller pieces we do, the more effort we need to put on coordinating all the pieces, as well as losing time for all the context switches our people need to do, as well as that our people losing the Big Picture.
The definition of project also indirectly states that there is no complexity involved. This since complex problems may not have any solution at all, and even if we find a solution by experimentation, we can never know when, and we can therefore not plan the total task. That also cope with the traditional HW projects, which are started after the complex work within research has been finished. We can also say that the traditional SW Projects did not really cope with the definition above, since Customer Pull many times consist of complexity, see this blog post for details.
By only looking at the definition (WHAT) of project, all above together give us many direct and indirect implications, and we can draw the following conclusions when we adding also some differences in the HOW, regarding the original true problems with the traditional way of working and if Agile way of working has solved it or not:
- Problem: The traditional projects are often too long, with too big deliveries in the end of the project, which especially can be seen in medium- and big-sized companies. But, remember that HW still have long lead times, as well as a non-flexible architecture as soon as it is reaching the customer, so small and fast features adding value to the customers are not possible then. The solution to this is to have platforms, like in the car industry, see this blog post for an elaboration on that.
Solved: In Agile way of working, the focus is on delivery on smaller projects, or features that can be delivered fast. But, remember that the architecture is still important, since carelessness with the architecture gives future problems, with slower and slower delivery of features; sloppy systemisation as Mary Poppendieck would have put it.
- Problem: But traditional projects are not only too long, they also consist of too small tasks derived from the excessive number of specialised part-time people** in the traditional projects in medium- and big-sized companies. This generates low Flow Efficiency, loss of the Big Picture and an excessive number of coordinators that is not adding any value at all.
Not solved: Agile thinking is: the smaller, the better, in order to try to solve complexity and to get rid of interdependencies, meaning that the features are divided into smaller and smaller tasks per year [2]. This also generates low Flow Efficiency, loss of the Big Picture and an excessive amount of coordinators, which are the same problems as for traditional projects, but of different reasons, see this blog post about Clogging for the details.
- Problem: Traditional big product development projects could not cope with both the complexity and uncertainty introduced with market change to include also Customer Pull (SW Projects). This due to that especially the complexity, which can never be part of planned work, was included in the projects, which is not possible per se, due to it is unplannable. This was never a problem with Technology Push (HW projects), since then the research was done before the project started, meaning that the whole project really could be planned. See this blog post for the details about the big differences between Technology Push and Customer Pull in a traditional project setup.
Not solved: The complexity and uncertainty is put together within the Agile projects, but where the complexity will not vanish just because the tasks are made smaller and smaller and experiments are made. To understand what the customer need, means uncertainty, and that need to be reduced by experiments with the customer, stakeholders etc., in order to understand the need. Big product development projects (any domain, not just software) with no understanding of the customer need, means extreme risk, but is fortunately very uncommon. This also goes for the software domain, where we Instead have finance, banks, insurance companies, retail, etc., that already have a product they sell, which means that the uncertain part of the system is only the UX part. The UX part for big systems, which requires a lot of experiments to get right, therefore need to be handled separately. On the other, hand we also need to reduce the transdisciplinary complexity/complicatedness for the total system, which incorporates systems design that takes care of the non-functional requirements, to get a stable architecture. See why this separation is required, and also how the back-end and front-end also easily are separated in this blog post about the method Systemic Organizational Systems Design (SOSD). So, for big product development projects, the complexity, HOW to build the product/system, is the hard part, see the Test-Driven Systems Design (TDSD) blog post for a deep dive of a method for development of big software systems. A project is only a project when you can plan the work, i.e., there is no complexity left, only complicatedness, since the latter can be handled with some iterations (like prototypes in hardware). If there still is some complexity left in a part of the wholeness, we need to do also a solution with no complexity left in parallel, to not risk the time plan. The same goes if the total solution has complexity left, then we need a parallel project with no complexity left, in order to not risk the time plan.
Note! In software when having big projects, we really need to avoid always having the mentality that because we do not know the exact customer need, this means that we cannot plan the future, which in turn means that there is no need to plan or make a systems design of the total. Remember that we humans at least the last 100 000 years, have learnt how to get order and structure. We reduce transdisciplinary complexity/complicatedness by making a new/updating the old systems design with a stable architecture as a result, and we reduce transdisciplinary complicatedness by making work break-down structures (different kind of plans) and people structures (line hierarchy and virtual delivery structures). For big systems in any domain, making structures (synthesis) after first have been thinking (analysis), is still vital, which SOSD, backed up by science (the organizational principles), clearly shows. Scaled agile methods and frameworks for big software systems are ignoring this common sense of the need of order and structure. This goes actually for all the resulting structures mentioned above, i.e., the needed organizational principles are not followed, and is the reason for the development of the method TDSD.
- Problem: To be able to finish a project, we need to have both the right number of resources and competences, the roles and the responsibilities, when we setting up the project, but then the focus must be on solving the problem as neatly as possible. The traditional line organisation takes care of administrative parts including the resource and competence need of the organisation, and this is structured by each manager having an area of responsibility; roles and responsibilities. But, when a project has been setup to solve a task with the right people, the focus needs to be on interactions flowing freely over the whole organisation to solve interdependencies between activities. The reason is that interdependencies in for example product development are never known in advance, meaning that the interactions can never be “processified” and therefore never can be fully specified any (manager’s) roles and responsibilities. See this blog post for a thorough explanation.
Not solved: Roles and responsibilities are too rigid in frameworks when Agile is scaled. Rigid roles and responsibilities we can only have within the repetitive processes in production; standardised work. In product development, as stated above, we can never from start address the interactions needed in order to solve the upcoming interdependencies between the teams and/or experts along the way. To have roles and responsibilities is important so a company can see that is has the right number of resources and competences needed, but when doing the actual work, the focus shall be on solving the problem, HOW the whole task should be solved in the most efficient way, not on the roles and responsibilities. And as also stated above, it is impossible to state who is responsible for an interaction, meaning that it neither can be put in any role’s responsibilities nor “processified” since we do not know from the beginning about its coming presence, neither when or between whom.
- Never a problem: Scaling in traditional projects, where the wholeness is still kept together when the original task is broken down to smaller tasks, also with a long-term architecture in focus. Traditional projects have always been very structured regarding organisation, architecture and planning, all three very important in order to reduce the complexity when size is introduced.
Introduced problem: Since our Agile way of working has incorporated many thoughts from Lean production, where there are no interdependencies between the processes and the processes always are autonomous, the interdependencies have become a big problem. The interactions needed to solve interdependencies, known or upcoming, between the teams and/or experts need to be planned as soon as possible, and preferably on an accuracy of day. Activities and interdependencies are the WHAT and the WHEN, which can never be given to the team to decide themselves, when there is more than one team. This is due to the teams’ strong connections to each other to be able to solve the wholeness, see this blog post for a thorough elaboration. And WIP Limits and different measurements are only trying to cure the queues on the Kanban boards, which is only a symptom of bad planning and/or bad T-shape. See this blog post about problem-solving, for a thorough explanation and how to take care of the Kanban board’s queues. Also, crappy systemisation becomes a problem according to Mary Poppendieck when a proper architecture work is neglected and focus is only on delivering new features. This means that the long-term wholeness is not taken care of, severely slowing down future feature deliveries, see this blog post for a further explanation.
Note also that when the wholeness is not properly taken care of, it is not possible to make a common platform, with common modules for the whole company. This is due to that the wholeness always is divided into small parts for the teams to solve, see this blog post for details.
- Problem: Micro management of HOW to do an individual’s or team’s task, how to finish the project, is not to respect people.
Only partly solved: The Agile teams are respected in Agile which is very good, but still smaller and smaller tasks, aside from causing low efficiency, is kind of disrespect by removing both the problem-solving ability and the Big Picture for the team members, reducing them to code monkeys, i.e., specialisation** as well. But, the real problem with disrespect comes when scaling, as we can see still exist in Agile way of working in the earlier bullets not taking care of the wholeness or caring about context or business. Many people inside the Agile teams have already seen this, but their voices are seldom listened too. The reason is because the coaches and other people around the teams are following the rules how to scale, or the rules of the framework for scaling agile, without any hesitation about their correctness. But the deeper we are into our method (HOW), following strict rules that are incorrect, the more distant we are from the implications of the definition of project above (WHAT), or our system start definition (adding also the interdependencies). This means that when rules are made on other incorrect rules, it will get more and more blurry and at last anything can be proven to be correct, due to the blurriness that no one can see through, not even the inventor, and we have got ourselves a mess, as Dr. Russell Ackoff would have put it [3]; “mess – sanctified as a technical term, for a system of problems”. Not listening to the people giving proposals about how to improve the system (organisation), was one of the biggest issues that Dr Deming brought up when the American industry had big quality problems in the end of the last century. Not respecting our people will result in more and longer chains of symptoms.
As we can see, there are many hidden problems in our Agile development to be taken care of, many easily solved, since they are now in the open air. One big reason for these hidden problems is that we in Agile has doomed the word project, and in that way disguised real problems, both traditionally ones and the ones inherent in Agile.
So, by dooming the use of a word, as we could see in the conclusions above, the risk is very high that someone’s intentions lack a proper investigation on what problems to solve, being dubious about (or not understand) what problems that really exist, as well as trying to hide (or not understand) problems that are self-generated.
And you that have followed the series about problem-solving, know that if we are not looking for the root causes to our problems, we are only doing the impossible; trying to cure the symptoms, insufficient and inefficient per se.
C u tomorrow in the next blog post in this series.
*With organizational purpose means; manufacture a product, service, develop a new product, etc., with a certain price and quality. We are not talking about the nowadays popular Purpose statement, that is only a continuation of the easy-gamed value and mission statements. In this kind of statements, behaviour, properties and core values of our employees are stated, which is more of wishful thinking, since they will only emerge from multiple interactions within the organization. Since the interactions in turn, also emerge from our way of working, one can believe that if the purpose of the organization is not fulfilled, neither will the emergent behaviour and properties of our organization be what one could wish for.
**Specialised people are not derived from the word project, but is the cause to small activities in traditional Project. Specialisation is of course a problem itself, where an exploration of the deep connection between queues of people and queues of activities giving low efficiency can be found in this blog post. Specialisation can also be found below in the Agile way of working.
Problem: Specialised people working in many different projects, gives an excessive amount of part-time people in traditional HW projects in medium and big companies, meaning low Resource Efficiency, see this blog post for details. Since all companies in order to meet today’s market need to have speed and flexibility, smaller projects often means faster and more flexible, which is impossible to achieve with too many specialised people found in medium- and big-sized companies.
Only partly solved: Full-time developers in the Agile teams is of course very good, but specialising the people around the developers in the Agile teams to only do coaching, or only take care of the product requirements, only coordinating, etc. is going in the wrong direction.
References:
[1] Cambridge Dictionary. Link copied 2019-06-01.
https://dictionary.cambridge.org/dictionary/english/project
[2] Patton, Jeff. “The Mystery of the Shrinking Story”. Link copied 2019-06-01.
https://www.jpattonassociates.com/the_shrinking_story/
[3] Ackoff, Dr. Russell Lincoln. Speech. “Systems-Based Improvement, Pt 2.”, Lecture given at the College of Business Administration at the University of Cincinnati on May 2, 1995. At 12:45 min.
Link copied 2019-03-18.
https://www.youtube.com/watch?v=k8g6ZoobDV4