scrum.boulevart.be

We at Boulevart have been using the Agile Software Development with Scrum methodology since 3 years. Unfortunately not all our customers take the agile road, so we still have a mixture, although the agile approach is gaining.

After observing some good results, I went to a training workshop to receive my own ScrumMaster Certification, like all our project managers . I’ve brought an Agile Project Management Scrum Methodology to the Professional Services team - an attempt to deliver multiple projects with shifting deadlines and changing priorities. While not completely geared for client-side development work, Scrum has brought transparency of our developer’s day-to-day activities to the senior management team. These are the guys that always seem to think that projects are “easy,” “will be done very soon,” and that our overall work troubles aren’t a “big deal.”

We are pleased with the early returns that Scrum has provided. As soon as the team broke out each project into discrete chunks of work (aka “stories”), the rest of the company started to see just how much work we had to do. Now, if they want to horse-trade and shuffle priorities, they at least know, in excruciating detail, the trade-offs they are making with respect to all other client deliverables.

Turns out that development is a lot of fun after all . . . .

This video provides you with an easy explantation of how scrum works:

These are a few video’s i found on YouTube, to explain what scrum is about.

We’re implementing Scrum as a process framework for the development of our projects. We’re iteratively implementing it, sprint for sprint. Therefore, this is not a post on how we do Scrum, rather it is a post on why we’re implementing it.

Reason 1:  It’s agile
It’s so fundamental that I’m not going to justify this with a real number, even. It gets a null. We rarely have a complete picture of where we are going when starting a project or a product. Thus, we need an agile approach that supports making discoveries while underway that can, and will, be included in the continuous planning process of the project.

Reason 2 : It’s a framework
That sounds ambiguous, but nevertheless, it’s of the most vital importance for our choice. Admitting that the process of creating great software is an intellectual process, you don’t want a full-fledged (big M) Methodology to govern and control you, just as little as you’d want that if you are trying to be a great novelist (another intellectual undertaking). You want to provide room for, and focus on, the day-to-day contributions and decisions from the development team, not the general approach solutions governed by a Methodology. We want a light-weight framework of simple rules for inducing our great potential as software designers and developers. We are so naive to assume that every employee wants to do their best, and that any rules, processes and frameworks that exists should be there to help them perform at the peak of their potential, rather than see to it that they do their work as they should. We believe the values and processes of Scrum supports this approach.

Reason 3 : Power to the people.
Day-to-day decisions — this is where the magic happens. Scrum realizes and supports this. During the sprint the developers are empowered, and they are able to do their jobs with minimal outside interference. The communication within the team is continuous as daily “Scrums” (short status meetings with no reporting, max. 15 min. regardless of team size) ensure that everyone is clear on daily objectives and progress, with minimal overhead.

Reason 4: Natural selection
Before every sprint (month long development cycles), new priorities are applied to the functionality wish-list (the product backlog) by the product owner. Only the tasks that will create the most value for the business objectives for the software will be put into the next sprint. When the sprint is full, no more tasks are added. This ensures a few vital properties of the project. 1) Natural selection. Low-value functionality in the wish-list will sink to the bottom and into the black hole. This is good, as no coders wants to code low-value functionality, and no product owners wants to pay for it, at least not before having the more important functionality working really well. 2) Just before the sprint, we can use the experience from previous sprints to do better estimation and we know more about the project, so we’ll plan better too.

Reason 5: Done
Scrum emphasizes the value of Done, with a capital D. During “The Demo” at the end of each sprint, no functionality that is “almost done” is given any attention. The goal is to get to Done (potentially ready for production) on all tasks committed to in the sprint. Thus, Scrum applies a focus on doing one thing right before doing four things half-assed. We value this as fundamental and as an imperative attribute of great software development.

Reason 6: Continuous improvement
The retrospect provides a great opportunity for self-improvement. We talk about what went good, and we talk about what can be improved. There should always be something to improve. We pick the most important improvement suggestions, and put them into the next sprint backlog to improve it during the next sprint. Not all improvement suggestions are acted on, but just having heard them sometimes makes all the difference. Scrum provides a placeholder for this activity which we cherish as one of the most important ones for being able to continuously improve the way we work.

Scrum does not allow for any detailed planning for longer than 30 days at a time. So how can you make a list of functionality that will be implemented within 3 months? Short answer, you can’t. If you do, it’s not Scrum, nor is it agile and it is the same as playing at the lottery

Old style waterfall planning let’s you promise:
A) “Within 3 months you’ll have this list of functionality fully functional and ready for launch. (insert impressively long wish-list here)”

