scrum.boulevart.be

Technology is not an exact science, but a real complex environment. It is not as building a wall from 1×1 meter, where you can calculate how much time a construction worker takes to build the wall. During this process there are not many unforeseen things that can rise up.

In technology projects nobody can foresee everything upfront and therefore it is crucial that a customer understands this. In Scrum time & budget are fixed so the only possibility is to play with priorities and functionalities. If at a certain point a problem rises, you and your customer (scrummaster & product owner) should decide which item you should drop to keep the budget & timing in control.

One of the best aspects of agile development is the ability for a team to frequently learn from their mistakes. It’s especially crucial that this happens in a blame free environment. When something goes wrong during an iteration, it’s important that no team member is singled out. The entire team accepts responsibility for their failures and successes together. And when a team makes mistakes, they need to learn from them. The key components for in a team’s ability to learn from their mistakes are the attitude and interactions of the ScrumMaster and the customer.

There are a few things a ScrumMaster must do to help their teams learn from their mistakes. First and foremost, the ScrumMaster cannot be a fixer. When things are broken or not working the team, not the ScrumMaster, must figure out how to fix things. If the ScrumMaster continually steps in to fix the problem, the team never learns how to fix a problem for themselves. This leads back to the old command and control structure of more traditional development approaches. Instead of being a fixer, the ScrumMaster needs to be an enabler and moderator

After working several years with scrum now, we decided that it was time to all get our Scrum Master certification. Last week we had a two day training by Joseph Pelrine

We went to the training with 8 project managers, some of them already familiar with the agile methodology for years now (like DSDM, Scrum, XP) and some who just entered the beautifull world of scrum.

The following colleagues are now certified scrum masters :

Claudio Capodifoglia, Stefanie De Preter, Hilde Van Dyck, Koen Bruers, Wilfried Ombelets, Guy Ceulemans, Sven Luyten, Luc Segers

Joseph Pelrine (info@metaprog.com) is an agile pioneer, a leading Scrum/XP expert, and Europe’s first Certified ScrumMaster Practitioner and Trainer. As a facilitator, he concentrates not only on the technical side of software development, but also on the “people” side, working at enabling customers, managers and developers to communicate more easily and clearly with each other.

The main conclusions from this course are things I already practice several years but it was good to hear it once again :

Projects must be FUN. In my experience, in a lot of companies, projects are done in a way of throwing the responsability each time ‘over the wall’ to the next in line, for example from concept designer to graphical designer to developers, to testers, … By doing this, the ‘team’ takes no ownership of the project. With scrum the team takes full ownership of the project and therefore the quality and ideas within the project increases a lot.  Same for working hours, whenever developers need to do overtime because of unrealistic deadlines or whatever, they get burned-out and that’s why a steady pace (with minor overtime :)) is more realistic and keeps the spirit high.

Development is NOT an exact science & mistakes can happen. I mean, you cannot cover or know everything upfront (if someone thinks he can, he must be GOD). So if someone asks me to estimate a certain task, i can only make a rough estimate based on experience and information i have a this point. A lot of things can change during the development or unforeseen things can rise up. Those problems should be identified and addressed to the customer at the time they occur and the customer should be aware that this can happen.

I’m still gathering all the other conclusions and I’ll post them soon.

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.