Why Businesses should not ignore Technical Debt - A Case Study
Cases like the Toyota’s Unintended Acceleration case of 2007 highlight the impact of bad engineering practices on the quality of the product. This eventually impacts the business and the organization’s reputation as well. There have been several such instances in recent history, yet business stakeholders get tempted to compromise on the sound engineering practices for having quick gains. This approach, most of the times, is due to lack of understanding of these practices and under-estimating their negative impact in the long run. The aim of this paper is to highlight this impact and present a strong case for paying enough focus on concept like technical debt to reduce and control it in software development context.
Outline/structure of the Session
- Present the Case Study
- Root Causes for failure
- Why Businesses should track and monitor it - Business Impact!
- How Engineering teams should make Technical Debt visible?
- How to factor Technical Debt in Estimation?
- Business Impact of high Technical Debt
- How to make Technical Debt visible?
Business Executives / Stakeholders, Product Owners
schedule Submitted 1 year ago
People who liked this proposal, also liked:
How to measure the outcome of Agile transformation?Rahul
schedule 1 year agoSold Out!
With many organization moving to Agile environment, it is important to have a model that can help us identify if the Agile Transformation is resulting in the expected outcome. This session would present different measurement models to measure the outcome of Agile transformation in an organization.
The paper covers various measurement models that can be used during different phases of Agile transformation. The session also presents outcome of a survey conducted by the author on how different organizations, Agile coaches & leaders are measuring effectiveness of their Agile implementation. It would present a research on how different organization perceive success of Agile adoption, what are the parameters used by different organizations and how different people present the changes observed by adopting Agile environment.
e.g. 20% respondents each said ‘Delivery cycle time’ & ‘Delivering business value’ as the key parameters. And other 20% mentioned ‘Working Software’ / ‘Customer Satisfaction’ & ‘Reduction in defects, waste & risks’ as the parameters for measuring success of Agile.
The session also presents a case study of Agile transformation where these different effectiveness measurement models were applied successfully. It covers various aspects like Business case definition of Agile implementation, Agile Transformation roadmap, Agile readiness assessment, Agile current state assessment, Agile effectiveness evaluation and ROI of Agile implementation.
The session would also include an Agile Innovation Game, where the attendees would brainstorm with their peers on how they currently capture the changes brought by implementing Agile in their organization.
Experience of building Agile Center of Excellence (CoE) for organization-wide Agile maturityRahul
schedule 1 year agoSold Out!
When any organization plans to move to Agile methodology, it needs to plan multiple initiatives for successful transition. One of the important initiative would be building an Agile Center of Excellence, a team which would support for consistency of Agile implementation across the organization. The Agile CoE we built worked on multiple aspects such as:
- Defining organization-wide Agile methodology, tailoring it as per organization environment if required
- Build knowledge of Agile across the organization
- Supporting the team members with any ongoing queries
- Support in building required Tools and Templates required implementing Agile
- Assessing Agile implementation of different projects, identifying any gaps or improvement areas
This session would cover practical experience of how we built a successful Center of Excellence, which become a big enabler for successful Agile transformation.
Building self-organizing teams is not a cake walkPooja Wandile
schedule 1 year agoSold Out!
Agile philosophy puts a lot of emphasis on self-organized teams that can build great quality products and services. Self-organization is one of the core attributes of agile teams or if I dare to say, is at the heart of agile project management. Self-organized teams are supposed to be self-contained and have required skills that works towards a shared vision. They don't need directions (read command and control) and can figure out on their how to best deliver results. A lot of literature can be found around self-organization.
In spite of wide knowledge and information around this topic, it would be interesting to know how many organizations have actually managed to create such teams. How many 'Spotify' case studies are around? In my opinion and experience, I think building self-organizing teams is easier said than done. While it’s a very good intent but there are lot of challenges that drags creation of such teams. For creating a mouthwatering dish, just like you will need right ingredients and in right quantity, same goes for creating a self-organized team. Unless you have all ingredients, such as, management commitment, an individual's willingness & attitude, infrastructure and operations, supporting groups, an organization's culture, etc. in place, it is difficult to have self-organized teams that can run like a well-oiled machine.
In this session, I will share some of my experiences with such teams, their behavior pattern, how such teams can be nurtured, some successful and some not so successful attempts.