How to measure the outcome of Agile transformation?

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.

schedule Submitted 2 years ago

Comments

In what kind of case organizations the survey was conducted? It might be interesting for potential participants to know if these were small, medium or large organizations and how long had they been on that road?

Thanks for submitting the proposal. I'd like to know the same question being addressed that which is asked by Tuula and learn if there was any downside at all in this research. The audience may look forward to learn the downsides too. Is the presentation focussing on that too? Please share.

11% of the participants mentioned that they are not measuring the returns achieved by adopting Agile. Some of them believe that it is not worth calculating ROI of Agile transformation in their context. The others believed that they are following Agile as a primary engineering standard and do not need to justify its efforts. I would be sharing more details around this in the presentation.

There is no downside of the research, but the downside of having ROI calcuations could be the way in which it is looked at. Agile is iterative process in nature and it would be difficult to justify the benefits achieved by applying Agile in tangible manner. People also need to collect required data/information before it can evaluated meaningfully.

11% of the participants mentioned that they are not measuring the returns achieved by adopting Agile. Some of them believe that it is not worth calculating ROI of Agile transformation in their context. The others believed that they are following Agile as a primary engineering standard and do not need to justify its efforts. I would be sharing more details around this in the presentation.

There is no downside of the research, but the downside of having ROI calcuations could be the way in which it is looked at. Agile is iterative process in nature and it would be difficult to justify the benefits achieved by applying Agile in tangible manner. People also need to collect required data/information before it can evaluated meaningfully.

The participants in the survey were from from mid & small sized organizations. Most of the organizations have been practicing Agile for more than 1 year. I would be sharing more details around the survey participants and observations on how different organizations look at ROI calculation for Agile adoption.

The session seems to have survey findings, a case study as well as an innovation game. Three different things seem a lot to cover in 45 minutes. Can you see if this needs to be trimmed down? I feel the survey findings are the most critical message, and you could further discuss the import of the findings for various scenarios.

Thanks for your inputs. Yep, the presentation would primarily revolve around the survey findings are how different organizations, leaders and coaches are reviewing the benefits realized through Agile adoption. The case study is in the same flow, where I would present, what parameters we used in identifying a practical value achieved through Agile for one engagement. Agile Innovation games are really to engage participants, where they can share their feedback with the peers on the table if/how they are reviewing the benefits of applying Agile in their organization. The core details lik survey findings & case study would be covered in 30 mins, leaving 5 mins for innovation game + 10 mins for Q&A or entire 15 mins reserved for Q&A.

It would be great if you can update the presentation uploaded with this proposal. The current presentation focuses primarily on the innovation games (that comprises a miniscule part of the talk). We would like to get a glimpse of the case study/survey findings. We understand that to come up with a final presentation might take some time. Therefore, we would like to see an initial draft of the presentation which lays out the agenda for the talk and gives ample pointers to the proposed talk.

We have 4 days left to close the submission. Do consider updating the proposal accordingly.

Thanks for uploading the new version of presentation. Survey findings section looks decent. It would be great if you can add some weight to the case study slides. I am not sure how will you accommodate that in 45 mins. But, in the present state, we would like to have few more slides for case study (if being discussed)/leave it out.

I would be presenting my experiences of building different models to present the different made by Agile implementation. I would also present findings of my research on this topic and how different organizations are identifying the returns by adopting Agile. Considering this, the audience for the session would be the people who are applying Agile or are planning to adopt Agile, who can have these models as take aways to apply in their respective organizations. Do let me know if you would like to have any further information.

schedule 2 years ago

Sold Out!

45 Mins

Talk

Beginner

When faced with some challenge we try various things and finally find one silver bullet. Further we make use of the same silver bullet by incorporating it as part of Process and make it a rule to follow.

SCRUM as a framework has originated in similar situations and become the silver bullet for avoiding the ills of waterfall method. Scrum is successful and now widely used within multiple organizations.

Since SCRUM is almost 20 years old and 20 years of usage must have generated enormous feedback for the framework itself. Maybe it’s time to look at those feedbacks and do a retrospective on the way we’re using SCRUM.

My experience with multiple scrum projects taught me that one of the biggest de-motivating factor of working with scrum sprints are their monotonous nature of work. The sprint cycles with sprint planning and retrospectives becomes too repetitive to keep up the initial momentum.

We use the word “Just for change” quiet often for our own well being and happiness. SCRUM Dev is the same “Just for change” development practices incorporated within sprints.

