Your Agile May Not Be Doing Well Through a Few Signals

Original

Image Source: Wrike

Preface

Agile is an empirical practice discipline that is easy to say but difficult to do well. In addition, the agile to generate effect is not a matter of minutes, which inevitably requires a prolonged observation. If you ask others how agile is doing, they will usually tell you it is good. But they can't give any specific examples when you ask how good it is. I can't tell you what doing well means here, but I can list some (self-perceived) signs that "agile is basically not doing well."

1. The Unacquaintance of Project Management

Although various trends of weakening project management and strengthening product management have emerged in recent years, product development that completely ignores the three constraints of project management has not really been seen much in practical work. So how to deal with these constraints during the development process can be considered a solvable problem domain is belonging to project management.

In addition, you always have to deal with stakeholders, risk management, resource allocation, communication management, and procurement management as long as you promote product development regarding how you deal with these knowledge areas. Agile practitioners, who do not understand project management, can handle it? If you can't handle it, the agile you perform will likely be an empty shelf.

After all, agile is a practical science, and doing things well is the most important thing. And project management, in all likelihood, is an integral part of helping you get things done.

Here are my views: PMP is not waterfall project management, PMP is not waterfall project management, and PMP is not waterfall project management! If you can, I recommend you take a serious look at the PMBOK even if you don't take the exam.

2. Only Know Scrum and Nothing Else

There is no denying that organizations are doing a great job promoting Scrum, and it does provide talents for Agile to a certain extent. But for various reasons, Some practitioners believe that agile is the same as Scrum, but they have no knowledge of other agile-related content and do not know how to be flexible.

Practitioners use the Scrum model for everything, whether appropriate or not, which is itself a show of pedantry. Moreover, agile, a practice-oriented discipline, does not have a fixed model that can solve any problems. When you only use Scrum, how can you ensure that it works? Or do you want it to be a retroaction？

3. Think About Agile and DevOps are Two Different Things

For these two things, Patrick Debois, the father of DevOps, and Arie van Bennekum, co-author of the Agile Manifesto, have already stated "they are the same thing" in the DevOpsDays live stream on 2021.11.10. But why do people still think there is a distinction between the two?

From my point of view, there are probably several reasons:

• Practitioners have a poor understanding of agile itself. The actual constitution of Agile is the manifesto, which only provides values but no framework or implementation plan. As a result, people's specific understanding of agile will be affected by frameworks such as Scrum, and they believe that the scope of agile is limited to the development part (this can be considered as a continuation of "Practitioners only know Scrum and nothing else"）
• DevOps is too concrete. In addition, DevOps is biased towards pipeline and automation tools and ignores the ideas behind DevOps. As a result, the practitioners' cognition of DevOps is limited to the level of "tools" and "practice";
• Theoretical players of evidence-based, unable to "know and do" and to produce the correct knowledge of the two from the bottom, knowledge is limited to the content of the examination syllabus. The results are naturally noticeable without saying.

If any of the above reasons are true, it is difficult for practitioners to do agile well.

4. Do Not Read Books or Never Read Classic Books

The knowledge in the agile circle is not updated that often, and a lot of knowledge from twenty years ago is still available, so there is no obsolescence of classic books. And some new books, many of them are making fixes and updates just based on the classics, and there is no such situation as a complete overthrow of the old theory.

So if you have never read classic agile books before, it is likely that your understanding of agile will be biased at the beginning. Even if you finally accumulate enough real-world practice experience, the deviation will likely be more significant, and "China Garden Agility" will be formed.

5. Lack of Attention to Engineering Practice

Note: This part applies to IT teams only.

Please note that I disagree that "no engineering practice is not agile" I can only say that if you do agile, you will have to deal with team engineering practices sooner or later.

According to the theory of constraints, during agile implementation or transformation, you have to focus on the most considerable constraints. Many teams in the early days have constraints in the process, tools, requirements, and communication methods. And they will not focus on the lack of engineering practices at the beginning (engineers' voice: yeah, How can there be such a good thing!) So many times, when importing Scrum or other frameworks, it can produce miraculous effects at the beginning. But this level of improvement can't go on forever, and you need engineering practices to eventually make up for the problems on the R&D side. If you can't do anything about engineering practices or ignore them at this point, the team's agile journey is basically at an end.

PS: Even without engineering practice, many teams can optimize reasonably. Just look at the trade-offs here.

6. Can do the Planning but Cannot be Personally Involved

An old Chinese saying says, " Take the whole into consideration, but do the job bit by bit." This is also true for agile - you need to look at the purpose, expected effect, and implementation steps of agile introduction from a global perspective. That is, you need to plan at the so-called "strategic level," You also need to put it into practice and have the ability to coach at the team level and department level, also known as the so-called "personal involvement." Only then can you get better information to make timely corrections to your strategy (You didn't expect that did you? but adaptability can also be used here.) and maximize the effect of agile.

As the ancients said, "knowledge acquired on paper ultimately seems shallow still to understand this thoroughly, one must personally experience it all. Is strategy difficult? No, it's not! If you go to Jingdong and look up "strategy," you will find many books on strategy, and any book you buy can tell you various methodologies and thinking points. But after all, those are the book knowledge and are available in practice? Are you full of question marks?

And the interesting point is here, I do not know if it is because many people do not have the opportunity to implement the strategy in their lifetime, so "talking about strategy" seems to become a very high-end thing. The cost is meagre - after all, what you say is not likely to be adopted, but it's also a great way to raise the style in the enthusiasm for strategy, and people are happy to hear it. It seems to be a win-win. Well, the thing of "talking about strategy" has won twice here, which has won quite a lot of times!

The above is my superficial view. In addition, there are many subjective factors, so it is inevitable to be biased. If you have other ideas, please leave a message and let me know.