What is agile coaching?
Agile coaching consists in guiding your team of project managers in choosing the right agile software development technique.
Agile coaching covers a wide range of topics. In literature about software development some authors distinguish between agile coaching and agile consulting while others make a distinction between the coaching of a group or company and the coaching on a one-to-one basis.
The consulting activity consists of applying a specific agile method. This could for example be the finetuning of the product backlog. Obviously this creates a major step forward for the team and also provides the team members with the tools and know-how to be able to work more efficiently without the presence of the agile consultant.
Coaching on the other hand consists of guiding a team to find its way within the agile methodology, providing them with answers to one or more of the following questions : “What is scrum all about?”, “What are the underlying principles?”, “Why are the results not as expected or predicted?”
To us it is not that important to actually distinguish beforehand whether you as a client are in need for consulting or coaching in the field of agile software development techniques. This is something that will be clear once our intervention starts on the workfloor.
Until now we have treated the horizontal aspect of agile coaching within a single team. However, there is also another dimension to agile coaching. The vertical aspect consists in coaching individuals to perform well within a team and to take this team to have it perform well within a department or the entire company.
The coaching on the individual level typically could consist in guiding a scrum master in performing well as a servant-leader, in precisely defining the tasks of release train engineer in SAFe or in making clear why continuous deployment can be of importance to a DevOps-engineer by showing that the disadvantages are largely outweighed by the advantages. At the team level coaching can be of great importance when integrating to different development departments into one or when integrating the department of Development and the one of Operations. Possibly also the accounting department can be positively affected by using some of the DevOps techniques or by organizing maintenance activities in sprints.
THE AGILE FRAMEWORK
The framework
The agile framework consists of several techniques that have evolved over the years such as Scrum or Kanban.
An important charter, the Agile Manifesto, has been issued by some of the most famous people within the domain of developing methods, such as Ken Schwaber of Scrum.
The charter is reasonably short and contains a few of the principles that should be met by any agile methodology. Apart from those, any methodology is free to invent its own techniques as long as the forementioned principles are respected.
From this angle, the famous technique of ‘lean management’ in itself is not considered an agile methodology. Often lean management is made part of other methodologies that do adhere to the principles of the Agile Manifesto, such as Lean Six Sigma.
Not all of the agile methodologies has been developed to solve the same issues. The mere building of software solutions is the object of methodologies as Scrum and XP, and partially of Kanban. DevOps however is more oriented to the actual deploying of the software, whereas Nexus or LeSS tend to find ways of effectively and efficiently integrating and combining software developing teams.
The agile framework has not seen the light on one specific day, but is the fruit of a movement that constantly evolves. Some 30 years ago the technique of Scrum was a real revelation. However, the limitation imposed by Scrum on the size of the developing team limiting it to a maximum of 9 people, has made people wonder what to do when one project is too big to be dealt with by one team or when one team has to deal with different interrelated or distinct projects. For this reason Nexus, LeSS and SAFe have emerged. Scrum tends to offer little solutions with regards to the actual deployment of software.
According to Scrum this just happens. In practise this doesn’t or hardly ever seem to be the case. As a consequence DevOps and DAD have come to offer solutions on the matter of deployment. In addition to the latter, SAFe has also put some hard work in thinking about deployment issues and has come to offer the concepts of release train.
This constant evolution can also be noticed when looking at DAD – Disciplined Agile Delivery – which consists in a methodology that indicates how to choose among other techniques but that also is a part of DAF – Disciplined Agile Framework. The latter framework aims to provide solutions on an interproject (portfolio) or enterprise level, but the different modules still have to be developed.
The example of DAD points us to another aspect of agile software development techniques. Most of those are referring to each other. DevOps for example refers to Scrum and Kanban when it comes to the part of developing the software and focuses primarily on the operations.
Other techniques are less popular or are already somewhat outdated, but they can still be of value or even lead to major improvements with regards to the effectiveness of a development team. Among those are DSDM, Agile Methods, Crystal and UP.
My personal touch
Regarding the multitude of agile software development techniques, I personally tend to make a note. Some managers may overlook the fact that software actually has to be developed by programming a computer, whereas the actual programming never is the object of the developing techniques. These merely focus on the managing of the developing of software. As a consequence the developing of the software in itself can sometimes be an issue that is not sufficiently addressed. In my opinion, it is to be noted that the actual programming can be a time-consuming task including many challenges.
Throughout the years software developing has become an ever more complex task to perform. Today’s software architecture has many layers (three-tier to seven-tier) and has to be implemented on a multitude of clients such as smartphones on Android, Tablets and dedicated professional devices such as barcode readers.
Servers too get ever more complex. In my opinion, the different existing agile methodologies fail to address issues related to complex databases. The possibilities offered by today’s Oracle servers really outperform the database servers of some 15 years ago.
In the early days of software development the actual deploying tended to be rather easy. The programmer could copy the software directly from his developing device to the platform that would take part in the production process. Personally I remember the many discussions in the year of 2009 that I had with contracted professionals who argued that the fact to have to develop their software on a developing platform was a mere waste of time since a month later, after passing the testing phase, it would be implemented directly on the production platform anyway. Why not directly programming in the production environment, so I was told, which at the time was so much less time-consuming.
Luckily, nowadays developing lanes have become mainstream. When wanting to apply Scrum, as a software architect one can only organize sprints of maximum one month’s work. That sprint will then have to deliver a “potentially releasable increment of product” : a fully completed functionality that has undergone full testing to the level required for implementation in the production process. And all that in a few weeks time.
From the viewpoint of the Scrum methodology, this reasoning seems very much acceptable. In practice however this isn’t the case. Regrettably Scrum doesn’t seem to be willing to address this issue.
Agile coaching is an art in itself and requires an approach specifically tailored to the company and the team.
This brings me to another aspect of agile methodologies. When reviewing discussions on dedicated platforms on the internet, I find that software managers are often struggling with the implementation of these techniques. They are ready to profoundly modify the development process or even to try all kinds of artificially constructed techniques to close any loopholes when trying to remain within the concept of Scrum.
The concept of Scrum is that you have integrated any person that you would need to develop the code into one developing team. As a consequence, this developing team can concentrate on developing the software without any disturbances or interferences. In the case that any obstacles would occur, it is the task of the scrum master to circumvent these obstacles and to find solutions.
A classic example of an issue that often occurs when developing software in practice, consists of the programming of software that has to interface with other legacy software. The latter will of course often be managed by another team, often not even within the same company. Scrum would dictate in that specific case to let the other team that manages the legacy software integrate into the developing team. This of course seems to be great in theory but will hardly be possible in practice. Often it will not be feasible due to legal restrictions, but even so, there will often be organizational issues preventing this from being implemented. Indeed, what can be done by the Scrum master of the initial developing team when the members of the other team do not wish to respect the deadlines of the scrum master’s sprints, doesn’t care much about participating in stand-up meetings and cares even less to travel for over a thousand miles to participate in a feedback meeting?
Wendel Van Hespen – Managing Director
I’d like to conclude by stating that companies are not universities. Thus, there is no money to be earned for having implemented Scrum in the best way. The way the methodology has been implemented, in my opinion, is not of greater importance than the final result. The methodology to manage software has to be available to the developing team as a tool, but it has never to be the other way around. In the case that implementing Scrum doesn’t add to the value created by the developing process, but on the contrary tends to be counterproductive, then another method or approach has to be looked for, one that does improve productivity. Nevertheless, it may also be useful to audit the actual developing process that is in place. Indeed, if a developing methodology doesn’t deliver, it may also be that the process is not well streamlined.
Philosophy, methodology and framework
Agile coaching helps to distinguish between philosophies and methodologies, in order to apply a specific agile framework when implementing agile software developing techniques.
When discussing agile software developing techniques in earlier paragraphs or other sections, people tend to use a strange mix of words or terms to refer to these techniques, often not really familiar with the actual terminology. For this reason some explanations about the terms of philosophy, methodology and framework is very relevant.
Scrum for example, is a framework and not a method. It offers a setting in which one can develop software, what ultimately will lead to a concrete methodology within the developing team, but another developing team could very well have developed and implemented another methodology, that still perfectly integrates within the Scrum framework.
DevOps, or Lean, is more of a philosophy. These ways of thinking tend to propose different ideas or visions on how to proceed when developing software, but how to implement those ideas is left out of the equation. Understandably many enterprises have been developing methodologies to implement the ideas as proposed by DevOps or Lean and there are many other companies following in their footsteps, but initially DevOps or Lean are philosophies providing mainly theoretical and guiding principles.
Kanban on the other hand, is more of a philosophy and a methodology at the same time. The system of working with cards and the Kanban board together with the mathematical methods of calculating and limiting WIP (Work In Progress) really provides developers with a decent methodology. Though it is true that the Kanban board can be implemented in very different forms or manners (a whiteboard at the wall, a blackboard with chalk, a wooden board with post-its or a website on a computer), the way of working with it is very well defined and not open to interpretation. Even though the system has been based on a philosophy used by Toyota when implementing the production process, it still offers concrete measures and can thus also be considered a methodology.
When discussing each of the agile software development techniques, the main characteristics of each will be clearly outlined and the distinction can be made among philosophies, methodologies or frameworks. Understandably, when referring to those techniques as a group, the words chosen to describe these can be less accurate and more generalizing.
A DELICATE ADVENTURE OR THE IMPORTANCE OF A CORRECT IMPLEMENTATION
A delicate adventure or the importance of a correct implementation
Scrum clearly states that it is not permitted to modify any of the modalities of Scrum nor that anything of the Scrum framework is up for modification
It is however permitted to add things to the framework. In practice this often leads to the adding of story points and poker planning to Scrum. Of course these add-ins are not part of the Scrum framework and have been developed for XP. This fact is not known to many and it appears to some that story points are always part of Scrum. Clearly this is not the case. One could also opt to work with ‘Ideal days’ as the director of Mountaingoat software Mike Cohn has suggested.
It is often told that if Scrum is not correctly applied, it will not guarantee the beneficial effects of Scrum. This may not be clear to the reader of the ‘Scrum Guide’, but on completion of the reading of a book such as “Software in 30 days” by founder Ken Schwaber there will not be any doubt left. It has to be said that Scrum has a proven track record over several decades and thus has proven to be a reliable methodology leading to success. Therefore, the Scrum methodology deserves to be respected.
As a conclusion it is fair to say that applying agile software developing techniques is a delicate work, best left to specialists in the field. The correct implementation of a specific methodology is of great importance since without it no or less success will be achieved. Of course some of the principles or guidelines are of greater importance than others, but since it is not easy for a novice to distinguish between those, is it sound to advice not to take part in any adventure. Therefore, an agile coach is really recommended. The results will undoubtedly follow.
The above reasoning is valid for Scrum but also for all other agile development techniques.
A clear setting and explanation of the framework often adds to the understanding of the principles and guidelines of a specific agile methodology, that can be very strict in wording, but may prove to be less harsh when implemented. As a consequence, the members of the developing team will be more supporting of the newly implemented agile software developing techniques.