These sprints contain unplanned working to themed based working which breaks the monotonous cycle of work and help maintaining the team momentum. At the same time it also benefits the product and its quality.

Jaya S - ScrumBan: Best of both worlds - A Fertile Hybrid

schedule 2 years ago

Sold Out!

45 Mins

Talk

Beginner

We're living in the days of fusion where fusions have created extremely useful products. There are fusions like western music with Indian classical, Pizza with Indian dishes like Paneer etc to name a few.

Scrumban is also a fusion generated by combining the best practices of Scrum and Kanban. Scrum is an excellent framework for delivering the software by using iterative incremental way while kanban "Just in Time" technique enables us to handle on demand agility for frequently changing and dynamic working environments.

Scrum framework consists of artifacts and roles while kanban is a visual board which deals with Work in the form of Work in Progress limits. There are situations where our product development environment faces ever changing priority and requirements.

ScrumBan is an effort to combine the iterative development and role based responsibilities of Scrum along with capability to handle the adaptive dynamics of Kanban.

Scrumban can be used effectively for product development as well as for maintenance purposes. In scrumban we do a Release Planning but not sprint planning. Planning on Demand is the characteristics of Scrumban where based on the items on the Scrumban board we decide to do planning or product demonstrations.

Scrumban also imbibes some new concepts of release planning called Triage & feature freeze which greatly improves the product quality.

schedule 2 years ago

Sold Out!

45 Mins

Talk

Advanced

This talk is an experience sharing session about what it takes to realize business benefits in a large-scale (beyond 100 people) agile transformation. Having driven more than 4 large-scale transformation initiatives (of scales 160 to 700 people) over last 5 years, I would be sharing a couple of case-studies where I worked recently and I would discuss various challenges of implementing large-scale transformation and possible approaches to handle them. Participants would be engaged through interactive discussions on mutual experience sharing with a focus on key dimensions of agile execution.

As the title reveals, the talk would focus more on execution challenges and approaches to handle them at all levels of stakeholders involved in a transformation. Levels include developers, architects, managers (project/engineering), senior management (delivery/program management, directors) and CXO's. More details in Outline section.

The key dimensions to be covered include

Building and sustaining learning culture (approaches include Community of Practice, Guilds and Joint Workshops)

Krishnamurty VG Pammi - Lean Scrum - The need of the hour

schedule 2 years ago

Sold Out!

45 Mins

Talk

Intermediate

The 2015 state of scrum report published by Scrum Alliance states that the outlook of scrum is highly favourable. Virtually all consider it likely that their organization will use scrum in future. While this is good, the survey also noted one of the key challenges observed by survey respondents as “Product owners and teams were just not willing and/or enthusiastic about Scrum best practices”. Thus, although scrum methodologies have greatly increased productivity, scrum is not without its problems. We need to quickly address this gap.

Keeping scrum values at the core, scrum methodology is mostly visible to teams on the ground in terms of three pillars (1) Scrum roles (2) Scrum artifacts and (3) Scrum events. While Scrum has kept scrum roles and scrum artifacts lean, it has empowered teams on the ground to learn the art of performing scrum. Scrum prescribed guidance on scrum events with clear purpose, frequency, maximum duration and recommended attendees. It recommends teams to learn the art of performing scrum events through their experience stating “scrum is easy to understand and difficult to implement”

While some scrum teams mastered this art, I find most of the scrum teams are still struggling in this process. I come across situations where teams are not finding scrum events interesting primarily because they find these events unproductive. The result is that we see less interactions and cooperation from the teams during scrum events. This is impacting basic agile manifesto “Individuals and interactions over processes and tools". In net, there is no surprise when product owners and teams were just not willing and/or enthusiastic about Scrum best practices.

Lean Scrum is the need of the hour. As part of lean scrum, we will adopt scrum methodology at the core and we implement lean framework to address the pain areas witnessed by teams

As part of this talk, I will share my experiential insights on

Outlook of scrum is highly favourable. Although scrum methodologies have greatly increased productivity, scrum is not without its problems. We need to quickly address these gaps

While scrum has kept scrum roles and scrum artifacts lean, it has empowered teams on the ground to learn the art of performing scrum events. Are we keeping these events lean and Valuable?

Lean scrum – The need of the hour

What is Lean Scrum

Anti-Patterns/Most frequently faced challenges/ wastes experienced by scrum teams in each of the scrum events (case findings based on my experience)