Scrum planning let’s you promise:
B) “Within 3 months we’ve shipped three increments of the product. We’ve been focusing only on the most important functionality, so some less important functionality are likely to be missing. But the important ones are there, and they are working properly, leaving your most important and current business goals taken care of.”

History of software development using waterfall planning, shows us that the “A”-promise really is more of a “wouldn’t it be nice if”-statement. It sounds a lot better on a contract, but then that’s also all it does. Research into the software development process has shown us a few things.

1. Up-front and long-term planning misses the target as implicit requirements explode once the implementation of explicit requirements starts to evolve. If you’re a developer, you know what I’m talking about. It’s all those nitty gritty requirement details that no-one was able to grasp or visualize during planning.
2. A 25% increase in requirements complexity yields a 100% increase in solution complexity. Considering this (not indisputable) fact in addition to the first, it does not take long to figure out why the software development industry is know for its hampering of budgets and deadlines.

Benefiting from the Pareto principle, Scrum lets the less important features (likely 25% or more of the requirements) stay at the bottom of the priority list where they belong. Implicit requirements are added to the list (product backlog) during each sprint. The product owner (the customer) sorts the list by importance, pushing the less important features over the edge and spiraling down into the black hole. This, to some perhaps paradoxically, increases the likelihood of hitting business targets with the most important explicit and implicit requirements considered.

The caveat of Scrum is that upon delivery you have with no more probability fulfilled the list of functional requirements initially provided by the customer (they tend to provide such a list). But considering that we humans tend to wish for more than we can consume, and by following a process that helps us weed out the low priority functionality, it is more than likely that no-one will miss it as it’s never introduced. It has given way for a higher purpose, as the implicit requirements discovered during development tend to root in a higher understanding of the business goals, and are of higher importance than most items in the initial functionality list.

With Scrum (and similar agile approaches), we argue that the product is more likely to be ready for launch, on time, major functionality included. Not necessarily precisely as the initial intention, but closer to the current intention. And most important: Business targets accomplished.

Scrum is one of the Agile approaches to building software. In a nutshell, Scrum is a simple approach to the management of complex problems, providing a framework to support innovation and allow development teams to deliver high quality product in short time-frames. Scrum is a state of mind; it is a way of thinking that unleashes the creative spirit while remaining firmly grounded in some solid and long-respected theoretical principles, including empiricism, emergence and self-organization

• Empiricism refers to the continuous inspect/adapt process that allows both workers and managers to make decisions in real time, based on actual data, and as a result respond quickly to ever-changing conditions in the surrounding environment, most importantly the market place.
• Emergence results from an empirical approach. It implies that all solutions to all problems will become clear as we work. They will not become clear if we simply talk about them. Big Up Front Design will only result in Big Wrong Design or at best Big Working But Totally Inflexible Design. When we allow solutions to emerge it is always the simplest and the most appropriate solution for the current context that rises to the surface. Emergence coupled with Empiricism will lead us to the most appropriate and the most flexible (i.e. changeable) solution.
• Self-organization refers to the structure of the teams creating the product of work. Small multidisciplinary teams are empowered to make the important decisions necessary to i) create high quality product and ii) manage their own processes. The thinking here is that those doing the work know best how to do the work. These teams work in a highly interactive and generative way, emerging the product through continuous dialog, exploration and iteration. Self-organization works when there are clear goals and clear boundaries.

In addition to these principles Scrum relies on two core mechanisms: prioritization and timeboxing.

• Prioritization simply means that some things are more important than others. This is obvious, yet quickly forgotten when the “we need it all now” mindset is entered. Scrum helps put the focus back on selecting the most important things to do first — and then actually doing them! Making time to prioritize, and being rigorous about it are essential to the success of Scrum.
• Timeboxing is a simple mechanism for handling complexity. We can’t figure out the whole system at this time, so let’s take one small problem and in a short space of time, say one week or one month, figure out how to solve that problem. The results of that will then guide us towards a solution for the next, bigger problem and give us insight into the needs of the system as a whole.

Organizational Change

With Scrum, the management hierarchies of organizations tend to get leveled and development teams have a more immediate and direct contact with customers. The work environment becomes less command-and-control and more collaborative. Regular, open dialog is encouraged over extensive documentation, and negotiated agreement is preferred to formal and impersonal contracts of work.

The qualities of openness, honesty and courage are fostered at all levels, and individual gain becomes secondary to collective advancement. A Scrum environment is a supportive one, where people at all levels show respect and trust for one another. Decisions are made by consensus, rather than imposed from above and all knowledge is shared in a fearless and transparent way.

