The main challenging reasons why organizations are struggling to appreciate scrum implementation in their context today are of two folds:

1. Scrum is an agile project management framework. This focuses on maximizing “Return on Investment (ROI)”. Scrum, however does not define how to manage and track costs to evaluate actual ROI against the set vision.

This is preventing product owner community to prioritize maximum ROI features to the team sprint after sprint based on a rational performance assessment yardstick. Instead, they are proceeding with their expert gut feel. Some are hitting the target and most of them are falling apart the target.

This is making organizations endure some benefits that come out of discipline that scrum is institutionalizing. But most of the organizations are struggling to reap further benefits beyond certain level as they lack performance yardstick that guide them meet their set vision.

2. On the ground, most of the scrum teams work in their silos. That is, they dwell in their own sprint planning, sprint goals, retrospectives etc. They do not even get time to think on how their peer scrum teams are contributing towards overall project goal. Finally, we witness disjointed teams lacking understanding on “Where our current overall project stands? Do we reach our vision if we continue with the same rate collectively?”

In essence, scrum and leadership teams lack complete picture of project performance on the ground. That is why, they are struggling to take efficient and effective decisions based on current information. This is preventing organizations reaching their vision. They end up working for scrum instead of scrum working for them.

In this session, we shall learn a rational performance measurement yardstick called Agile EVM (Earned Value management) that integrates scope, schedule, cost parameters adapting to scrum values and principles. We shall take an agile scrum project as an example and learn how to calculate EVM indices that give below beautifully "carved interpretations" during scrum project's journey (after sprint 2 in our specific example):

1. We are currently behind the planned scope by $ 5,000 worth of work.
2. We are currently running over the budget by $ 7,000.
3. Rate at which the planned scope is realized is 80%.
4. For every one dollar we put into our project, we are getting 74 cents worth of work back.
5. If we continue at the same productivity rate, the expected total cost of completing the project is $ 67,500. Thus, we incur additional budget of $17,500 compared to our original budget.
6. If we have to complete the project on the original estimate of $50,000, all our scrum teams have to demonstrate 30% more productivity in the upcoming sprints. Else, we should be prepared for deviation.

This way, product owner can take rational decisions based on current information sprint after sprint and release after release. Also, teams on the ground can have complete picture on where the project stands and collaborate towards achieving maximum ROI.

We use the concept called value points in arriving at EVM indices for the targeted release wise business value. In some project contexts, we may experience imperfections in arriving at value points. That’s okay… because “Imperfect leading metrics are generally more valuable than perfect trailing metrics, since the leading metrics give us the opportunity to re-plan our approach”.

Agile EVM is must-to-have “AID” for product owner community because it enables them to prioritize high ROI features to the team early in the project journey. It thus enables them to take rational decisions based on current performance information. Agile EVM helps collaborate all the scrum teams well towards set vision by visually depicting the current performance and predicted future state at any stage during agile project life journey.

Unless we achieve maximum possible ROI, team collaboration keeping end customer satisfaction into our mission, no methodology or framework survives in the long run…. Let SCRUM work for us fully when we work for SCRUM fully.

We must admit that we are living in the age of conflict. We all are surrounded with conflicts in one form or the other. More than 20% of current leadership team's bandwidth is estimated to be going on resolving one or the other types of conflicts.

Whenever people come together to solve problems, there will be difference of opinion and competing interests. Thus, conflicts are normal and inevitable. Coaches, Scrum masters and managers often feel obliged to help resolve conflict, but before rushing in, it is best to observe the situation to get a better view of the issues.

Some degree of conflict is healthy, to ensure that ideas are sufficiently tested before they are adopted. However, we need to make sure the conflict does not escalate beyond healthy levels, else we will end up with a negative and repressive team environment.

Speed B. Leas Framework can help us objectively assess the severity of a conflict on severity scale of Level-1 to Level-5. In this session, we shall discuss Leas’ framework by detailing below topics:

1. Objective assessment of conflict levels (Level-1 to Level-5) based on environment and language being used.
2. Suggested conflict resolution approaches for different levels.

Thus, this session will equip you with Leas’ framework that can help you revisit your team level conflicts objectively by separating emotions. This way, you can create an environment in which people can use conflict constructively towards development of successful people, projects and products where each idea is successfully tested before it is adopted.

We are delivering products, but are we delivering with required "productivity"? – This is the question, each of us need to retrospect. In the current era, agility is becoming buzzword. We witness scenarios, where people are implementing agile just because they are asked to do. We witness prescriptive agile events, where team members do not engage to the required level during agile events. If this trend continues on the ground, the result is "unproductive agile events" wasting team's productive time. If we do not correct this pattern in time, agile leads to fragile on the ground.

Stemming from my practical insights on ground zero, I wish to share with you, the top 5 scenarios where sprint planning event can turn unproductive. For each of the 5 scenarios, I will explain

1. Scenario Context
2. How it went unproductive
3. Practical problem solving

This way, audience can take preventive steps so that the stated scenarios (from practical insights) will not recur in their sprint planning events. It helps them to retrospect what is going wrong in their sprint planning event and take steps to conduct sprint planning events through excellent team engagement. This way, they can contribute to “productive” sprint planning event.

The very thought that “How something can go wrong” can also trigger further thoughts to make other agile events productive.

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

1. 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
2. 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?
3. Lean scrum – The need of the hour
4. What is Lean Scrum
5. Anti-Patterns/Most frequently faced challenges/ wastes experienced by scrum teams in each of the scrum events (case findings based on my experience)
6. Where do the scrum teams stand on "expected scrum patterns" in each of the scrum events (case findings based on my experience)
7. Leverage "Lean Framework" to craft scrum events towards value generation. How to draw "AS-IS" and "TO-BE" Value stream management maps for two scrum events.
8. 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".
9. 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.