Where do the scrum teams stand on "expected scrum patterns" in each of the scrum events (case findings based on my experience)

Leverage "Lean framework" to help scrum teams to learn the art of performing scrum events through realizing value and enhancing their reach on "expected scrum patterns".

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” The term value is increasingly becoming starting point of what we do. We need to keep questioning everything we do using customer value generation as the yard stick

Unless, we drive scrum events towards value generation by continuously eliminating waste/ anti patterns, there is no surprise that “Product owners and teams were just not willing and/or enthusiastic about Scrum best practices” as observed by "The 2015 state of scrum" report.

schedule 2 years ago

Sold Out!

45 Mins

Experience Report

Beginner

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.

schedule 2 years ago

Sold Out!

45 Mins

Case Study

Advanced

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.

Krishnamurty VG Pammi - Building Cross functional teams by example.

schedule 2 years ago

Sold Out!

45 Mins

Talk

Intermediate

Cross functional team (CFT) as a whole has all the skills needed to build the product, and that each team member is willing to do more than just their own thing. Agile methodologies recommend long lived CFTs to implement agile manifesto and principles effectively. CFTs have become more popular in recent years for many reasons that include but not limited to:

They improve coordination and integration

They are flexible to adapt to changing market needs

They develop innovative products more quickly

They span across organization boundaries

They improve problem solving and lead to more thorough decision making

To be precise, we are not fully agile if we do not nurture CFTs. Not far from now, you will see digital enterprises trying to compete with each other in developing and releasing their apps every 5 days. CFTs will become one of the fundamental pillars for agile methodologies to adapt to such aggressive future needs

Building CFTs is an art and nurturing collaboration among CFTs is even more challenging. In this talk, I will explain about

(1) Building Cross Functional Teams by Example

(2) Nurturing Cross-functional Team Collaboration

(3) Imperative elements that need to be considered for succeeding with cross functional teams. Without proper attention to these elements, any cross-functional team will be fighting an uphill battle to succeed.

schedule 2 years ago

Sold Out!

45 Mins

Talk

Intermediate

Although agile methodologies have greatly increased productivity, Agile is not without its problems. Agile recommends adaptive planning through its multi-level planning events. Agile planning is expected to remain relevant in guiding teams till their destination as it incorporates the then risks, issues, assumptions and constraints into consideration while planning at last responsible moments.

While it appears good on paper, I find challenges involved in this approach. Scrum teams on the ground may mostly focus their efforts on their team specific daily and sprint targets. They lack common understanding of team expectations on what is probable product that they think is possible at the moment with the list of the then risks, assumptions, constraints and dependencies. To be precise, teams on the ground lack this bottom up view of the integrated probable product in next 2 to 4 months

On the other hand, enterprises spend efforts and money for their strategy, portfolio and product planning exercises. The result is that these planning events tell the top down view of “Where Product owner want to take the product to be?”

When top down view and bottom up view are not properly balanced with proper discussion among stakeholders during release planning exercise, we see teams oscillating instead of iterating witnessing below symptoms.

Teams slips on their release forecast

Cross team dependencies are detected towards end of the release and there was not much time available to resolve those dependencies within the release

Key decisions that were supposed to be taken during release planning exercise, would be taken up towards final sprints.

Risks are identified towards the end and this gives less room to mitigate the risks

When these symptoms recur periodically, as an enterprise, we would not be in position to provide the expected functionality to the end users. This may ultimately hit team’s morale and enterprise brand. Part of this chaotic pattern may be attributed to agile planning events.

This can be overcome if we perform release planning exercise effectively. But surprisingly, not much literature is available on how to perform release planning exercise even though everybody underlines its importance. In result, we see anti patterns keep creeping and they derail release planning objectives.

In this talk, I will be listing potential probable anti patterns that can derail teams from achieving their expected outcomes. I will introduce each pattern in the format

Anti-Pattern

Potential Impact

How to address this anti-pattern

If performed well, release planning exercise makes stakeholders meet together and discuss the challenges involved in unifying the top down understanding of “What the product Owner wants the product to be” with the bottom up understanding of “what the development teams thinks as the possible product scope that can be accomplished”. This inturn will be input to upcoming product planning events. Release planning thus acts as a guide post to baseline current understanding of team expectations on what is probable product that they think is possible at the moment with the list of the then risks, assumptions, constraints and dependencies.