Scrum goes against the grain for most companies in the software industry, where a phased approach coupled with a high degree of micro-management, and an insistence on defined processes and extensive documentation have been the norm for over thirty years. Many companies rely on fear and money as the key motivators for their workers. This approach has shown short-term success but more and more companies are beginning to understand that it is not a good long term strategy.

Scrum is still at the early-adopter stage. It will take many years for the majority of companies to recognize the benefits of creating more trustful and compassionate workplaces. Without such change many software companies will likely sink under the sheer weight of their heavy processes, and overstaffed workforces.

Others – those who dare to embrace the lean, lightweight, agile approach of Scrum – stand a greater chance of surviving and prospering. For those who turn to Scrum, and fully embrace it, a reversion back to the old way of working becomes unthinkable. A paradigm shift is occurring in the workplace, and Scrum is an important part of that shift.

Developing outstanding Web based marketing projects is best done using state of the art process management techniques. In terms of “fastest growing trends in managing Web projects” the leading contender is a process called SCRUM.

SCRUM’s been so successful that anyone managing a software development project should consider using it, especially anyone managing any kind of Website or e-marketing project.

The scrum process has been used to develop Web-based projects at Yahoo, Google, Adobe, the BBC and hundreds of other major companies. Wherever it’s applied, the scrum process almost universally increases the projects chance’s of success, and makes the development process much more manageable, and less full of surprises.

The scrum process is so simple that adopting it is nearly transparent to upper management. It’s effective for nearly any size project.

Simply put, the scrum method, or scrum for short, breaks a clearly defined project down into several parts to be done sequentially, and monitors the progress of all team members through a daily meeting designed to identify roadblocks and resolve as them needed to stay on schedule. The scrum development process includes a set of practices and procedures, like rules for meetings, and a set of roles to be assigned to key people.

According to scrum lore the philosophy of how the scrum process views roles is best expressed by a story about a chicken trying to talk a pig into opening a breakfast restaurant named “Ham and Eggs.” The pig declines, telling the chicken, “I’d be committed, but you’d only be involved.”

In the scrum world, the pigs are the people who are working on the project 100%, whose careers are really on the line, and the chickens are the people who are only partly concerned with the development process, like marketing, sales or documentation, or who other wise represent the end user or customer. For this reason, only team members classified as pigs can speak at meetings.

Scrum’s have three types of active roles, or “pig” roles; the project manager, the scrum master, and all team members who qualify as pigs, including the programmers, QA engineers, graphic artists and copywriters.

The project manager runs the project as usual, and the scrum master is responsible for overseeing and enforcing the scrum process (though the PM can opt to also be scrum master).

At the beginning of the scrum the scrum master holds a meeting that determines and clearly specifies exactly what features will be included in the project, a feature set referred to as the Scrum Product Backlog. The meeting then allocates the development time required for those features into a sequence of time periods called sprints, which are usually 1 to 4 weeks long, and assigns people to each feature.

Each sprint has an assigned number of features to accomplish, known as the Sprint Backlog. By the end of the sprint all features in the Sprint Backlog should be complete, and by the last sprint, all of the features in the Scrum Backlog should be finished.

The decisions made at the initial meeting are entered into a project schedule chart, referred to as a burn down chart. The columns represent days and the rows represent team members and each cell tracks the hours remaining. The number of hours each person on the team will need to finish his work is determined, and entered into the column for day one in that person’s row. Each day, each team member must update the numbers of hours remaining to accomplish the task by deducting the hours they actually spent working on the assignment.

Once the scrum has started meetings are held daily, with the following rules:

• Each meeting is exactly 15 minutes long, no matter how many people are attending. This will encourage people not to waste words in their answers.
• Every person at the meeting who is allowed to speak must answer three questions at each meeting. These are: What have you accomplished since the last meeting? What will you have done by the next meeting? What, if anything, is getting in your way?
• Another rule is that people should always stand at sprint meetings. The only exception to this rule should be who ever is designated to record notes of the meeting. (If you don’t feel like standing for 15 minutes, you can sit down and also take notes, or at least pretend to, which is usually good enough.)
• The meeting should be held at the same time in the same room everyday. Attendees, including senior management, may be subject to penalties for being late. Sprint teams at some companies require tardy attendees to wear a rubber chicken hung from their neck for the duration of the meeting.
• At the end of the last sprint, and the development phase is over, a meeting is held to evaluate how well the scrum went, and to identify changes that need to be made in processes and procedures to improve quality and efficiency.

The scrum process provides a great deal of return for very little effort. Few development processes are as simple to implement, and yet so effective. If you have a software project coming up, you should consider using the scrum process. It would be hard to do better.