This is where Lean-scrum could prove to be powerful...

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:

1. They improve coordination and integration
2. They are flexible to adapt to changing market needs
3. They develop innovative products more quickly
4. They span across organization boundaries
5. 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.

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.

Price is what you pay. Value is what you get. According to the Standish Group research, 20 percent of customer application development features are often used, 30 percent are infrequently used, and 50 percent are hardly ever used. This means that a major percent of the performing organization's effort does not correlate to value generation.

Of the projects that met triple constraints, Standish Group research showed that only 13 percent yielded very high value, and 27 percent of the projects yielded high value. This means that about 60 percent of the projects yielded average to low value. And this means that, in the words of the study, "Sometimes you pay the price for a project but do not get the value."

What is missing? - I reflected on this experience and also reached out to teams to learn what can bridge this gap. Interestingly, I got collective feedback that stated, "Either we fail to understand end-user experience, or we do not give much weight to it."

User experience highlights the experiential, meaningful and valuable aspects of human-product interaction. Take the iPhone, which was launched in 2007. The phone’s unmatched user experience made its competitors out of the game; it set a new standard for smartphones. One of the secrets behind its success is the narrow set of customer needs Apple selected. Building customer satisfied products in the domain “internet of things” are becoming difficult and interesting now-a-days compared to other domains because gauging user experience in internet of things is quite dynamic and thus becoming quite challenging.

When developing a product with agile, planning takes place at multiple levels. Agile projects involve planning upfront and throughout the entire project. This way, agile teams perform adaptive planning at last responsible moments by incorporating the then risks, issues, assumptions and constraints into consideration.  This will enable teams to change their course of action even in scenarios where requirements take abnormal shift or when teams come across unforeseen challenges. Agile planning thus remains more relevant and useful as it can guide teams till destination. Products that are complex, creative and high-risk in nature certainly prefers agile planning approach because traditional approach of “upfront plan the entire work and work the initially set plan for rest of the journey” cannot guide them till  destination.

Experiential insights: I will unfold my experiential insights on how agile planning events (Vision, Product, Release, Sprint and Daily planning events) propel each other and nurture user experience periodically. I will explain how these adaptive planning outcomes connect each other and align themselves to the goal of delivering customer satisfied products.

User experience is no longer a choice -- it is a means of survival: You have got to start with customer experience and work back toward the technology, not the other way around. The user experience approach is no longer about usability, it is about value creation. It is no longer the role of one person or department, it is about culture. It is no longer a choice, it is a means of survival. In the words of MarketingTech, "74% of businesses believe that user experience is key for improving sales, conversation, and loyalty." Thus we cannot afford to underestimate the impact of our users' experience.

User experience does not start at purchase, it begins when the user has a need:  Agile planning events nurture user experience by discovering user needs. Aligning the product road map with user needs will certainly correlate product price to value creation. In fact, going with this approach, we can create situations in which end users perceive more value in our products than the price they pay for them. Google analyzes users' response patterns to their online posts and predicts user behavior even before users understand their responses themselves. It is an interesting journey toward understanding user experience, especially on products that leverage the Internet of Things. It is not an easy job to predict user experience. However, if we champion this aspect, we will indeed correlate product price to value creation.

2 major errors across 6 agile planning events give us 12. Learning “what not to do”, can sometimes help us identify risks early in the cycle so that, as a team, we can effectively respond to these risks.

Agile planning happens at multiple levels. In scaled agile delivery model, effective outcome of one planning event can influence the other significantly either positively or negatively.

Come and learn top 12 experiential insights. These will help you alert your teams on “what not to do” during Scaled Agile Planning events. I tried capturing top 12 errors across 6 planning events namely Strategy Planning, Portfolio Planning, Product Planning, Release Planning, Iteration Planning and Daily Planning.

Are you in need of stepping up “Transparency” & “Speed” in your scaled agile framework? Are you experiencing the difficulty that most of your scrum teams are focusing on their individual team specific goals and thus missing “whole-team” thinking towards “Shared Project goals”?

Learn our practical case study on how our teams could able to establish “Transparency and Speed” through realizing the connect among our “Daily Scrum”, “Scrum of Scrum”, “Scrum of Scrum of Scrum” events on a happening project that comprises of 18 scrum teams belonging to 10 business components located at 4 different countries.

Experience how our teams are able to instil the sense of urgency among the virtual teams and understood the noble purpose/role of “scrum of scrum” events in resolving cross site dependencies promptly through our 3 step framework “Plan, Perform and Adapt”

(1)    Plan:  Easy to use planning practices adopted by our teams to make our scaled “scrum of scrum” agenda simple and relevant.

(2)    Perform: Ground level challenges resolved by our teams and how our team could able to implement the agenda set in achieving transparency, speed and thus quality.

(3)    Adapt: Practices our team implemented in responding to the change and adopted “whole team thinking” in achieving“ shared project goals”

Scrum of Scrum events helped our team progress quickly and easily. Our team could able to coordinate and integrate their work effectively. The interesting thing is that our teams could able detect the risks early in this game and came up with apt response strategies to address them.  

Keeping the discussions short and focussed in these events comes with practice and preperation. Our teams are kept current with “cross team dependencies”, “Risks with response plan”, “Issues and their progress” and “number of added stories and defects since we last met”.  Our teams leveraged Visual communication channels when it comes to “scrum of scrum of scrum” across different sites.

Come and experience our case study and take-a-way “useful” learnings to make your scaled agile project achieve “Transparency”, “Speed” and thus “Agility” with teams reflecting “whole-team thinking” and working for “Shared project goals day after day….