Innovative companies, and those who will be ready when the economic crisis will be over are choosing for Agile/Scrum approach so that they can go early to market and earn money fast while continue to improve products.
Therefore the market for Scrum specialist is increasing rapidly : see article
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.
