(2 votes, average: 4.50 out of 5)
Loading...“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. 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.
Vasile Putina
October 19, 2011 at 1:42 pm EDTI think the people who says “Scrum doesn’t work” don’t know exactly what Scrum mean, tryed to use an “Adapted Scrum” metodology or because of an another reason didn’t manage to implement it corectly. For me a “self-organizing team” it’s a dream that serve as a final target for continuous amelioration of team work.
Cristina Stoian
October 19, 2011 at 2:01 pm EDTI found your article very interesting. It is almost a law of nature that individuals tend to label hard&useless the method that requires the most effort, forgetting at the same time that ultimatelly, if done properly, it brings the best results. Before reading your article it I was also getting deeper into analysing Scrum methodology, especially from the perspective of a Scrum-Product Owner. I went from the basics and then deeper into some case studies. In my research of I found out that the major hiccup for this role is the tension between authority and responsibility. The harder task for the Owner is to strike the right balance of involvement. Can you recommend some training material/books/studies that deal specifically with this?
Cornel
October 19, 2011 at 3:14 pm EDT@Cristina, as it is difficult to create a ScrumMaster it is also difficult to identify and train the Product Owner. The role didn’t exist till recently. To quickly describe the responsibilities for the Product Owner: define the features, lifecycle and a shared vision of the product. Skills required: qualified for negotiation and product definition techniques, high level of expertise in the required business domain, capacity to take decisions and to define features just in time. The following references treat most of the common traps for a PO and cover Scrum from the basics till advances scenarios and very useful tools: Must read! Scrum Primar http://www.rallydev.com/documents/scrumprimer.pdf -Scrum: Le guide pratique de la méthode agile la plus populaire – Claude Aubry -Succeeding with Agile: Software Development Using Scrum – Mike Cohn -Agile Product Management with Scrum – Roman Pichler -User Stories Applied: For Agile Software Development – Mike Cohn -Scaling Lean & Agile Development – Craig Larman -Practices for Scaling Lean & Agile Development – Craig Larman You just gave me an idea for another article 😛 Hope this will help you developing as a PO!
Arthur Peltier
October 19, 2011 at 4:41 pm EDTGood article ! What I retain from this article (and my short experience) are the following points : – Avoid ScrumBut! – “Working software over comprehensive documentation†is not “we no longer need documents!â€. – The importance of feedback (continuous integration, frequent delivery). – Scrum is a continuous process (continuous improvement and learning cycles, retrospectives, impediments management). These are soooo true. I tried to use scrum after reading a couple articles and a book or two but it didn’t work right from the beginning (I had left some ceremonials out that seemed a hassle)… Got there after a couple of months of iterations and retrospectives : once the organization/velocity looked right and the team was self organized, I looked back and understood what scrum was really about. I have been using it ever since… More surprisingly, I saw that we had actually re-implemented all the good practices that I had thought would be not adaptable to my context >> ScrumBut doesn’t work ! Scrum does !
Ion Vasilov
October 19, 2011 at 5:20 pm EDTThank you for an interesting analysis. Certainly the process will not work itself. It is very important that all the involved people (client and provider) understand and follow their roles responsibilities, the Agile/Scrum philosophy and principals. A key factor is the setting of a clear project objective and the motivation for the team. And when I saying the “team”, I mean the common “project team” consisting client and provider people. Without these there is no way to succeed with Scrum.
Marius I.
October 26, 2011 at 5:13 pm EDTGreat article, but I detect a halo effect in your analysis: “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%.” This analysis is based on what? On opinion of people involved in SCRUM projects after having applied this methodology? How has this “astonishing” rate of productivity rate been measured? And by whom? If it’s by people involved in SCRUM-approach projects and it’s a post-project analysis they do by themselves, it doesn’t say anything -one could mitigate that an alternative development approach COULD have brought exactly the same results (only it wasn’t tried on exactly the same project with the exact same people, was it?) Generally, there is no golden rule. And this is why I particularly like this part in your article: “Maybe they found a context where Scrum does not apply.” Could you please detail what are the contexts where SCRUM is more desirable? Thank you!
Cornel
October 31, 2011 at 1:06 pm EDT@Marius, sorry for my late answer! Numbers written above are results from our experiences, from projects which passed from the traditional to agile way, mostly migrated from V-Cycle to Scrum. The performance rate is calculated based on number of features delivered in a specific amount of time =>costs per feature including defects solving=>“Scrum is often seen as a cost saving measure for the companiesâ€. When does Scrum apply? it is a tricky question. Scrum it is not the only agile framework and none of these process tools are complete or perfect. So when we compare tools we should “compare for understanding, not for judgmentâ€. When I’m comparing, I’m keeping in mind two different aspects: 1.Philosophy and principals of the method so that I could categorize them as a.traditional (sequential) : V-Cycle, Waterfall,… or b.agile : XP, Scrum,… Starting from their focus: process, people, tools…? What values: commitment to business value, to respect a planning..? What roles? How we continually improve the process and ensure a sustainable pace? How do we treat information?… 2.Prescriptive VS Adaptive, depending on the number of rules (constraints) that the framework/model imposes (http://www.crisp.se/futureofagile/slides/henrikkniberg at page 8) My answer is becoming quite big so I think it would be better to write another article on this subject but from my opinion the main actor who’ll make a difference is the client. Here you can find a presentation where we gathered the most frequently asked questions during their visits: http://www.slideshare.net/PentalogHighTech/pentalog-scrum-vscyclev. Hope I’ve answered your questions!
Daniel Taivan
October 31, 2011 at 5:01 pm EDTInteresting article and the title says it all… After working in agile for about 3 years, I agree with the fact that the 1st thing that must be changed is not the process, but ourselves(our mindset). From my point of view the 4 agile principles from http://agilemanifesto.org/ can be resumed by qualities that if we developed them is more easy to understand& work& value agile world: flexibility, focus, priorities, value added… And I believe that if we really stick to this 4 basic principles, at the end of the day we will be fulfilled in our work& sure that we really helped the client& did the right and not the written thing…going the extra mile (and not to be read extra time). Regards, Daniel