SMEF 2007 (www.dpo.it/smef2007)
This presentation discusses the current manner to do estimations in agile contexts taking care both of ASD (Agile Sw Development) and APM (Agile Project Management) methods and techniques, proposing some tips for improving estimates from SE best practices
Agile is not just a collection of practices or a checklist, but rather a methodology that needs to be tailored to each individual project situation. While Agile shares common principles, it does not prescribe practices that must be followed for every project. Agile should start by following established practices and principles but allow for iteration-based tailoring, as it is not a one-size-fits-all approach that will be right for every project type.
This document discusses the challenges of running a project that combines both waterfall and agile methodologies. Some key challenges include different approaches to reporting, managing changes, meeting customer expectations, and communicating plans to stakeholders between the two methods. However, the document notes that it may not always be necessary to view waterfall and agile as completely different if long term goals are defined but short term iterations use more agile processes, and flexibility is prioritized over rigid adherence to a single methodology. It concludes that the best approach depends on the specific project, customer, environment and team.
Waterfall vs agile approach scrum framework and best practices in software d...Tayfun Bilsel
The document discusses various topics related to software development approaches, including:
1. The differences between waterfall and agile approaches. Agile focuses on iterative development and responding to change over extensive planning.
2. Common problems with traditional project management like late delivery and budget overruns.
3. An overview of the Scrum framework, including roles, artifacts, ceremonies, and best practices. Scrum uses short iterations called sprints to iteratively deliver working software.
4. Recommendations to customize Scrum by incorporating elements of eXtreme Programming (XP) and lean principles to eliminate waste and continually improve processes.
The document discusses estimation in agile projects, noting that agile methods use iterative development with frequent delivery of working software to allow for emergence of requirements and capabilities. Agile estimation is done at both the iteration and release level, with developers re-estimating effort for upcoming iterations based on experience from previous iterations. Daily stand-up meetings, iteration planning meetings, and retrospectives help facilitate collaboration, adaptation, and continuous improvement in agile projects.
The document discusses the role of business analysts in agile software development. It argues that business analysts play an important role in helping agile teams meet business needs, either as the product owner or by supporting the product owner. When adopting agile, teams should initially focus on becoming more effective before emphasizing requirements or the business analyst's role. Over time, the business analyst should take a more prominent role in reducing unnecessary work through improved requirements analysis. Adopting agile processes does not remove the need for requirements; it changes the nature of requirements from push to pull based on business needs.
The document discusses prototyping in a SCRUM environment. It defines prototyping as an early sample or model used to test concepts and processes. In SCRUM, prototypes are used to identify requirements through requirements elicitation and validation. Different types of prototyping are used depending on needs, including throwaway prototyping, evolutionary prototyping, and rapid design and visualization prototyping. Prototypes help gather requirements, bring concepts to life for stakeholders, and reduce project risks.
Agile is not just a collection of practices or a checklist, but rather a methodology that needs to be tailored to each individual project situation. While Agile shares common principles, it does not prescribe practices that must be followed for every project. Agile should start by following established practices and principles but allow for iteration-based tailoring, as it is not a one-size-fits-all approach that will be right for every project type.
This document discusses the challenges of running a project that combines both waterfall and agile methodologies. Some key challenges include different approaches to reporting, managing changes, meeting customer expectations, and communicating plans to stakeholders between the two methods. However, the document notes that it may not always be necessary to view waterfall and agile as completely different if long term goals are defined but short term iterations use more agile processes, and flexibility is prioritized over rigid adherence to a single methodology. It concludes that the best approach depends on the specific project, customer, environment and team.
Waterfall vs agile approach scrum framework and best practices in software d...Tayfun Bilsel
The document discusses various topics related to software development approaches, including:
1. The differences between waterfall and agile approaches. Agile focuses on iterative development and responding to change over extensive planning.
2. Common problems with traditional project management like late delivery and budget overruns.
3. An overview of the Scrum framework, including roles, artifacts, ceremonies, and best practices. Scrum uses short iterations called sprints to iteratively deliver working software.
4. Recommendations to customize Scrum by incorporating elements of eXtreme Programming (XP) and lean principles to eliminate waste and continually improve processes.
The document discusses estimation in agile projects, noting that agile methods use iterative development with frequent delivery of working software to allow for emergence of requirements and capabilities. Agile estimation is done at both the iteration and release level, with developers re-estimating effort for upcoming iterations based on experience from previous iterations. Daily stand-up meetings, iteration planning meetings, and retrospectives help facilitate collaboration, adaptation, and continuous improvement in agile projects.
The document discusses the role of business analysts in agile software development. It argues that business analysts play an important role in helping agile teams meet business needs, either as the product owner or by supporting the product owner. When adopting agile, teams should initially focus on becoming more effective before emphasizing requirements or the business analyst's role. Over time, the business analyst should take a more prominent role in reducing unnecessary work through improved requirements analysis. Adopting agile processes does not remove the need for requirements; it changes the nature of requirements from push to pull based on business needs.
The document discusses prototyping in a SCRUM environment. It defines prototyping as an early sample or model used to test concepts and processes. In SCRUM, prototypes are used to identify requirements through requirements elicitation and validation. Different types of prototyping are used depending on needs, including throwaway prototyping, evolutionary prototyping, and rapid design and visualization prototyping. Prototypes help gather requirements, bring concepts to life for stakeholders, and reduce project risks.
The document provides an overview of Agile software development. It defines Agile as a collection of principles and practices aimed at improving collaboration, reducing documentation overhead, and making development teams more responsive to changes. The document discusses Agile methods like Scrum and Extreme Programming. It also covers Agile concepts such as user stories, velocity, and retrospectives. The document aims to help attendees understand what Agile is, its benefits, and how it differs from traditional waterfall methods. Training and certification options in Agile are also listed.
The Role of a BA on a Scrum Team IIBA Presentation 2010scrummasternz
What is your role as a BA on a Scrum team? How do you fit in? This presentation was given to the IIBA conference in NZ in 2010 by Stephen Reed. Stephen had worked extensively as a BA and moved into using Scrum with multiple teams at a large Insurance company. This experience led to a lot of questions around what the BA should be doing on a Scrum team. This presentation goes some way to listing what worked in the teams Stephen was involved in. The BA role does not change and all the skills of a great BA are necessary still on a great Software Development team, just more focused on being a team member and utilising those skills for the Scrum process of getting working software to the customer with more focus and clarity for the user.
The document discusses software estimation, including perspectives on estimation, exercises to practice estimation techniques, factors that need to be considered for software estimation such as requirements changes and team capabilities, and tools that can be used for estimation like work breakdown structures and Gantt charts. It also covers challenges with estimation like a lack of historical data, uncertainty in the estimation process, and how estimates become more accurate as a project's definition is refined.
The Business Analysts Role in Agile Software Developmentallan kelly
The document discusses the role of business analysts in agile software development. It argues that the product owner role is often filled by a business analyst. While business analysts take a backseat in early agile adoption, their role becomes more important as teams become more effective in delivering business needs. Specifically, business analysts are key to reducing unnecessary work through improved analysis and requirements. The document recommends a ratio of one business analyst for every 3-7 developers, depending on how stable the product is and how rapidly requirements change.
The BA role in Agile software developmentallan kelly
The document discusses the role of business analysts in agile software development. It argues that in traditional approaches, requirements are gathered at the start of a project by business analysts who then leave the project. However, in agile approaches, requirements gathering is an ongoing process and business analysts need to stay involved throughout to have a dialogue rather than just produce documents. The business analyst role evolves from an "order taker" to an internal consultant, facilitating discussions between business and development teams.
Is Project Management Discipline Relevant in an Agile World?Steve Nunziata
Traditional Project Management discipline is often perceived as in conflict with Agile methods. Is this the case? How can Project Mangers transform their approach to be effective in an increasingly Agile world?
This document provides an introduction to Lean, Agile, Scrum, and XP. It defines Lean as focusing on identifying value and optimizing processes. Agile emphasizes responding quickly to change through principles like valuing individuals, working software, and customer collaboration. Scrum is a framework that uses short cycles, daily stand-ups, and product backlogs to organize complex work. XP includes practices like pair programming, test-driven development, and collective code ownership.
The document describes how the Orion Standing Review Board (SRB) provides independent reviews that add value to the Orion Project. It outlines the makeup and role of the SRB, which includes experts from industry, government agencies, and academia. The SRB observes Orion's internal reviews and conducts formal assessments of key project milestones. While the SRB aims to provide constructive feedback, its assessments must be high-quality, fact-based, and independent of the project. The document notes some challenges around the timing of the SRB's reviews and reporting.
PMICOS Webinar: Building a Sound Schedule in an Enterprise EnvironmentAcumen
Dr. Dan Patterson presented a one-hour webinar on effective scheduling using metrics analysis. He reviewed some of the common problems found in schedules and the research that backs the claim that, in the end, the schedule drives project success.
Key Considerations for a Successful Hyperion Planning ImplementationAlithya
The document provides an overview and recommendations for a successful Hyperion Planning implementation. It discusses key project phases, recommended build techniques including application definition, dimensionality, master data integration, building the planning model, and form and calculation development. It also covers tips for planning design including delineating plan types, defining dimensionality, integrating master data from various sources, and best practices for building forms to ensure performance.
Administering a substantial fpc program in a large organisationGraeme Prescott
The document summarizes Graeme Prescott's presentation on administering a substantial function point counting (FPC) program in a large organization. It describes implementing and managing an FPC regime across multiple projects and sites within the Australian Government Department of Education, Employment and Workplace Relations (DEEWR). Key aspects included utilizing a qualified metrics cell and trained counters in each project team to count over 40 projects delivering more than 10,000 FPs per quarter across 25 applications. Challenges involved managing staff movements, fluctuating skill levels, potential conflicts between project counts impacting the same applications, and consolidating counts in a timely manner. Techniques aimed to automate linking reported FPs to effort recording and drive process and performance improvements using
This document provides an introduction to lean principles and kanban. It discusses two pillars of lean thinking: don't trouble the customer and develop people. Lean principles include continuous improvement, respect for people, eliminating waste, and problem solving. Kanban is introduced as a change management methodology that utilizes lean tools like visualizing workflow, limiting work-in-progress, measuring and managing flow, making process policies explicit, and using models to recognize improvement opportunities. Similarities and differences between scrum and kanban are also outlined.
The document introduces agile methods, including the agile manifesto which values individuals, interactions, working software, and customer collaboration over processes, tools, documentation, and contract negotiation. It describes the principles behind agile, such as customer satisfaction, welcoming changing requirements, and daily collaboration between business and development teams. Specific agile methods like Scrum and XP are also introduced.
The document discusses various agile methodologies including Agile Project Management (APM), Lean Software Development, Kanban, and Lean Kanban. It explains that APM introduced phases to align agile projects with traditional PMP phases. Lean Software Development adopts principles from Toyota Production System to address manufacturing issues. Kanban uses visual boards to manage workflow. Lean Kanban blends Kanban with lean principles and practices. The document also notes some controversy around agile approaches challenging traditional practices.
Dnv Improving Your Process Performances With AgileGeorge Ang
This document discusses a presentation given by Yann Hamon of DNV IT Global Services on improving process performances with agile methods. It provides background on DNV, describes agile software development practices like scrum and lean, and how mixing agile and CMMI can provide repeatable and controlled agile processes. The presentation explains how agile benefits productivity, reduces time-to-market and defects, and improves maintainability through practices like iterative development, continuous integration and automated testing.
This document discusses a presentation given by Yann Hamon of DNV IT Global Services on improving process performances with agile methods. It provides background on DNV, describes agile software development practices like scrum and lean, and how mixing agile and CMMI approaches can result in repeatable and controlled agile processes. The presentation outlines how agile methods can improve productivity, reduce time-to-market, lower defects, and enhance maintainability when using practices such as iterative development, continuous integration, and test-driven development.
1) In 2001, 17 people met to discuss lightweight software development methods, with only one person having a major interest in testing. This meeting helped establish agile methodologies but did not explicitly mention testing.
2) Early versions of agile testing focused on developers automating unit tests, with the view that testers roles would diminish. However, testers argued for the importance of other testing types like exploratory testing.
3) Over time, agile testing evolved to recognize different testing skills like test design, defect management, and exploratory testing. Automation tools also advanced to support both manual and automated testing by different roles within agile teams.
This document summarizes an agile transformation journey at a product company. It describes the current functional structure and process, which led to issues with efficiency, quality, transparency and expectations. An assessment was conducted which recommended transitioning to a cross-functional agile model with value streams aligned to products. A proposed solution included agile training, establishing roles and teams, and implementing ceremonies and practices. Initial results showed improvements in productivity, quality, time to market and visibility. Strengthening the product owner function and embedding changes into corporate culture were also recommended.
A keynote presentation comparing/contrasting old & new SDLC methodologies that was used to kick off an internal agile meetup focused on standardizing on the Atlassian suite of SDLC tools.
This document summarizes a seminar about continuous improvement in agile practices. The seminar introduced agile values and principles like transparency, inspection and adaptation. It covered techniques for continuous improvement like retrospectives and emphasized learning from experiences to constantly improve. Attendees participated in a retrospective exercise to discuss what went well and possibilities for future seminars to become more effective.
Obiettivi della presentazione: (1) Presentare una breve storia dell’ITSM degli ultimi anni; (2) Illustrare i tratti caratteristici dei principali framework e modelli nell’ITSM, tra cui ITIL e DevOps; (3) Proporre la giusta sintesi di diversi approcci ITSM, ricordando sempre che tali approcci rimangono sempre strumento, non obiettivo.
The missing links in software estimation: Work, Team Loading and Team PowerLuigi Buglione
This presentation investigates the theoretical foundation of the basic concepts used in software effort estimation, productivity measurement and benchmarking. By elaborating on how similar concepts are defined and used in well-established engineering fields, we aim to shed light on some inconsistent and fallacious use of concepts and units of measure, resulting misconceptions and their consequences in project planning. Particularly, we focus on ‘Work’, ‘Team Power’ and ‘Team Loading’, analyzing the way many studies from the ‘70s on faced such issue. Too often projects fail for being late and not always adding new resources allows respecting established milestones as well as the established quality levels. After setting the theoretical layout, we present the results of an empirical investigation we made using the data in the International Software Benchmarking Standards Group (ISBSG) dataset D&E (Development & Enhancement) v13, using both COSMIC and IFPUG data for Business and Real-Time applications. The results indicate that a considerable number of projects might have been poorly planned and utilized human resources inefficiently, and hence paid much higher costs. Hence, we suggest software companies to revisit the productivity data of the past projects as well as evaluating the new ones by measuring Team Power, Team Loading and comparing to Team Size utilized.
More Related Content
Similar to Improving Estimations in Agile Projects: Issues and Avenues
The document provides an overview of Agile software development. It defines Agile as a collection of principles and practices aimed at improving collaboration, reducing documentation overhead, and making development teams more responsive to changes. The document discusses Agile methods like Scrum and Extreme Programming. It also covers Agile concepts such as user stories, velocity, and retrospectives. The document aims to help attendees understand what Agile is, its benefits, and how it differs from traditional waterfall methods. Training and certification options in Agile are also listed.
The Role of a BA on a Scrum Team IIBA Presentation 2010scrummasternz
What is your role as a BA on a Scrum team? How do you fit in? This presentation was given to the IIBA conference in NZ in 2010 by Stephen Reed. Stephen had worked extensively as a BA and moved into using Scrum with multiple teams at a large Insurance company. This experience led to a lot of questions around what the BA should be doing on a Scrum team. This presentation goes some way to listing what worked in the teams Stephen was involved in. The BA role does not change and all the skills of a great BA are necessary still on a great Software Development team, just more focused on being a team member and utilising those skills for the Scrum process of getting working software to the customer with more focus and clarity for the user.
The document discusses software estimation, including perspectives on estimation, exercises to practice estimation techniques, factors that need to be considered for software estimation such as requirements changes and team capabilities, and tools that can be used for estimation like work breakdown structures and Gantt charts. It also covers challenges with estimation like a lack of historical data, uncertainty in the estimation process, and how estimates become more accurate as a project's definition is refined.
The Business Analysts Role in Agile Software Developmentallan kelly
The document discusses the role of business analysts in agile software development. It argues that the product owner role is often filled by a business analyst. While business analysts take a backseat in early agile adoption, their role becomes more important as teams become more effective in delivering business needs. Specifically, business analysts are key to reducing unnecessary work through improved analysis and requirements. The document recommends a ratio of one business analyst for every 3-7 developers, depending on how stable the product is and how rapidly requirements change.
The BA role in Agile software developmentallan kelly
The document discusses the role of business analysts in agile software development. It argues that in traditional approaches, requirements are gathered at the start of a project by business analysts who then leave the project. However, in agile approaches, requirements gathering is an ongoing process and business analysts need to stay involved throughout to have a dialogue rather than just produce documents. The business analyst role evolves from an "order taker" to an internal consultant, facilitating discussions between business and development teams.
Is Project Management Discipline Relevant in an Agile World?Steve Nunziata
Traditional Project Management discipline is often perceived as in conflict with Agile methods. Is this the case? How can Project Mangers transform their approach to be effective in an increasingly Agile world?
This document provides an introduction to Lean, Agile, Scrum, and XP. It defines Lean as focusing on identifying value and optimizing processes. Agile emphasizes responding quickly to change through principles like valuing individuals, working software, and customer collaboration. Scrum is a framework that uses short cycles, daily stand-ups, and product backlogs to organize complex work. XP includes practices like pair programming, test-driven development, and collective code ownership.
The document describes how the Orion Standing Review Board (SRB) provides independent reviews that add value to the Orion Project. It outlines the makeup and role of the SRB, which includes experts from industry, government agencies, and academia. The SRB observes Orion's internal reviews and conducts formal assessments of key project milestones. While the SRB aims to provide constructive feedback, its assessments must be high-quality, fact-based, and independent of the project. The document notes some challenges around the timing of the SRB's reviews and reporting.
PMICOS Webinar: Building a Sound Schedule in an Enterprise EnvironmentAcumen
Dr. Dan Patterson presented a one-hour webinar on effective scheduling using metrics analysis. He reviewed some of the common problems found in schedules and the research that backs the claim that, in the end, the schedule drives project success.
Key Considerations for a Successful Hyperion Planning ImplementationAlithya
The document provides an overview and recommendations for a successful Hyperion Planning implementation. It discusses key project phases, recommended build techniques including application definition, dimensionality, master data integration, building the planning model, and form and calculation development. It also covers tips for planning design including delineating plan types, defining dimensionality, integrating master data from various sources, and best practices for building forms to ensure performance.
Administering a substantial fpc program in a large organisationGraeme Prescott
The document summarizes Graeme Prescott's presentation on administering a substantial function point counting (FPC) program in a large organization. It describes implementing and managing an FPC regime across multiple projects and sites within the Australian Government Department of Education, Employment and Workplace Relations (DEEWR). Key aspects included utilizing a qualified metrics cell and trained counters in each project team to count over 40 projects delivering more than 10,000 FPs per quarter across 25 applications. Challenges involved managing staff movements, fluctuating skill levels, potential conflicts between project counts impacting the same applications, and consolidating counts in a timely manner. Techniques aimed to automate linking reported FPs to effort recording and drive process and performance improvements using
This document provides an introduction to lean principles and kanban. It discusses two pillars of lean thinking: don't trouble the customer and develop people. Lean principles include continuous improvement, respect for people, eliminating waste, and problem solving. Kanban is introduced as a change management methodology that utilizes lean tools like visualizing workflow, limiting work-in-progress, measuring and managing flow, making process policies explicit, and using models to recognize improvement opportunities. Similarities and differences between scrum and kanban are also outlined.
The document introduces agile methods, including the agile manifesto which values individuals, interactions, working software, and customer collaboration over processes, tools, documentation, and contract negotiation. It describes the principles behind agile, such as customer satisfaction, welcoming changing requirements, and daily collaboration between business and development teams. Specific agile methods like Scrum and XP are also introduced.
The document discusses various agile methodologies including Agile Project Management (APM), Lean Software Development, Kanban, and Lean Kanban. It explains that APM introduced phases to align agile projects with traditional PMP phases. Lean Software Development adopts principles from Toyota Production System to address manufacturing issues. Kanban uses visual boards to manage workflow. Lean Kanban blends Kanban with lean principles and practices. The document also notes some controversy around agile approaches challenging traditional practices.
Dnv Improving Your Process Performances With AgileGeorge Ang
This document discusses a presentation given by Yann Hamon of DNV IT Global Services on improving process performances with agile methods. It provides background on DNV, describes agile software development practices like scrum and lean, and how mixing agile and CMMI can provide repeatable and controlled agile processes. The presentation explains how agile benefits productivity, reduces time-to-market and defects, and improves maintainability through practices like iterative development, continuous integration and automated testing.
This document discusses a presentation given by Yann Hamon of DNV IT Global Services on improving process performances with agile methods. It provides background on DNV, describes agile software development practices like scrum and lean, and how mixing agile and CMMI approaches can result in repeatable and controlled agile processes. The presentation outlines how agile methods can improve productivity, reduce time-to-market, lower defects, and enhance maintainability when using practices such as iterative development, continuous integration, and test-driven development.
1) In 2001, 17 people met to discuss lightweight software development methods, with only one person having a major interest in testing. This meeting helped establish agile methodologies but did not explicitly mention testing.
2) Early versions of agile testing focused on developers automating unit tests, with the view that testers roles would diminish. However, testers argued for the importance of other testing types like exploratory testing.
3) Over time, agile testing evolved to recognize different testing skills like test design, defect management, and exploratory testing. Automation tools also advanced to support both manual and automated testing by different roles within agile teams.
This document summarizes an agile transformation journey at a product company. It describes the current functional structure and process, which led to issues with efficiency, quality, transparency and expectations. An assessment was conducted which recommended transitioning to a cross-functional agile model with value streams aligned to products. A proposed solution included agile training, establishing roles and teams, and implementing ceremonies and practices. Initial results showed improvements in productivity, quality, time to market and visibility. Strengthening the product owner function and embedding changes into corporate culture were also recommended.
A keynote presentation comparing/contrasting old & new SDLC methodologies that was used to kick off an internal agile meetup focused on standardizing on the Atlassian suite of SDLC tools.
This document summarizes a seminar about continuous improvement in agile practices. The seminar introduced agile values and principles like transparency, inspection and adaptation. It covered techniques for continuous improvement like retrospectives and emphasized learning from experiences to constantly improve. Attendees participated in a retrospective exercise to discuss what went well and possibilities for future seminars to become more effective.
Similar to Improving Estimations in Agile Projects: Issues and Avenues (20)
Obiettivi della presentazione: (1) Presentare una breve storia dell’ITSM degli ultimi anni; (2) Illustrare i tratti caratteristici dei principali framework e modelli nell’ITSM, tra cui ITIL e DevOps; (3) Proporre la giusta sintesi di diversi approcci ITSM, ricordando sempre che tali approcci rimangono sempre strumento, non obiettivo.
The missing links in software estimation: Work, Team Loading and Team PowerLuigi Buglione
This presentation investigates the theoretical foundation of the basic concepts used in software effort estimation, productivity measurement and benchmarking. By elaborating on how similar concepts are defined and used in well-established engineering fields, we aim to shed light on some inconsistent and fallacious use of concepts and units of measure, resulting misconceptions and their consequences in project planning. Particularly, we focus on ‘Work’, ‘Team Power’ and ‘Team Loading’, analyzing the way many studies from the ‘70s on faced such issue. Too often projects fail for being late and not always adding new resources allows respecting established milestones as well as the established quality levels. After setting the theoretical layout, we present the results of an empirical investigation we made using the data in the International Software Benchmarking Standards Group (ISBSG) dataset D&E (Development & Enhancement) v13, using both COSMIC and IFPUG data for Business and Real-Time applications. The results indicate that a considerable number of projects might have been poorly planned and utilized human resources inefficiently, and hence paid much higher costs. Hence, we suggest software companies to revisit the productivity data of the past projects as well as evaluating the new ones by measuring Team Power, Team Loading and comparing to Team Size utilized.
Risk Management: Achieving Higher Maturity & Capability Levels through the LE...Luigi Buglione
A common challenge in life is to evaluate and deal with risks. Even though Risk management is fundamental to any activity, it is too often evaluated and managed from a qualitative rather than a quantitative perspective. In order to improve, too often organizations are seeking compliance against a single model/approach, forgetting that most often ‘one model doesn’t fit all’ and that the target process model is the organizational one, strengthened by external best practices. An approach to process improvement that takes this into consideration is LEGO (Living EnGineering prOcess). LEGO extracts the most useful Elements of Interest (EoI) from several types of maturity models into an organizational Business Process Model (BPM) in order to facilitate to the achievement of higher organizational maturity and capability levels, that’s the definitive intended target to be improved. This paper applies the LEGO approach to Risk Management, analyzing several Risk Management Maturity Models and unifying their practices in order to come up with a more comprehensive process model on risk management integrating multiple views.
L4A - Lean for (being) Agile - Some thoughts and tips for a progressive path ...Luigi Buglione
‘Agile’ risks to be a very (ab)used term in the ICT (and not) community during last years. Agile means – as in the Agile Manifesto – to be responsive, working in team and be ready to change. But what do we need for really being agile? The answer is simple: start to be (before) LEAN in order to be (after) AGILE. Too often these two terms risk to be meant as synonyms, but they are different and complementary to each other. The presentation will show a possible path to do that, adopting Lean techniques as suggested by Six Sigma for reducing wastes (the seven ‘muda’) and only then adopting Agile ones, also applied to Functional (and not) Sizing Methods, such as Function Points and SNAP. Note from the conference organizers: “Muda” is a Japanese word meaning “waste”. The Toyota Production System identified seven types of “muda”.
From Software to Service Sustainability: a still Broader PerspectiveLuigi Buglione
This paper proposes an approach to enlarge the view from software (products) to services, because a service is a broader container than a project and can include software as well as other assets to be managed from an Asset Management perspective. Hybridizing typical software and service management models and frameworks could help organizations in a better management of their assets, stressing more the (inner) value of intangibles and of a good mid-long term strategy, passing for a valuable proposition of MVVs (Mission-Vision-Values).
The Significance of IFPUG Base Functionality Types in Effort Estimation - An ...Luigi Buglione
This document presents an empirical study on using different IFPUG base functionality types (BFCs) like external inputs, external outputs, external queries, internal logical files, and external interface files in effort estimation. The study uses project data from the ISBSG repository containing information on functional size, effort, application type, development type, and other attributes. Statistical analysis is performed on various subsets of the data based on filters. The results show that using multiple BFCs together in estimation, instead of just total function points, increases the correlation with effort significantly. This implies BFC types should be considered to obtain better estimation accuracy.
In Information and Communication Technology (ICT) a ‘deliverable’ may be either software (perceived as an ‘output’) or a service (perceived as an ‘outcome’). On the one hand, the differences between software and service have led to the design of parallel models and lifecycles with more commonalities than differences, thereby not supporting the adoption of different frameworks. For instance, a software project could be managed applying best practices for services (e.g. ITIL), while some processes (e.g. Verification & Validation) are better defined in models of the Software Management domain. Thus, this paper aims at reconciling these differences and provides suggestions for a better joint usage of models/frameworks. To unify existing models we use the LEGO approach, which aims at keeping the element of interest from any potential model/framework for being inserted in the process architecture of the target Business Process Model (BPM) of an organization, strengthening the organizational way of working. An example of a LEGO application is presented to show the benefit from the joint view of the ‘software + service’ sides as a whole across the project lifecycle, increasing the opportunity to have many more sources for this type of improvement task.
A Murphological View on Software Measurement: a serious joke or a funny seri...Luigi Buglione
The 30-year experience from the Software Measurement field explains that a strong resistance usually comes from project team members, supposing the real objective is a personal evaluation on their performance and not a neutral measurement for a concrete process improvement. Concurrently, from the middle ‘80s a series of SPI models - such as the Software Capability Maturity Model (Sw-CMM) and nowadays its evolution, the CMMI –provided a guide for realizing a real improvement, where measurement played an important role, before as a Common Feature, then as a separate process (MA – Measurement and Analysis) at Level 2. But a certain resistance still remain alive also after these years.
Recently, in the Management field (and also in ICT) more than “serious” books and reference guides it seems that (apparent) semi-serious publications such as the Dilbert strips by Scott Adams are referenced in technical presentations and papers as a starting point for commenting daily ICT malpractices. If so, another good source for “joking” with such serious things are some of the most know laws, the “Murphy’s laws”, originally written by Arthur Block and after created/modified by plenty of people worldwide and published over the Internet in a sort of “GNU licence for humour”.
This paper tries to propose a “murphological view” on Software Measurement issues, commenting some related measurement-related laws and providing links with main SPI practices at the aim to reduce the percentage of failures in application of Software Measurement programs, as noted by H.Rubin some years ago.
Do we really re-use our knowledge (or not)?Luigi Buglione
Looking back to the last 25 years in IT, one of the most used, practical IT ‘inventions’ has been the ‘cut & paste’ mechanism, that’s a reuse of a previous artefact. But looking to ICT organizations in these turbulent years – no matter if they deal with software and/ services – many of them seem to do not be designed for resilience. From a root-cause analysis (RCA), one of the main ‘bones’ for improvement is the lack of reuse of organizations’ experience, in terms of historical data, artefacts, processes, etc.
Thus, re-using the ‘internal knowledge’ (before thinking to software reuse) is – as many Process Improvement models like MPS.BR (both the SW and the SV constellations) affirm – one of the real ‘wheels’ driving an organization to achieve success, measured not only by ROI but also by VOI (Value on Investment), because the more and more relevance in understanding the role and value of intangibles in our business.
The keynote presentation will move from evidences and well-known industrial stories for discussing and understanding where knowledge has (or not) been the key driver for organizational success, which possible barriers to that and how multi-model approaches as LEGO (Living EnGineering prOcess) could help an organization in achieving such goals in an easier way, betting mostly on people knowledge, as the ‘building perspective’ also looking to the Balanced Scorecard (BSC) schema and logical flow.
Balanced Measurement Sets: Criteria for Improving Project Management PracticesLuigi Buglione
The availability of a measurement framework right at the early stage of a project can have a very positive impact in the management of software development process. In this paper, we cope with this problem proposing a methodology that can allow an early adoption of balanced measurement sets, which will be iteratively refined at each iteration of the process. The proposed methodology can be implemented and supported by open source tools like the Spago4Q platform.
PIF or SNAP? That's the Question! Or maybe it's not? - A panelLuigi Buglione
The presentation introduced a panel organized at IWSM-MENSURA 2014 by MAIN (Metrics Associations' International Network - www.mai-net.org) about the value and way to deal with NFRs in a software project, using a series of PIF (Productivity Impact Factors) for calibrating your project effort or a specific sizing unit? That's the (discussed) question!
Software Sustainability: a Broader PerspectiveLuigi Buglione
In this presentation the approach to address software sustainability evaluation is discussed. We believe that software sustainability is a complex business to be addressed by including the largest set of indicators from software development, use, maintenance and disposal.
An ISO/IEC 33000-compliant Measurement Framework for Software Process Sustain...Luigi Buglione
ICT can provide a definitive contribution in reducing CO2 emissions and, in general, in the environment preservation. Because its pervasiveness in today’s life, software in particular plays an important role in achieving such a goal. Software process is the combination of those practices, directly or indirectly involved in software development, operation, and maintenance.
In previous papers the authors addressed the topic of evaluating the sustainability of software products. In this paper the focus is on the evaluation of the sustainability of the software process, i.e. the measurement of the extent the process is performed by having care of the environment and by minimizing its impact on the environment. To do that, a sustainability measurement framework for software process is defined. Such a framework is composed by Sustainability Levels, Sustainability Process Attributes and being compliant with the requirements stated in the new ISO/IEC 33000 series standard for software process assessment.
Measurement Process: Improving the ISO 15939 StandardLuigi Buglione
Over the past few years ISO has published a number of specific standards detailing processes included in a generic form in software development life cycle models. ISO 15939 on the Measurement process itself is an example of such specific ISO standard. This paper presents some suggestions for improvements to its Measurement Information Model and to the measurement plan within the planning process of ISO 15939.
This document discusses measuring and evaluating productivity for both functional and non-functional requirements (NFRs). It describes SNAP (Software Non-functional Assessment Process), a new NFR sizing method developed by IFPUG. SNAP divides NFRs into categories and sub-categories to assign size in SNAP Points. The document advocates measuring both functional size units (FSUs) and non-functional size units (NFSUs) to more accurately evaluate overall productivity. It provides an example of how to incorporate NFR-related tasks into work breakdown structures and schedules.
The LEGO Strategy: Guidelines for a Profitable DeploymentLuigi Buglione
When dealing with improvements, organizations seek to find a break-even point for their applications as early as possible in order to maximize the return from their investment. However, in some cases such a strategy can lead to a long term failure by not realizing the full benefits, when focusing only on a short term. The LEGO (Living EnGineering prOcess) approach – a method for building your own process meta-model based on multiple inputs – is a way to make an organization more efficient and effective, optimizing resources, as well as time and costs through looking at its entire Business Process Model. This paper introduces the elements for designing a strategy for a more valuable deployment of a process improvement initiative, in order to optimize the choice of the models and elements to be considered as an input to the LEGO approach
ICEBERG: a different look at Software Project ManagementLuigi Buglione
Every project – whatever the application field – should be managed taking into account at least four dimensions: Time, Cost, Quality and Risk. To manage these dimensions, a key tool for a Project Manager is to increase project visibility, defined as the amount of information about the project associated with its probability of occurrence. This paper uses the “iceberg” metaphor to introduce the ICEBERG (Improvement after Control and Evaluation-BasEd Rules and Guidelines) approach that can help Project Managers through the use of standard (de jure and de facto) ICT methods and techniques. This approach focuses not only on the management, and measurement, of resources, process and product, but also of the project and the organization itself. A list of candidate measures related to these 5 entities is suggested for a comprehensive software measurement plan in order to reduce project risk.
Improving Measurement Plans from multiple dimensions: Exercising with Balanci...Luigi Buglione
“Tracking & Control” activities in software projects are most often based, in industry, on just two dimensions of analysis: time and cost. Most often, ‘tracking & control’ excludes other dimensions (such as quality, risks & impact on society, stakeholders’ viewpoint in a broader sense) taken into account in Performance Management models such as EFQM or the Malcolm Baldridge model. How can balancing those multiple concurrent control mechanisms across several dimensions of analysis be done? Balancing Multiple Perspective (BMPs) is a procedure designed to help project managers choose a set of project indicators from several concurrent viewpoints. This paper also presents the related questionnaire with a list of 14 candidate measures helping to compare the “as-is” situation and to figure out what will be the desired one, including cost figures to be possibly considered in the budget for next projects.
Improving the User Story Agile Technique Using the INVEST CriteriaLuigi Buglione
Although the Agile Software Development (ADS) approach has been around for the last 15 years, it is only recently that attention has moved towards Agile Software Management (ASM) for tackling some of the management-related weaknesses, such as estimating on the basis of User Story points. This paper presents an application of the INVEST criteria (Independent – Negotiable – Valuable – Estimable – Small –Testable) for improving the measurement technique of User Stories, introducing sizing units and a technique to negotiate requirements. It includes a discussion on an approach to balancing the six criteria used to evaluate a set of User Stories in a Sprint.
During the past 20 years Maturity & Capability Models (MCMs) become a buzzword in the ICT world. Since the initial Crosby’s idea in 1979, plenty of models have been created in the Software & Systems Engineering domains, addressing various perspectives. By analyzing the content of the Process Reference Models (PRM) in many of them, it can be noticed that reuse-related issues have unfortunately often little importance in the appraisals of the capabilities of software organizations while in practice they are considered as significant contributors in traditional process and organizational performance appraisals. While MCMs represent a good mean for assessing the status of a set of processes, integrating two or more models with a common area of focus can offer more information and value for an organization. The aim of this paper is to present some information about Reuse best practices and models, keep the best components from each model and – using the LEGO (Living EnGineering prOcess) approach to process improvement - merge those best practices from several types of maturity models into an organizational Business Process Model (BPM) in order to achieve in an easier and faster way higher organizational maturity and capability levels.