Archivos de Categoría: English

Agile 101: How to write an Agile book

domingo, 10 julio 2016 19:00

antoniomartel

0 Comentarios

Yes, you can also write a book in an Agile manner. Not only software can be created this way. All these Agile things can be applied to a myriad of fields, not only to technology. In this chapter I will tell you how I used this work philosophy to write the book that you have before you:

Focus on what’s important,
delete the non-essentials

Nowadays books—especially technical books—are going through the same phenomenon as CDs did a few years ago. You bought a CD only because you had heard that song on the radio, but, how could a CD have less than 20 songs (and cost less than 20 dollars)?

It had to be filled up with something. Maybe the last few songs did not have the same quality as the two or three first hits in the disc? Well, it was necessary to justify the price, to pad it a little. This could make you hate the author for those last three songs in a duet with Tom Jones or the techno-pop version of their first hit.

The same can happen with books. We feel better if our book is 500 pages long, and we write it for two years but, at what cost to you, the writer? And for the reader who buys it? Probably that reader is only interested in the chapters on Agile quotes or about Scrum’s advantages.

Something of the sort happened to me while I wrote this book. It had very few pages and I was tempted to add some filler chapters. They weren’t really as interesting as the rest and they weren’t as close to the main subject of the book. I ended up taking them out. The first version of the book was about 67 pages long, but I chose to keep it that way instead of having readers think that the book was too long or too boring.

Real artists ship!

This expression, attributed to Steve Jobs refers to the fact that real artists are not constantly re-thinking their work until they have the perfect painting or the perfect sculpture. They ship their works, put them up for sale, and then see what the market is really interested in.

Have you written a tutorial on how to install Pentaho? A WordPress configuration manual? What are they doing in a drawer? Get a cover (there are hundreds of websites for that), format it, write an attractive description, and put it up for sale at Amazon’s KDP, at iTunes or wherever you want.

It is only 30 pages long? Well, then sell it for one or two dollars. If you sell a few you’ll get a return for the 20 or so hours that it took you. Also, you’ll have learned lots of things about digital marketing, sales, royalties…and also about which kinds of subjects sell books and which don’t.

Perfection is a vertical
asymptote

No matter how much you try to write the perfect book, with the perfect cover, with the exact price to maximise sales and no typos… you won’t be able to do it. Perfection is a vertical asymptote (sorry again, Math 101 Calculus).

The better you try to make it, the higher the cost will be for you. When you’ve put an enormous amount of hours into it, putting in another enormous amount won’t get you any closer to getting a bestseller.

When I put the book up for sale, I realized from the first opinions on the book that users thought it would be a Scrum manual. I had to learn from that and change the description to make it clearer. Small changes in the description had very high impact on sales.

In the same way, when I updated the book to its second cover, sales increased by 30%. Sadly it went further down when I changed it to the third cover. It was more expensive, and in my opinion prettier, but apparently Amazon’s users didn’t like it.

Your leads will tell you if they find the content, the cover or the subject interesting or not. You can think it over again and again, but until the book is not in the virtual shelves you won’t know what works and what doesn’t. Avoid the paralysis that sets in with perfectionism and don’t overthink it. Put your book up for sale and let them decide (remember, real artists ship!).

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: Scrum’s advantages

domingo, 12 junio 2016 20:00

antoniomartel

0 Comentarios

Scrum pros and cons: blue pill, red pill

I don’t want to become one of those Agile evangelists, preaching everywhere about how good and modern it is to be agile. But now that we’ve discussed the disadvantages of Scrum, we should look at Scrum’s advantages. I’m going to focus on one of its brightest features: regular deliveries. Thanks to these deliveries, Scrum will make the following possible:

Clients can start using their products

The client can start using the product even if not all the elements have been built. If 20% of the new features have been developed—which are the features that will be used 80% of the time according to the Pareto principle—users could start enjoying the product.

With the feedback of users after trying out one of the deliveries, we might realize that some of those features are far more important than 80% of the remaining tasks in the Product Backlog. Somebody could say “but the draught of the new regulation no longer requires a signed approval form” or “actually what we need is a button that would cancel the procedure” (we actually received these two comments in real life).

We can decide where we’re going

Businesses change, needs change, regulations change. And what was key when the project was signed might not be so important six months later. The client can pursue new goals, what to do in each new sprint and what we should focus on in our next delivery.

Divide and conquer

Colossal tasks require colossal efforts. If we must deliver just a part of that task every two weeks, our load will be lighter. Smaller, more manageable tasks make us feel that our job is easier. In each delivery, we have the feeling of having advanced one more step towards the final goal.

Fewer surprises

When we see our product grow, little by little, we all get an idea of what we are doing with it and if it is going to be useful or not. Also, we will know pretty accurately at what speed things are being delivered and how long it will take to finish up. Should we correct our course? We would know that in weeks.

Deliver what the client needs

One of the basic principles of Scrum (and also one of its main challenges) is accepting that clients can change their minds about what is or isn’t necessary. With Scrum, we strive towards providing a flexible response, admitting that clients themselves may not have put their finger exactly on the problem, and that often, as the project advances, they may come to realize what they truly need. That is why, among other things, Scrum is considered an Agile methodology.

The list of requirements and features created at the beginning is open and can be modified at any time. It contains rough estimations of the amount of effort that each feature requires. Before each iteration, or sprint, a group of these requirements is set as the goal for that period. Two or three weeks later, requirements may have shifted and the new goal might be in another direction, rather than the one that was set a few sprints back.

It is a new way of working, and a bit hard to adopt, for both the client and the provider. There are other, apparently easier, ways. We can always go back to the traditional formula. First we analyse the problem for months. When we’ve determined what should be built, we start developing it for a few months more. When we’re finished, we cross our fingers and deliver our final product to the client.

After this step, who hasn’t heard sentences like: “but this is not what I wanted, there’s this thing missing here…” or “no, it wasn’t like this, you misunderstood me” or “yeah, it’s fine, but I’m going to call the Director, actually he’s the one who has to sign it off” After months of work, of stress and rushing around to deliver by the deadlines, clients have not received what they need and we need to work even more to try and patch up the proposed solution.

How Scrum helps to build big projects

Revisiting Raúl Hernández post “Learning how to build cathedrals” I started reflecting on that well-known story about building cathedrals. In the story, two workers are chipping stone to build a cathedral and somebody asks them what are they doing. One complains about how hard and never-ending it feels to build the wall he is working on while the other one simply replies “I’m building a cathedral.”

I have wondered if it is possible to be agile when you are building something so big. I think that the answer is yes, you can. At least I can think of a few advantages of being agile when you are immersed in a project that is the size of a cathedral:

With a framework such a Scrum, you’ll always bear in mind the final goal and the features it should have. In the Sprint Backlog you will have a series of requirements such as the creating a ground plan, raising the vault, decorating doors and windows, and many other things that will give shape to the final cathedral.

But once the goal has been defined, we have to start chipping stone. At the beginning of each iteration, the team will choose which tasks can be started from the list of things that are pending construction (and that has been prioritized by our client). We will define a smaller goal for the next few weeks, so we’ll have a new goal, a much closer goal that will help us not to despair at the distance that still separates us from the final goal. It is the moment to pick up our hammer and our chisel.

When our pending tasks are divided into small groups to be solved in fixed amounts of time, they are timeboxed. This is a divide and conquer strategy. Plan your most immediate goal and what you will do to solve it without getting overwhelmed with all the work still pending. A Burndown Chart will also help you see how the amount of pending work is diminishing and that, however slow it may seem, you are making progress towards your final goal: the cathedral.

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

Página 8 de 9

Archivos de Categoría: English