Archivos de Categoría: English

Agile 101: Scrum’s sprint 0 and the initial design

sábado, 16 julio 2016 19:00

antoniomartel

0 Comentarios

Sometimes we’re in projects in which we need to prepare a large number of things before starting out. Can we start building without stopping to plan or analyse what we’re about to do?
When we read about Scrum, we get the impression that all texts start directly with development, but…what about environment, team or office preparation tasks? What about design? Shouldn’t we stop to think about the whole design and architecture of what we’re about to build before we start programming?

About preparation or “before” programming. Some people call it “sprint #0”, the sprint where you prepare your tools, install the stuff you need, train the team, etc.. It can be a longer sprint (3, 4 weeks or so). Some detractors criticise this sprint because it is not agile, and because it hides some work that is taken care of in the same way as the rest.

It is true that it can be very comfortable, because we tell the client that we’ll be back in 3 weeks to have the preparation meeting for the first sprint, and by then we have organized it all. I have also used those zero sprints in my first projects, but now I prefer to solve those issues also in an Agile manner.

I try to make every one of those tasks (installing the development server, installing the demo server, creating a project and tasks in Trac or Redmine, installing the Integrated Development Environment or IDE, etc.) part of the first sprint and, if possible, have a set deliverable at the end of each demo.

In that demo, we could show, for example, the project-management tool already installed in the final URL and the task list with the tasks ready to be assigned, or we could launch the IDE in that demo meeting, and check whether the environment has been created correctly and whether Jetty executes a “Hello World” application correctly.

Another important step is the initial architecture design. If we make a huge design with all the application architecture (known as a big up-front design) before we start programming, we will be returning to a waterfall design. Firstly, we analyse everything, three months later we do all the design work during a couple of months, and then we program everything in one go until we finish it six months later. If we finish all work and show it to the clients and they say: “that is not what we discussed a year ago…” then we have a problem.

It is better to design one of the modules of the application, or one of the new features, then draft the specifications, and finally send them to development. While part of the team implements them, analysts can gather requirements for another module or another feature, and go on doing so sprint after sprint.

There will be sprints in which we won’t have new stuff to analyse and others in which the development goes a bit faster than the specifications, but normally there is always some task ready to be carried out while Product Owners sign off the latest requirements, or until those requirements are completely defined.

If we work like that, new modules or features could be regularly deployed to production or preproduction, so users will be able to take advantage of them without waiting until the very last feature of the application has been designed.

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: Scrum for fixed-price projects

jueves, 14 julio 2016 19:00

antoniomartel

0 Comentarios

One of the most common questions we ask when we’re wondering whether we should adopt a methodology like Scrum is how to face the fixed-price contracts that are so common in public procurement and many other sectors. One of the Agile principles says: “we welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” This means that using Scrum we will be flexible with features we must develop, and we will admit new ones that were not in the original contract listing. This sounds very good but… the final price of the project is not going to change!

I work in the public-procurement department in a software-development company. That means that in at least 90% of the projects I work on I have a public institution as a client. Contracts are normally defined by a document with specific administrative specifications and another one with technical features. These contain all the services that are being hired, the characteristics of the product to be developed and the maximum price of the tender. They include even the technical features of the software and the profile of the projects’ participants. It is all very narrowly defined. It is the price that the public administration must pay to avoid arbitrariness.

If our company has been lucky enough to win the tender, then both of us, provider and client, have to face the harsh day-to-day reality of projects. Circumstances change. New legislation comes up that affects the project. Things that were deemed correct a few months ago are no longer valid, because needs have changed. What should we do? If we adapt the project to every change that the client needs, then we providers have to bear the brunt of additional cost. If we refuse to change anything for the client, always waving the contract and its specifications in their face, we risk delivering something that might be perfect for last year’s decree, but—for that very reason (or for any other reason)—is no longer of any use.

The way to avoid this, or at least the way that has worked best for me so far, arises from the way of working in Scrum projects. At the beginning of the project I make a list with the features to be developed, and give them a score that the client knows right from the beginning.

I normally give the example of a large jar full of ping-pong balls. Each ball is a feature that must be developed. The jar is full. If the Product Owner wants to include two new features, I ask that person to tell me which other features—or ping-pong balls of a similar size—should we take out of the jar. Normally this vision solves the predicament and the Product Owner does not resist giving up other features, now recognizing that they aren’t important. If it all gets recorded in the meeting’s minutes and, most important of all, if the Product Owner understands what is being given up and what will be gained instead, it is normally a comfortable solution for both sides.

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: Scrum in a maintenance project

martes, 12 julio 2016 20:00

antoniomartel

0 Comentarios

There is a common doubt among those considering using Agile methodologies to manage a project: would it be possible to apply Scrum to projects where, on top of the upcoming and planned tasks, there are frequent interruptions to solve maintenance problems, to correct errors or to resolve issues? Many project managers face these types of problems and use several approaches to tackle them. Let’s see some of those approaches:

Short sprints

With this solution, we will keep the tasks that have already been programmed for that sprint. If our sprints are 1 or 2 weeks long, we will be able to make the unplanned tasks a priority on the to-do list for the next sprint. If the sprint is one week long, we will start urgent tasks after 3 days, on average.
In an ideal world, this would work but it would pose some disadvantages. Not every issue can wait for a few days to be solved. A whole service could depend on it.

Low load factor

If we know that as a general rule we will have unplanned tasks or issues that we must solve quickly, we can lower our load factor during the sprint so we have “room” to solve these problems.
If in each sprint the team has the capacity to solve 10 planned stories, we could promise to deliver just 7, so the team has time to solve urgent issues. That way we won’t fail when it’s time to deliver what we promised, sprint after sprint.

In my opinion this solution can be useful in some projects but it could create another problem. Let me explain. Normally the load factor is 75%. If we lower it so we’re able to devote 30% of the team’s time to urgent tasks, we should apply a load factor ranging from 40 to 50%. On this 40% we’re using Scrum but, how are we managing the rest of the team’s time? What do we know about that pile of tasks that we’re solving sprint after sprint?

A different team for each type of task

This solution consists of having a Scrum team for the identified and planned tasks, and a Kanban team for the urgent issues. With Kanban we can add new tasks to the TO-DO column as they arrive, and we will follow them up until they get shifted to the DONE column. With this the team will be even more agile, reducing the overhead in meetings and planning that we could suffer with Scrum.
We still have a dilemma with unplanned tasks, which are, well, unplanned. There will be times when the Kanban team providing support will be oversized, because there are very few issues. But then a week later the number of issues and their importance could be so high that we will need any help we can get.

To minimise those risks, we could rely on the previous solutions. We could have short sprints, so the Scrum development team can plan the tasks for the next iteration. We could also use a lower load factor so the team can have a bit of room in their planning to give a hand if needed. In the same way, the support team can help with planned sprint tasks when their TO-DO column starts to look empty. To make the most of this, it would be good if all members in all teams rotated, so that everyone knows every aspect of the job.

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