Archivos de Categoría: English

Agile 101: Scrum pros & cons

domingo, 05 junio 2016 20:00

antoniomartel

0 Comentarios

“There is nothing more difficult and dangerous, or more doubtful of success, than an attempt to introduce a new order of things.”

Machiavelli

Disadvantages of using Scrum

How many technologies have quickly popped up and then vanished even quicker? They all promised to be revolutionary, the new silver bullet that will end every problem in the software industry. When we get as much hype as has been lavished on Scrum and Agile, our first reaction is to raise a critical brow.
If you are adopting Scrum in your project or company, it is best for you to be informed beforehand about its drawbacks:

The team might be tempted to follow the shortest route

When we have things to deliver every two weeks, and in the latest deliveries the projected functionality wasn’t ready and the speed of the team does not indicate that we will finish the next one on time, we have a problem. We can succumb to the temptation of finishing the pending tasks in any way we can and leave a “technical debt” behind us. Everything has the appearance of going well, we create more features, we start new things, and the client is happy because deadlines are being met.

But every time you leave a small hole of a deficit behind you, I can guarantee that you will stumble on it again and make it bigger. If new things keep caving in this way, the “debt” will become a pit. Sooner or later you’ll have to stop everything and fill in the pit—pay back that loan and with extra interest because of that late payment. The project doesn’t finish when we were so close to the end, and the burndown chart appears to have a horizontal asymptote at 0 (sorry, Calculus I).

Do you need to have delivery deadlines way in advance?

This is one of the main criticisms that Scrum normally receives. In a way, it is logical that Scrum cannot give you those deadlines. At the beginning of the project, you cannot predict when you’re going to finish, if you’re making it easy to change the thing being built as time goes by. But, do you prefer a product that you know “for certain” will be finished in 12 months, but is built over the ideas and opinions you had a year earlier? Maybe you prefer a product that could be finished in a similar period of time, but that you have been able to steer towards your real needs, and you’ve been able to use and test before the final delivery deadline.

Stress!

We cannot sprint for our whole lives. We deliver something and the next deadline is just two weeks away. Then another one, and another one. If we have to run like this for many miles, we will sprint really hard for the first deadline, but we will walk for the last one —and that, with luck. It is something we should bear in mind during planning, from the start.

Is your team able to self-organize?

One of Scrum’s principles is that the team members must make their own decisions and self-organize. Also, one of the requirements is to avoid having teams that focus just on specific tasks, like analysis, testing, design, documentation, development etc., but rather to make sure that every member of the same team can carry out all of these tasks without depending on external teams or members. Can we always have a team like this? What happens if we don’t have one, or if we lack a key component?

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).

Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Agile 101 book: Requirements might change

lunes, 23 mayo 2016 22:27

antoniomartel

0 Comentarios

A few years ago, before completely applying this whole Agile thing, I worked in the development of a web application that should manage the client’s worksheets through a series of steps, a wizard that would lead users through the phase they were in.

We made a full analysis, we collected all the client needs, and from there we compiled a list of features to be implemented. All very normal. Correct, coherent features that solved specific problems. With a thick requirements document and their respective designs, we started to implement these features, one after another.

Back then, we tried to be a bit Agile (in a way) and every two weeks in pre-production we showed how things were going. It didn’t look half bad. It was easy to use and we even got congratulated by clients on the work they were seeing.

We were happy like that, so we went on until we developed, with no small effort on our part, all the features that were included in the analysis document that had been approved. And we deployed them into production…

And as soon as the administration staff used the application for a few days, they realized they could have done with some changes: include a table in each screen with the original documents, so they wouldn’t lose sight of them; avoid going out to another menu when creating an entity; adding more controls at the end to avoid mistakes when filling them in, etc… Most of them were minor changes that wouldn’t take more than two or three days of development, but we had already exhausted our budget (and more).

Amongst the features we had developed from the beginning, there were some complex ones that allowed complicated changes between projects and that were difficult to develop (and test, in order to be able to check every possible case). I asked about them months later but nobody knew anything about them or which menu they were in. It wasn’t considered important. When they had needed something like that, they had cancelled the process and started a new one.

When we started the project, neither I, nor the client, nor the users had an exact idea of what would work well. We simply couldn’t know for sure. What could have been done to avoid this? Well, we should have deployed the basic features to production as soon as they were ready. That way we would have easily seen all these little changes that would have made the application much more practical and easy to use.

From that moment on, in new projects, when users see the need for changes like these, they ask me about the possibility of including them. They have no problem giving up other features for which they no longer remembered the reason for including in the initial contract or that no longer made much sense.

The feature list is drafted from the beginning in the Product Backlog. The client is aware of this estimation and simply says: “Take out feature 18, which would take 8 days’ work, and change it for these other two features which would take 6 days. We save those two days in case we need some other change.”

That is another Agile principle:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

In general, it is advantageous for clients because they get a product that works and is not broken until a new contract for corrective maintenance is drafted (which would involve paying extra money). But it is also an advantage for us as providers, because we offer a project that is a good reference, in which we are aware of and can account for every hour we spend, and we avoid delivering a product that depletes our budget but still lacks important features.

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).

Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

New chapter from book Agile 101: Principles Behind the Agile Manifesto

domingo, 15 mayo 2016 20:00

antoniomartel

0 Comentarios

Nearly 15 years ago, in 2001, 17 software developers met in Utah. They were critical of the then popular software-development models, which they considered rigid or heavy. That meeting included people like Kent Beck, Martin Fowler or the Scrum founders. They had decided to meet in order to talk about the new techniques and processes to develop software.

That meeting gave rise to a number of principles governing the new alternative (and Agile) methods they were proposing: the Principles behind the Agile Manifesto. One of these principles is:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Clearly, this is what should be done in any type of development. We start every project with that in mind, but soon people start getting into a rush. Our director asks how many hours we’ve spent (and we’ve spent a lot already). Our client asks when all the features will be ready. Our workmates ask if they can take that two-week holiday we owe them.

It starts to look ugly. We’re in a mess again. We have to redo the Gantt chart with the new delivery deadlines, we have to look for another set of dates for those holidays (even our own holidays), and we have to give the director loads of explanations. “The client requested lots of changes” “The technology was new.” “We miscalculated.”

Here’s where we should be firm and ask the team for some extra effort, and decline little changes requested by the client. If it isn’t written exactly like that in the contract we signed or the minutes of a meeting we had six months ago, we’re sorry but we can’t do it.

The thing is, clients also did this. They wrote a very clear contract in which they stated each and every feature that they wanted (or the ones they wanted when they drafted it). Maybe they no longer needed those features or had realised that there were other, more important things, but they’re in the contract and they should be done. The project cannot end and leave 30% of undeveloped functionality.

At the moment, we have lost sight of what should be our top priority in our job: early and continuous delivery of valuable software. From here on, there are just tough negotiations and a contract that we would try to fulfil as soon as possible with the least amount of damage possible.

The contract might have tonnes of clauses and stipulations, but regardless of what it says, what the client wanted on signing it was a solution to the problem at hand, not an argument about whether to implement one functionality or another.

But if we deliver our software early and often, we can let clients test it and use it and tell us what they think. We can allow them tell us if there is something missing or what could be improved. They will want us to implement things they find they now need, and they will be delighted in turn to take out that .rpt file-exporting feature that no one remembers requesting or knows why it was requested in the first place.

When we finish the project, the client will have a product that really solves their problems, one that has been evolving while they learned, and one that they have been able to use and test from the early stages of the project. It sounds better for both the provider and the client, right?

New chapter from Antonio Martel's book, Agile 101: Principles Behind the Agile Manifesto

“How do you
manage a project when you have received no previous training in project
management? Well, by suffering a lot.”

Albert Cubeles

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).

Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Agile 101 book

domingo, 08 mayo 2016 20:47

antoniomartel

0 Comentarios

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).

Agile 101 – Practical Project Management

5 Lessons learned in Project Management

domingo, 01 diciembre 2013 18:58

antoniomartel

0 Comentarios

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.

Página 11 de 12