Ajedrez - antoniomartel.com

Archivos de Categoría: English

Agile 101 book

Pretty soon my first book on Agility will be also available in a new English edition. You will be able to find there same contents and same topics that were addressed at the Spanish edition or that you can find here in my blog but ready for English speakers:

  • Scrum pros and cons
  • Agile estimations with Scrum
  • Help and hints to pass your Professional Scrum Master (PSM I) Certification test.
  • Real life projects experience and practical know-how on how to deal with situations that we all have gone through any time in our professional lifes.
I leave you here with the foreword of this brand new edition (translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt):

“Extra! Extra! New edition Agile 101. Read all about it”


Your company has just appointed you project manager. You’ve heard about Agile methodologies, Scrum, Kanban, and lots of other things you’d like to try. You’ve started reading all about artifacts, principles, and manifestos, but nothing is crystal clear just yet.

You don’t know whether your lack of knowledge will put your project at risk, but probably what worries you the most is that all these things are nothing but buzzwords, the current fad, and that they won’t have any real effect on your day-to-day work… or even worse, that such a big change in what to call things and how to do them will make your team, your clients, and your company reject those ideas altogether. Luckily for me, or unluckily maybe, I have also gone through all these problems, so in this book I will tell you how I solved them (when I’ve been able to) or, at least, what I tried and what eventually failed.

Don’t expect this document to be an exhaustive Scrum guide. I don’t know everything about Scrum, and the implementation I follow is far from perfect. For a thorough knowledge of Scrum, I recommend following some of the popular Scrum guides that you can find either online or in books like the one by Henrik Kniberg, not to mention the one by Jeff Sutherland, creator of Scrum.

Even though I follow a survival Scrum style and I still have lots to improve, Scrum has worked for me. Using it, we have managed to gain credibility in difficult projects, projects that were not working the way we expected. We managed to reduce the amount of stressful situations that, luckily, now happen far less often, and we have increased the satisfaction of the clients who, sprint after sprint, get their money’s worth. We have not been able to follow Scrum methodologies to the letter in every project we have worked on, but just trying to be more Agile we have improved our results in the projects we are working on.

When we start using Scrum, we all tend to use the terminology of this framework, talking about daily sprint meetings, product backlogs or burndown charts. We follow our Scrum guides to a tee, when in fact no one understands them, not even ourselves. Not understanding the spirit behind these rules, we end up creating a waterfall project—like we always have done—disguised by jargon that makes us look more innovative.

Rather than telling you how to do things, or explaining in detail how many meetings you should have and how many minutes each one should last, in this book I want to describe what the purpose is behind those meetings, what the artifacts described in Scrum guides are for, and what you might get out of them. I’ll help you understand the Agile principles that underlie this way of working and that really make this work. I hope you find this book very useful!

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

5 Lessons learned in Project Management

Whenever I finish a project I try to have a look at what went wrong, what worked as a charm, and what I tried but it didn’t work out. Even when I get a final negative balance, the project may has been worth it if I don’t make the same mistakes again.

From some of these balances, I have extracted five of the most important lessons I’ve learned. Some are beginner mistakes, others should have been solved using simple logic but, by then, it wasn’t that evident to me. Here you go:

Agility works

It is difficult to quantify it but since I started using Scrum in my projects, the number of hours spent by functionality went down. Just doing the daily meeting for 15 minutes, maintaining project status chart that tells us if we are going well or not and a delivery every two weeks allowed us to obtain 80% of the benefits of Scrum. In addition, delivering consistently every two weeks, showing client what was agreed two weeks earlier, seemed to bring customers some comfort. In July or August, when meetings were not possible, the weekly delivery of a simple two-page document with the percentage of completion for each functionality and two paragraphs explaining the reason of those percentages, helped to restore credibility in a difficult project (especially in September when they could check that those percentages were real)

Everything is not positive in Scrum

It requires much more dedication of the Scrum Master than it would if you only were playing the role of project manager. Those 15 minutes at the daily meeting will tell you a lot about the difficulties that need to be solved to keep going forward. Trying to solve them will take you the rest of the morning.

On the other hand, having a delivery every 2 weeks can be exhausting. You cannot be sprinting for months and months. After six months you will be ending trotting (hopefully) You need to take this into account since the first planning.

Last but not least, Scrum is not magic. Whatever methodology you use you will need a team able to perform at a good level, willing to pitch in and eager to contribute. Teams like that do not grow on trees. If you already have one of those teams the project manager mission will be to interfere as little as possible.

Adding more workers to the team will slow it down

Well, this is already said for a lot of years in the book The Mythical Man-Month. Yet it is necessary to emphasize this, there are no much exceptions to this rule. No matter how tight the deadlines are: Nine women cannot make a baby in one month.

Who is the owner of all this?

No matter how we call it: identifying stakeholders, designating the product owner or involving the stakeholders. At the end we need to know who will actually validate. And I do not mean who will sign the bill. You also need to know who will use the product. The project will only be successful if after delivering it works and it is useful.

In certain project, the client’s director gave us all the documentation, validated partial deliveries, tested the entire application and congratulated us for the work done. Unfortunately, when his secretary attended the training session a week before sending the product to production, she said: ‘This is not going to help me: that one is not the right template and I need to collect different data than the one showed there’ . This meant a week of overtime and extra effort and the risk of putting into production environment a product that could be unstable.

Minimum Viable Product

If you already have something that may be useful to the user, give it to it, put it into production, take it out for sale. Do not wait until you have completed every single functionality. If you remember the Pareto principle, with only 20% of them you will obtain 80% of uses of your product.

While in production you will begin to get the impressions from its users. They will know more accurately what they really need and you will know what you did wrong and how you can improve it. If you bet on a single final delivery you will have only one bullet to hit the target (to do this would have saved us a lot of problems with the product mentioned in the previous point)

Those are my lessons learned. I hope someone will make the most of them.

Keep it Simple, Stupid

Recently, after a conversation with a professional colleague on the current IT world, something reminded me of a Andres Diplotti cartoon I saw first time in Google+:

As a programmer I have been for a long time, and partly still I am, acknowledge that I have had this kind of arrogance (without going to these extremes) I guess it is a sin of youth that has been mitigated with age and that some of us already had since college.
By that time I remember to have discovered the software design patterns book from The Gang of Four. Our applications began to fill with design patterns, the more you used the better, in a kind of competition won by the one who used the more complex and difficult pattern. I guess this helps me to understand the posts and articles I see now on refactoring to eliminate design patterns and the cost of all these changes in some projects.
Over the years I learned firsthand the KISS principle (Keep it Simple , Stupid) not only with patterns, but also when customizing graphical components on screen or with the ‘ghost requirement’, a name that I heard on a rise to a co-worker to refer to those features that nobody asked but one believes important to the customer and that ‘for sure’ he would end up needing.
Long ago, a project manager on a client told me that someone in another team had indicated that it was impossible to get the functionality he asked. I replied that practically everything could be achieved by investing the necessary time. I was not clear enough . I should have added, Is it reasonable to use all that time on that functionality? With almost any programming language one can send a rocket to the moon but do you really want to go to the moon or do you want a working application on time?

Suscríbete

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad