For professional development, attempts are made to apply athlete training methods or martial arts practices such as Coding Dojo and Coding Kata. Of course, it is a big question whether such techniques can be applied to train programmers. But in any case, some training is needed. If you work on production code all the time, you can solve the same problems in the same ways and not develop at all. It seems that classes are really needed, aimed not at creating something specific, but at honing certain skills. Perhaps the most effective method is to solve the same problem in different ways, using a variety of technologies. Continuous improvements to the current architecture are good too. You need to constantly question the current state of affairs and try to improve the solution, make it simpler, more flexible, more understandable.
Obviously, increasing the complexity of systems requires a lot from people. It is no longer possible to simply know C, data structures and algorithms. Now you need to know OOP, patterns, libraries, a bunch of related technologies and disciplines. The volume of required knowledge increases every year. However, the level of abstraction in programming has not changed much over the past few years, while the complexity of systems has changed significantly. The architecture of Facebook or Twitter is extremely complex, I don’t think a single developer has any idea how the whole system functions. So the programmer has no right to stop learning.
Problem solving
Problem solving is probably the most important human skill. If it is, you can easily fill in your own gaps and gaps in the development process in the company where you work.
See how a retrospective happens on almost any team. People gather, put forward some problems that often lie on the surface, and offer solutions that also lie on the surface. Very rarely root problems are touched upon and solved. It is very rare that truly non-standard, cool solutions are offered. At such meetings, there are practically no tools for identifying problems. Systems thinking, TRIZ, brainstorming techniques – most teams ignore all this because they do not have the skills and knowledge. Programmers are not taught systems thinking. Programmers are not taught TRIZ. Programmers are not taught brainstorming. Programmers are not taught to think outside the box.
Problem solving techniques are not taught in school, college or university. It’s just incredible! One of the main skills in professional life is not mentioned in any lecture!
Programmers themselves love to learn everything related to the strategy and tactics of programming, other things are of little interest to most developers. Programmers know the algorithmic way of solving problems, but practically do not know the heuristic, creative way. Process improvement tasks are almost always complex and creative tasks that cannot be solved using algorithms. Architecture tasks also require creative thinking.
Experienced coaches try to bring new practices into retrospectives, but they do not always succeed. Often they themselves are not experts in problem solving, often fail to transfer their knowledge to the team.
Agile relies on self-organization in teams. This means that the team itself must identify and solve its problems effectively. Otherwise, it will inevitably step on the same rake. However, no agile methodology contains or promotes problem-solving tools.
Interestingly, in design and UX, people use these tools. There it is something ordinary, just another set of working tools. Developers often miss this.
A great developer must have creative, out-of-the-box thinking. He does not need to be able to compose poetry, but he must write coherent, good texts. Develop the right hemisphere, gentlemen!
Scale
Scale is a serious test for agile processes. Basically, the problem of scalability concerns the company as a whole and distributed teams.
Company as a whole
Agile works well at the level of individual teams. A single team can really improve its efficiency by switching to Scrum + XP or Kanban. But if you try to develop the idea for the whole company, very often it will meet with serious resistance and misunderstanding.
First of all, agile conflicts with the corporate culture of many companies. The basic principles of agile, such as transparency, trust, modesty, are met with bewilderment by the business world. Transparency? The trust? Modesty? Hmmm… In many companies political games, careerism, boasting and incompetence reign. For such companies, agile is perceived as a virus that threatens to break the existing order.
Agile seeks to break the homeostasis of the traditional company and bring to the surface all the undercurrents, hidden flaws, and everything that does not sink in water under normal conditions.
Even if the company is doing well with transparency and trust, there are still quite difficult problems. The HR department must change its approach to hiring people and select those who are suitable not only for skills, but also for the culture of the company. The marketing department needs to figure out what to do with frequent releases. The design department needs to figure out how to include itself on the development team. Top management must understand how to organize interaction between many agile teams throughout the company. All this is very complicated and there are no answers to many questions at all. Large companies are just starting their reorganization processes with agile in mind.
Recently, UX teams and the development team have been actively connecting. There is serious progress here.
As for the interaction of many teams, everything is much sadder here. Scrum of Scrum showed its complete inoperability. There are no clear mechanisms yet, everyone steps on the same rake and invents his own bicycle.
Distributed teams
A longstanding problem with agile is globalization. The development of the Internet has led to the emergence of distributed teams. There are companies with offices in dozens of countries around the world that have to synchronize the work of hundreds of people. Since agile was born at the level of co-located teams, it initially has serious problems with distributed teams. Continuous communication and reduced feedback is difficult when the product owner wakes up at 9am and the developers sleepily show up at work at 4pm.
The solution to this problem is complex and, first of all, should be carried out by increasing the saturation of communication channels. Direct constant video communication between offices is the best solution. It’s always nice to see today’s mood on an unshaven face and know if a person can now ask a question, or is it better to wait.
Also, tools for remote pair programming, brainstorming and testing are emerging and developing. Tools like TargetProcess are essential for any distributed team.
Conclusion
The main task of the software development industry is to get into the center. Learn to do the right thing right and fast.
I’m sure it’s possible. To do this, you need (in descending order of priority):
study problem solving techniques such as TRIZ, develop out-of-the-box thinking and systems thinking
reduce feedback time by all means
study the subject area
learn how to scale agile-mindset for the whole company and for distributed teams