Archivos por Etiqueta: SCRUM

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 – Practical Project Management

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

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!

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.

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.