Giuseppe de Simone - The Mango Tree: How to make your Company Agile
•Download as PPT, PDF•
2 likes•710 views
Agile SW development is becoming mainstream. The pattern repeats the same over and over. "A company develops SW products by means of expensive projects. Each project takes a long time to be finished and has usually a complex organization, with many roles involved. Meanwhile the market gets very turbulent and it becomes more and more difficult to predict long-term customer needs. At the same time customers cut down investments and a strong competition rises: customer capitalism age has come. The company finds themselves not equipped to navigate in a stormy sea. Until someone gets a great idea: let’s adopt Agile!" And here´s where the real challenge starts. Agile is not plug and play! It's not a simple upgrade of the SW methodology currently in use in the company! Embracing Agile means much more than the mere application of a number of practices: it changes some of the basic assumptions and thoughts about how products get developed! So what is needed for an organization to really leverage on Agile SW development to deliver quality products in an effective way? The talk, based on the experience and the learning of the speaker as a coach at Ericsson in Italy and Sweden, will show what you cannot miss to set the foundation of a successful Agile enterprise transformation, whether you work in a big or small company.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (14)
More from Agile Lietuva
More from Agile Lietuva (20)
Recently uploaded
Recently uploaded (20)
Giuseppe de Simone - The Mango Tree: How to make your Company Agile
- 1. HOW TO MAKE YOUR COMPANY AGILE AKA THE MANGO TREE Agile Tour Vilnius October 8th , 2015
- 4. The starting point Why by Ksayer1/ CC BY 2.0
- 9. Focus on People’s Skills
- 12. It’s not enough to do your best; you must know what to do, and then do your best. W. E. Deming
- 15. 3. Start growing small plants
- 16. Run experiments
- 17. Run experiments Ref. Mike Cohn – Succeeding with Agile, Software Development Using Scrum
- 18. Scaling up
- 20. The Cultural Change Value by Got Credit / CC BY 2.0
- 21. The Cultural Change Mixed messages by Rich Anderson / CC BY 2.0
- 24. Culture follows structure! Subordinate every structure to the purpose of delivering value as fast as possible!
- 25. Make your Transformation Self- sustainable › Internal Coaches › Communities of Practice › HR Green and sustainable by Rick Harris / CC BY 2.0
- 30. Summary
- 31. Failure patterns
- 32. In God we trust; all others must bring data. W. E. Deming
- 33. Fruits 0 10 20 30 40 50 60 12A 13A 13AFD1 13AFD1 MP Days Releases Leadtime in development phases One Pager Feature Study Execution
- 34. Fruits 0 10 20 30 40 50 60 1 3 5 7 9 11 13 15 17 19 21 23 25 27 NumberofTRs Number of months after GA CustomerTRs trend LIIMS 24FP2 LIIMS 12A LIIMS 13A LIIMS 13AFD1
- 35. The Inevitable Discovery Agile development will not solve any of your problems. It will just make them so painfully visible that ignoring them is harder. Ken Schwaber
Editor's Notes
- Last Friday I met a colleague during a coffee break.We were sharing some views about what had happened during the week, when he said: ”You know, this transformation we are all undergoing is like a mango tree. Everybody seems to want mangos, but no one seems to care about how juicy they are and to know how to get juicy mangos”.Nice way to put it: don’t you think so? Then we started building upon this metaphor and having fun taking it to the extremes. And I think that, what we got out of it at the end, was really good way to explain what does it take to get a team or an organization become Agile or more generally to make a change successfully happen. So what will a good gardener do in order to get the juicy fruits she wants to harvest in her garden? Then we started building upon this metaphor and having fun taking it to the extremes. And I think that, what we got out of it at the end, was really good way to explain what does it take to get a team or an organization become Agile or more generally to make a change successfully happen.
- 1. Decide what fruits or vegetables you would like to collect The first step is definitely to define what kind of garden you would like to build and what fruits or vegetables you expect to get. Then you can go and buy the corresponding seeds to plant: of course you need to plant mango trees if you want to get mangos. On the other hand you will never get mangos out of onion seeds (for instance have look at this article from Lyssa Adkins to check out what to seed to get a high performing team)
- Due to what we said above, it is easy to understand that any successful Agile transformation implies a top-down approach, in terms of Company values, Management culture, Vision, Business goals and above all senior management support: you cannot do anything otherwise. However, changing an organization (irrespective whether big or small) into being Agile is not like the nth Change Program to be deployed with targets to comply with and a well-defined plan to stick to. There are aspects that need to emerge bottom-up, like practices to be selected by empowered and self-organized teams. So an Agile transformation is a sandwich transformation: you need 2 equally big slices of bread and both are essential.
- 2. Work a good piece of land Quality of seeds is essential to get juicy fruits, but so is quality of land. So make sure to have the right environment for the plant to grow strong. Plants growing nearby can also affect the taste of fruits and vegetables: for instance if you grow lettuce close to artichokes, it will probably get bitter. A good gardener knows that, same as she knows how air pollution can also be very detrimental.
- Training managers Given the importance of the top-down part in the enterprise change, the very first step is training managers, for them to understand the why, be able to share and communicate the Vision, embrace Agile values and be ready to support people with a new leadership style. Many times this critical step is down prioritize, if not even neglected. It is too easy to fall into temptation that becoming an Agile organization means making Scrum teams work and that managers, well, they are clever enough that can handle themselves or can get it with a short summary from a developer attending a Scrum course: being a manager in an Agile organization is a totally different job and requires new tools which must be learnt and cannot be improvised.
- Creating a successful Agile organization does not simply mean make a number of Scrum teams work: it means creating all the conditions around to enable those teams to succeed and get astonishing results. The Transition Team is an operative team, with the goal of helping and supporting the organization in implementing the Agile Transformation, by supporting teams, removing organizational impediments, training and coaching people, spreading the Agile values and Lean thinking. The team works as an agile team, driven by the so-called Transition Backlog populated top-down by the organizational transformation strategy and bottom-up by impediments from the team.
- 2 concepts Training is not enough Lean is respect for people : management goals is to focus on improving people’s skills, teach people how to solve problems Create the new roles In order to scale up you need to build new skills and behaviors for people to fill the new roles of Scrum Master, Product Owner and Scrum Developer. This is best done by means of a mix of training, mentoring and coaching and is a typical item in the Transition backlog. Understanding that we’re talking about new roles, you cannot find in the existing organization, is a critical success factor. One of the worst (and yet easy and most common mistakes) is to create a mapping between existing and new roles, like System ArchitectProduct Owner or Project ManagerScrum Master. They are totally different jobs and you need to realize this and prepare to help individuals who are willing to learn and challenge themselves to fill the gaps needed to move to the new roles.
- WHAT AGILE IS
- Shu-Ha-Ri: Follow the rule, Break the rule, Be the rule
- Taylorist vs Lean approach
- Able to deliver value to customer: organize teams around delivering value Logistics is important Cross-functional teams Cross-functional teams who can deliver potentially shippable product increments at each iteration are a key element in a successful Agile enterprise. So one needed step is to change your organization, remove functional silos and have self-organized teams of 5-9 people with all needed competences working together permanently. And this might imply changes in the office logistics as well, to create the right environment to enable team collaboration. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation – 6th Agile principle
- Scrum is not enough! Scrum is a very powerful way of organizing work, but doesn’t say anything about how to practically do the work. Instead the biggest challenge for a waterfall organization is delivering a potentially shippable product increment in a short iteration. This implies finding new ways of doing things, applying state-of-the-art technical practices and build teams of professional developers, who are able to find the right solutions to always new problems. Continuous attention to technical excellence and good design enhances agility. – 9th Agile principle
- 3. Start growing small plants So how do you think you can verify whether you bought the right seeds and you worked the land properly? Will talking about how the plant should look like help? Most probably not. Instead a good gardener would start planting some seeds and grow some small plants. She would water the plant; she would ensure it gets enough sun (but not too much); she would fertilize it and protect it, so that it grows strong and can produce the first fruits.
- Always start from one team, better if a great team! The pilot project Since we’re talking about applying an empirical process, the starting point is to setup an experiment in terms of a pilot project. Scrum can help out with its framework to give some guidance and some practices which help understand the agile principles behind. A pilot project can provide objective information on the feasibility of rolling out Agile to all the organization. Craig Larman says that if an organization is not able to implement real Scrum with only one team, how can they succeed in scaling it in the whole enterprise?
- But be aware of choosing a proper pilot project. It needs to be important and critical enough so that people will consider it a serious try and a valuable success (it should be used to gain even more management support for the change), but not too critical to create a safe environment for possible failure. It should be end-to-end and therefore include all the stages that are needed to bring an idea into a product and it needs to be closely monitored and supported by senior management, ready to fix possible impediments.
- Leveraging on the feedback from your pilot project and acting on the findings, you can start scaling up incrementally. This will allow better control and will enable the organization to build internal capabilities to help the teams that start later. If you don’t know what you’re doing, don’t do it on a large scale – Tom Gilb However beware not to be too slow, to avoid the organization finding them in the ford for too long and losing momentum, sense of urgency and a clear direction about the change to make. Do not scale processes, but scale values, practices and learning
- Shu : Shu phase will mark the adoption of Agile practises by an organisation. The goal will be to learn a particular practise like SCRUM and follow it without any modification. Mixing up too many things or trying to do lot of variations will only make the path tedious. It can also result in not realizing the actual advantages of the process. Ha: Once a process is followed To a T, adapting can be accommodated to know the best fit for an organisation. Its logical to have deep understanding of a process and understand what is working and what is not before trying to branch out and try variations. In Ha stage, organisations try to figure out what works for others and learn from them. Ri: Ri is an advanced stage where the learning is mature enough to give birth to innovations. Here, the organisations evaluate their own experience and learn from them. An organisation can be called truly Agile when it has reached the Ri stage.
- Cultural change It’s not about doing Agile: it’s about being Agile, by embracing Agile values and principles. This means primarily focusing on value, on what really makes your customer happy and not your boss or the boss of your boss. Prioritize your work based on the contribution it gives to the people actually paying for the product and not because “we have always done like that” or in order to make people busy:busyness is not a good business. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. –1st Agile principle
- Cultural change It’s not about doing Agile: it’s about being Agile, by embracing Agile values and principles. This means primarily focusing on value, on what really makes your customer happy and not your boss or the boss of your boss. Prioritize your work based on the contribution it gives to the people actually paying for the product and not because “we have always done like that” or in order to make people busy:busyness is not a good business. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. –1st Agile principle
- Then let self-organizing teams to pull the work they are able to do. This is very much connected to why Agile. We’re in an industry with such high levels of complexity and uncertainty that we can no longer assume we can know or control everything goes on. So there’s no other way than building empowered individuals and teams who are able to take decisions autonomously using their best capabilities and judgments in the moment, respond to changes fast and reach a defined goal in the most efficient way. They should be able to navigate through storm. The best architectures, requirements, and designs emerge from self-organizing teams. – 11th Agile principle
- Remove roles: have people collective responsible. When you have one responsible, all others feel not to be.
- If you have silos, you will get silo culture If you have many coordinators, you will see lack of responsibility and people not stepping up If you have check-point and committees to ask permission to, do not be surprised to get lack of innovation and lack of initiative Subordinate every structure to the purpose of delivering value as fast as possible
- Make your transformation self-sustainable · Build internal coaches who can teach and coach the new roles, support people to work as performing teams and be permanent change agents: if you’re really Agile, you’re never Agile enough. · Nurture Communities of Practice to give people a place where to meet colleagues who share the same passion or interest and learn from each other. · Adjust your HR processes (Performance management, career models, recruitment, reward and compensation) to support your transformation, instead of giving contradictory messages, and enable a collaborative environment of high level professionals.
- 4. Taste the fruits and decide what to do Finally she will happily pick the first fruits and taste them to check if they are sweet and juicy enough. Sometimes you will not even need to wait until the fruits are mature. It won’t be hard to see quite early if you’re getting the right fruits in the first place: you will pretty easily tell a mango and a pineapple apart. If you’re getting the right fruits with the expected quality, you can keep growing the same tree and maybe plant more of the same. Otherwise you can even remove the plant or adjust your gardening, trying a different type of fertilizer or dose the water differently. Until you get the wonderful garden you were looking for.
- An Agile transformation is not a Change Program, you can plan upfront, set goals and KPIs, deploy it to the organization and track the progress. It simply doesn’t work like this. As you might have understood introducing Agile is complex: you’ve never done it before and you do not know exactly where you’re going, how can you define the steps to get there? The answer is then to use Agile instead: yes, use Agile to introduce Agile. So have a transition strategy and a transition backlog, but use an empirical, iterative and incremental approach. Prototype and refine, make assumptions and validate them through baby steps, use fast feedback loops: it’s all about Continuous Improvement.
- Of course using an empirical process control implies that you can observe your system to be able to inspect and adapt. Therefore enabling full transparency is a key success factor: make relevant information visible as much as possible from everybody to everybody to be able to really understand what’s going on and act accordingly. Otherwise your transformation will degenerate into chaos. It is not enough to put information in Ericoll
- Nobody can say: I do not have the link
- Management by incentives: Management puts targets and incentives to e.g. number of trainings, usage of agile practices, velocity, improvement in velocity, green builds Pushing Agile: Very little / no communication about why we are doing this change and what do we want accomplish. A lot of push of processes and practices. Managers exclude themselves from the change or don’t see need to change themselves No/little investment in learning and coaching: Very often I would get the question “But we don’t have 2 days for that training. Can’t you do it in two hours?”. My standard answer was: “sure, if I skip the learning part”. And very often we would get requests for training only, because “we don’t have the time for coaching”. Leadership Team does not have the time or interest to lead the change Start by defining the “Agile Process”: no focus on improving people’s skills: Taylorist approach vs. Lean approach: Do things with people not to people!
- Taylorist vs Lean approach
- In 18 months we managed to: 1. reduce the average lead time of developing a feature (from concept to being ready for deployment) by 25% In particular we reached the first result, especially thanks to a dramatic reduction (about 60%) of the lead time of what we called early phases, mainly by: - replacing waterfall studies with iterative backlog handling and much earlier prototyping and development - using a PO team to minimize dependencies among teams and a Portfolio Kanban to reduce the WIP of MMFs, so that the whole organization could focus on the top priority items
- 2. reduce defects at customer site by 42% We achieved the second result mainly by: - having cross-functional teams incorporating also QA engineers, so that we could have faster and more meaningful feedback loops - moving from Sprint based to daily based system integration, with many team builds and tests per day and builds and tests of the whole system both nightly and event based (whenever a US was finished) We reached these 2 results while increasing at the same time the motivation index by 10%, thanks basically to Scrum and a new leadership style.