“I had difficulties respecting deadlines and products were flooded with defects and bugs, which made it even more difficult when accepting changes required by the customer until I decided we have to step into agile world! In Scrum they accept changes diminishing impact because there is no document to update. The team is self-organizing and more responsible so we will have fewer defects in the end. Traditional development models are no longer sufficient or effective.6 months after software manufacturing with Scrum, we understood that all this was just good advertising and worst results were just about to come!”Does this desperate message sound familiar? Yes, too familiar! As a CTO at Pentalog I had the opportunity to meet potential clients with similar problems: “we’ve done Scrum but it doesn’t work for us, so we want to continue in a more traditional, waterfall or v-cycle way…” When this comes to my ears I never react. Maybe they found a context where Scrum does not apply. During further investigations it turned out that Agile practices were not sufficiently mastered or even not applied. Causal analysis showed that it was not related to organizational models, delivery issues…, but more likely about wrong beliefs, agile misconceptions and local optimizations.Migrating from traditional product development to Agile way requires a different mind-set, enabling us to completely deploy and understand the deep changes that must occur! Resistance to change will overwhelm your enthusiasm, will delay ROI and you’ll come to the same conclusion in the end: “Scrum doesn’t work!”Staring at the Agile world with the eyes of an experienced agile practitioner is almost impossible for the beginner. Because common sense is not the same for everybody, less experienced people will interpret “Working software over comprehensive documentation” as “we no longer need documents!” and we can’t transform into self-organizing teams over the night, can we?So, how can “we solve our problems with the same way of thinking we used when we created them?” Albert Einstein. You can’t! A good approach would be to start by training people for Agile practices with trainers outside your organization. A training for Scrum usually takes around 2-3 days, is very efficient but it’s still not enough. You should prepare for a long run. This is where the role of the Scrum Master takes its place. He is there for you to facilitate all that and to ensure that everybody from the organization respects established and agreed values. Be aware that a project manager can’t implicitly be converted into a Scrum Master ! It will require a lot of training and coaching for him too so that he will change his reflexes from a manager to a coach and facilitator. Once again, try to find a more experienced Scrum Master (Agile coach) who will guide you for several months.This is not an easy explanation for the Board: “We’ve bought the best managers money can buy, and now you’re telling me they are not good? What are they going to learn during this training? What are the benefits?”An Agile course should be adaptive. From our experiences, in order to cover the most important aspects of Agile development and Scrum, an entire team would need around 5 days of training.
- 2 days for all the team (Scrum Master and Product Owner included)
- 1 day for Scrum Master
- 1 day for Product Owner
- 2-3 days for the team members regarding agile manufacturing (testing, developing, continuous integration…)
During this training people should understand:
- The differences between traditional software development methodologies and Agile development. When does Scrum apply? Avoid ScrumBut!
- What is business value and business attitude?
- What is wishful thinking and how to eradicate it? Estimations, planning (planning poker), team velocity.
- The different perspectives of building an environment for increased shared understanding (self-organizing teams, team welfare, coding standards, definition of done, simple metaphor, simple design)
- What about self-organizing teams?v
- Agile VS Discipline! Scrum ceremonial.
- Agile testing (test everything, TDD, Mocks, A-TDD, GUI acceptance testing…)
- Pair programming, refactoring (hiding, extracting…), code smells…
- The importance of feedback (continuous integration, frequent delivery)
- Scrum is a continuous process (continuous improvement and learning cycles, retrospectives, impediments management)
- How to continuously improve results in order to bring more value to final clients? Diminish waste!
- Learn to unravel system dynamics, root causes, mental models and local optimizations.
Regarding the second question, maybe the most important one “What are the benefits?”, Scrum is often seen as a cost saving measure for the companies by being focused on business value delivery, product adaptability and time to market. Reports like “The Standish Group’s statistics on software usage” confirm the importance of having a value driven development approach to decrease the number of unnecessary features:Also known as the Pareto Principle, the 80-20 rule, the law of the vital few and the principle of factor sparsity states that for many events, roughly 80% of the effect comes from 20% of the causes. This is why an Agile team shall continually ask what incremental value a new feature will deliver over another.Our experience shows that in the first semester you will earn between 25%-50% in productivity if you are already aligned with an international standard like ISO 9001:2008 and after 2-3 years of continuous improvement with Scrum, the gain can raise to an astonishing 100%-200%.It requires a lot of courage for your team to achieve that, but we will see more about that and Scrum values in future articles.