Break Rules and Still Be Agile: How to Succeed with Agile While Managing Risks and Delivering Value
•Télécharger en tant que PPTX, PDF•
1 j'aime•403 vues
This document discusses how to break rules while still maintaining agility. It introduces FATA INFORMATICA, a software development company since 1994 that has worked on several government projects. It then discusses focusing on team commitment, measuring risk through a risk evaluation value scale from no risk to very high risk, and measuring value through assigning point values to new stories.
Recommandé
Recommandé
Contenu connexe
Dernier
Dernier (20)
En vedette
En vedette (20)
Break Rules and Still Be Agile: How to Succeed with Agile While Managing Risks and Delivering Value
- 1. How to break the rules and still be agile Dott. Antonio Capobianco PMP, PMI-ACP, Certified Product Owner Certified Scrum Master
- 2. Who is FATA INFORMATICA Software development since 1994 ERP Contrattisti for Foreign Affair Minister Toto2000 for Lottomatica Schengen scheduler for Foreign Affair Minister Electronic Visa for Istituto Poligrafico e zecca dello stato Pers2000 for per Comando Generale Arma dei Carabinieri Sentinet3®
- 20. Risk Evaluation Value NO RISK 1 MODERATE 1.3 HIGH 1.8 VERY HIGH No Evaluation
- 23. 10 Value point New Story Value 3 Value point
- 26. 1 23 4 12 3 1 23
- 28. Focus on Team Committment Measuring risk Measuring value
Notes de l'éditeur
- The history of the Waterfall model is somewhat disrupted. It is often said or believed that the model was first put forth by Winston Royce in 1970 in one of his articles; whereas he did not even used the word “waterfall.” In fact Royce later presented this model to depict a failure or a flaw in a non-working model. So later on, this term was mostly used in writing about something that is often wrongly done in the process of software development – like a common malpractice. Royce was more of the opinion that a successful model should have the allowance of repetition or to go back and forth between phases which the waterfall model does not do. He examined the first draft of this model and documented that a recurrent method should be developed in this model. He felt the need of progressing only after a feedback from the previous stage has been received. This is known as the Iterative model. As opposed to the Waterfall model, the Iterative model is more practical and has room for maneuver. Followers of the Iterative method perceive the Waterfall model as inappropriate.
- Il project management tradizionale, almeno secondo PMI, si divide in 12 aree di conoscenza, ciascuna divisa in sottoprocessi interconnessi tra di loro. Per passare tra un processo ed un altro è necessario creare documentazione come il Project Charter la cui approvazione fa partire il progetto, il piano di progetto, il registro delle modifiche, piano di gestione dei requisiti. Tutto questo può avere un senso in progetti molto grandi e nei quali si sono contrattualizzati strettamente con il cliente il costo, il tempo e lo scopo. Ricorda di parlare del gold plating
- Il project management tradizionale, almeno secondo PMI, si divide in 12 aree di conoscenza, ciascuna divisa in sottoprocessi interconnessi tra di loro. Per passare tra un processo ed un altro è necessario creare documentazione come il Project Charter la cui approvazione fa partire il progetto, il piano di progetto, il registro delle modifiche, piano di gestione dei requisiti. Tutto questo può avere un senso in progetti molto grandi e nei quali si sono contrattualizzati strettamente con il cliente il costo, il tempo e lo scopo. Ricorda di parlare del gold plating
- Il project management tradizionale, almeno secondo PMI, si divide in 12 aree di conoscenza, ciascuna divisa in sottoprocessi interconnessi tra di loro. Per passare tra un processo ed un altro è necessario creare documentazione come il Project Charter la cui approvazione fa partire il progetto, il piano di progetto, il registro delle modifiche, piano di gestione dei requisiti. Tutto questo può avere un senso in progetti molto grandi e nei quali si sono contrattualizzati strettamente con il cliente il costo, il tempo e lo scopo. Ricorda di parlare del gold plating
- Jim Highsmith, the Director of Cutter Consortium's Agile Product and Project Management Practice, explains the need for the Agile Triangle. "If agility is about delivering customer value by being flexible, then how can adhering to a traditional scope-schedule-cost (Iron Triangle) be the best way to measure performance?" Highsmith's answer is that it can't, so on to the Agile Triangle that focuses on value, quality and constraints. With the Iron Triangle comes scope, scheduling and cost to deliver quality. Agile Methodology does require that teams must adapt within the project scope and realign schedules all while staying within the cost of the project to deliver the end result. If the new Agile Triangle theory is attempted, what's different? Scope Versus Value - The project scope is important. It outlines your projects and defines them. If you're an Agile manager, shouldn't value be part of the project scope? In fact, the value of your project includes the scope at many levels, not just definition, so think about both project value and project scope and how well your team can adapt. Agile management offers flexibility, but too much flexibility can lose the value of the project or result in a failed outcome. Discuss what the most valuable elements of your project's scope are. Schedule Versus Constraints - Project schedules are hard and fast rules to stick to but there will always be change. Defining constraints can help with time lines and schedules within a project. The Agile Triangle considers utilizing constraints to redefine scheduling. Cost Versus Quality - Does the cost of a project actually reflect the quality of the project? With the Iron Triangle, a good project scope, schedule and cost factors measure a project's quality. In the Agile Triangle, quality should not be the end-all of the project, it should rather allow for flexible cost structures to produce the desired effect and quality. Using the Agile Triangle Some experts say there is no such thing as an Iron Triangle in Agile Methodology. Why? Because projects can't be fit into tiny flexible boxes and there are more than three elements to consider when using Agile management. The Agile Triangle has helped to sway these doubters through implementation. If we take Jim Highsmith's example that utilizes Agile Methodology, the first being Motorola's Iridium project that failed in the marketplace and then James Cameron's over-cost and over-schedule movie, Titanic, which one succeeded? Motorola's project was the Agile Methodology success because it stayed within the scope, schedule, and cost, even though it failed at the marketplace. Titanic, on the other hand had overruns as high as $200 million but gained $1 billion at the box office; it utilized no Agile methods and even though monetarily it succeeded, it didn't use good agile management techniques. So how can the new Agile Triangle work for your projects? Value - Your project's value should be measured by the stakeholders and what they expect. Quality - The quality part of the triangle means you can deliver a reliable product by adapting to the customer's needs. Constraints - Here, the three elements of the Iron Triangle appear – project scope, schedule, and cost. So in fact the Agile Triangle, by changing its elements to include value and quality and keeping the old standards in the constraints part of the triangle can be beneficial, more adaptable, and flexible to teams and the entire project.
- We went through all the stages of the shu ha ri process, the Aikido learning path, introduced in agile by Alistar Cockburn.
- We went through all the stages of the shu ha ri process, the Aikido learning path, introduced in agile by Alistar Cockburn. Jeff Sutherland e Ken Schwaber – Scrum XP – Kent Beck Crystal – Alistar Cockburn (osmotic comunication and caves and common)
- obeying he rules (shu, which means to keep, protect, maintain), consciously moving away from the rules (ha, which means to detach or break free), and finally unconsciously finding an individual path (ri, which means to go beyond or transcend) We went through all the stages of the shu ha ri process, the Aikido learning path, introduced in agile by Alistar Cockburn. Jeff Sutherland e Ken Schwaber – Scrum XP – Kent Beck Crystal – Alistar Cockburn
- kind of micromanagement where the project manager tells to the team what to do, and in which timeframe.
- “The one minute manager” by Kenneth Blanchard: one night he went with Mark to a bowling house.
- Developer develops the stories and set a story ready to be tested. A tester tests the stories
- The score is the sum of the risk adjusted costs of the story developed during the year. When a story is developed the risk adjusted value of the story is added to the previous score.
- Pre Sales chief that leads the pre sales engineer, a Post Sales Engineer that is an expert in networking and monitoring and leads the post sales engineer team, and a development team
- Our roadmap is stored in a roadmap board (RMB) that is a classic high touch low tech board where we stick the post it with epics. A classic backlog We tried software solutions but I felt that they don’t have the information radiator performance of a classic white board. Maybe the RMB could be done by a software board because the RMB information radiator attributes are not so important but we love to work with white board so we stick with them, furthermore we strongly have the need to have a very dynamic RMB because the IT market is very dynamic and so are the customer needs and expectations, and nothing is more dynamic than a post it on a white board!
- The “gulf of evaluation” is the difference between what the Pre and Post Sales Chief (PPSC) are expecting from a story and what the developing team really do!
- Mock ups are usually created with power point or html and, in our experience, helps to drastically reduce the gulf of evaluation.
- If an epic deserves to be entered in our PB 3different evaluations will be given: 1 for the risks, 1 for the costs and 1 for the added value.
- Risk Evaluation Situation Value No technical risks We know what to do, how to do and the code produced will not impact previously done features 1 Moderate technical risk We know what to do, how to do (maybe we have to do some small experiment) and the code produced will have a low impact previously done features 1,3 High technical risk We know what to do, how to do (maybe we have to do some small experiment) but the code will have a heavy impact on previously done feature. 1,8 Very High technical risk We know what to do, but we don’t know how. No
- Our measure is in working days, the days that 1 developer needs to do a feature. The costs evaluation is in charge of the Developer Chief. He really knows his team and how it works.
- Once done with the costs evaluation we multiply the costs value with risks value and we obtain a risk adjusted cost evaluation.
- Se la storia ha un rischio tecnico alto, e non è possibile definirne il costo e se ha meno di 3 value point la storia viene messa in fondo al Rbacklog.
- In iteration results we produces working code, increments, in a spike the results are information. A spike is strictly timeboxed in one iteration
- Project team chooses the stories to add to the iteration backlog. The stories are chosen by priority. The Chief Developer explain in detail every story and uses the mock ups created for the PPSC. This meeting is timeboxed to 4 hour
- The team member works on their stories and usually they catch up at the end of the week. Our programmers work on an open space and they have their backlog where stories are split in tasks. If a programmer needs help he can talk to the Chief Developer. We uses iterations of 10 days.
- At the end of the iteration a demo will be done. Our demo involves the development team showing what they have been produced during the ended iteration